Plan Awesome GitHub site phases#753
Conversation
|
Warning Review limit reached
More reviews will be available in 42 minutes and 2 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
📝 WalkthroughWalkthroughThis PR launches a new "Awesome GitHub Site" project within the ChangesAwesome GitHub Site Project Documentation
YAML Frontmatter Corrections
🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
area:documentation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request establishes the planning documentation and structure for the 'Awesome GitHub Site' project, splitting the delivery into a Phase 1 MVP and a Phase 2 expansion. It introduces comprehensive guides, execution plans, run logs, and normalized briefs, while also updating the main execution plan and correcting minor front-matter formatting in existing website briefs. The review feedback suggests enhancing navigation and developer experience across several markdown files by converting plain text relative paths into clickable markdown links.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| - `../../../../../wceu-2026/website/mini-site-plan.md` | ||
| - `../../../../../wceu-2026/website/page-copy-starter.md` | ||
| - `../../../../../wceu-2026/website/` |
There was a problem hiding this comment.
Converting these plain text relative paths into actual markdown links will make them clickable and significantly improve navigation and developer experience.
| - `../../../../../wceu-2026/website/mini-site-plan.md` | |
| - `../../../../../wceu-2026/website/page-copy-starter.md` | |
| - `../../../../../wceu-2026/website/` | |
| - [Mini Site Plan](../../../../../wceu-2026/website/mini-site-plan.md) | |
| - [Page Copy Starter](../../../../../wceu-2026/website/page-copy-starter.md) | |
| - [Website Directory](../../../../../wceu-2026/website/) |
| - `../phase-1/README.md` | ||
| - `../phase-2/README.md` | ||
| - `../ISSUE_EXECUTION_PLAN.md` | ||
| - `../briefs/mini-site-plan.md` | ||
| - `../briefs/page-copy-starter.md` |
There was a problem hiding this comment.
Converting these plain text relative paths into actual markdown links will make them clickable and significantly improve navigation and developer experience.
| - `../phase-1/README.md` | |
| - `../phase-2/README.md` | |
| - `../ISSUE_EXECUTION_PLAN.md` | |
| - `../briefs/mini-site-plan.md` | |
| - `../briefs/page-copy-starter.md` | |
| - [Phase 1 Plan](../phase-1/README.md) | |
| - [Phase 2 Plan](../phase-2/README.md) | |
| - [Issue Execution Plan](../ISSUE_EXECUTION_PLAN.md) | |
| - [Mini Site Brief](../briefs/mini-site-plan.md) | |
| - [Page Copy Brief](../briefs/page-copy-starter.md) |
|
|
||
| ## 2026-06-03 Awesome GitHub Site Planning Kickoff | ||
|
|
||
| - New active project folder created: `.github/projects/active/awesome-github-site/` |
There was a problem hiding this comment.
Converting this plain text path into a clickable markdown link to the project's README will make it much easier to navigate directly to the new project planning folder.
| - New active project folder created: `.github/projects/active/awesome-github-site/` | |
| - New active project folder created: [.github/projects/active/awesome-github-site/](awesome-github-site/README.md) |
github-actions
Bot
removed
type:feature
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/projects/active/next-issues-execution-plan.md (1)
310-310:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFix the broken workflow file reference.
The pipeline's link checker found that
.github/workflows/readme-audit.ymldoesn't exist. The reference appears in the "Related Workflows" section at line 310 and again at line 475. Since this workflow hasn't been created yet, either remove the reference or update the text to clarify it's proposed/future work.Pipeline error:
Cannot find file: File not found. Check if file exists and path is correct. Missing file referenced: file:///home/runner/work/.github/.github/.github/projects/active/.github/workflows/readme-audit.yml.🔗 Proposed fix
**Related Workflows**: - `readme-regen.yml` — Already exists; runs on `.md` changes -- Future: `readme-audit.yml` — Proposed to validate Mermaid syntax, WCAG compliance, staleness +- `readme-audit.yml` — **Proposed** (not yet created): Will validate Mermaid syntax, WCAG compliance, staleness - Trigger: Combine manual dispatch + agent integration🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/projects/active/next-issues-execution-plan.md at line 310, The "Related Workflows" section references a non-existent workflow file `.github/workflows/readme-audit.yml`; update the entries that mention this filename so they no longer point to a missing file by either removing the broken link or changing the text to mark it as a proposed/future workflow (e.g., "proposed: .github/workflows/readme-audit.yml") and ensure any Markdown link syntax is removed or replaced with plain text so the link checker won’t try to resolve it; search for occurrences of `.github/workflows/readme-audit.yml` in the "Related Workflows" text and update both instances accordingly.
🧹 Nitpick comments (3)
wceu-2026/website/page-copy-starter.md (1)
1-6: ⚡ Quick winComplete the required frontmatter fields.
The YAML syntax correction is brilliant, but the frontmatter still needs six additional required fields per the coding guidelines:
file_typeversiontagsstatusstabilitydomainAs per coding guidelines: "All
.mdfiles in this repository should include YAML frontmatter with required fields: file_type, title, description, version, last_updated, owners, tags, status, stability, domain".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@wceu-2026/website/page-copy-starter.md` around lines 1 - 6, The frontmatter for "Page Copy Starter" is missing required YAML fields; add the six missing keys (file_type, version, tags, status, stability, domain) to the existing frontmatter block so it includes: file_type, title, description, version, last_updated, owners, tags, status, stability, domain; ensure values follow repo conventions (e.g., file_type: "page", version: "1.0.0", tags: [..], status: "draft"/"final", stability: "experimental"/"stable", domain: "<appropriate-domain>") and keep YAML syntax consistent with the existing header.wceu-2026/website/mini-site-plan.md (1)
1-6: ⚡ Quick winComplete the required frontmatter fields.
Whilst the YAML syntax fix is spot on, the frontmatter is still missing six required fields per the coding guidelines. Consider adding:
file_typeversiontagsstatusstabilitydomainAs per coding guidelines: "All
.mdfiles in this repository should include YAML frontmatter with required fields: file_type, title, description, version, last_updated, owners, tags, status, stability, domain".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@wceu-2026/website/mini-site-plan.md` around lines 1 - 6, The YAML frontmatter is missing required fields; add the six fields file_type, version, tags, status, stability, and domain to the existing frontmatter (alongside title, description, last_updated, owners). Edit the top YAML block in mini-site-plan.md to include file_type (e.g., "doc" or "plan"), a semantic version string for version, an array for tags, a status value (e.g., "draft" or "published"), a stability value (e.g., "experimental" or "stable"), and the domain string (e.g., "wceu" or appropriate area) so the file meets the repository frontmatter policy..github/projects/active/awesome-github-site/openspec/README.md (1)
52-56: ⚡ Quick winMake the RUN_LOG.md reference consistent with other paths.
For consistency with the explicit relative paths you've used in the Inputs section (lines 46-50), consider updating the RUN_LOG.md reference to use a relative path as well. This helps readers immediately understand where the file lives in the project structure.
🎯 Proposed fix for path consistency
- Keep phase 1 and phase 2 proposal files separate. - Use the normalised briefs as the initial source for `/opsx:propose`. -- Update `RUN_LOG.md` after each proposal run. +- Update `../RUN_LOG.md` after each proposal run.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/projects/active/awesome-github-site/openspec/README.md around lines 52 - 56, Update the README.md note that references RUN_LOG.md to use an explicit relative path (e.g., ./RUN_LOG.md) so it matches the other relative paths used in the Inputs section; locate the line mentioning RUN_LOG.md in the "Notes" block and replace the bare filename with the relative path (RUN_LOG.md -> ./RUN_LOG.md) to make the reference consistent and unambiguous.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/projects/active/awesome-github-site/briefs/mini-site-plan.md:
- Around line 1-16: Add the missing required YAML frontmatter fields to the Mini
Site Plan metadata so it matches the repository schema: include stability and
domain alongside the existing fields in mini-site-plan.md. Update the
frontmatter block at the top of the document, keeping the existing identifiers
like title, version, status, owners, and tags intact while adding the two
required keys with appropriate values.
In @.github/projects/active/awesome-github-site/briefs/page-copy-starter.md:
- Around line 1-16: The YAML frontmatter in the Page Copy Starter brief is
missing the required fields "stability" and "domain". To fix this, add these two
fields with appropriate values according to the metadata guidelines, alongside
the existing fields like file_type, title, description, version, last_updated,
owners, tags, and status. This change should be made at the top of the file
where the frontmatter is defined.
In @.github/projects/active/awesome-github-site/ISSUE_EXECUTION_PLAN.md:
- Around line 1-16: The YAML frontmatter in the ISSUE_EXECUTION_PLAN.md file is
missing the required fields `stability` and `domain`. To fix this, add these two
fields with appropriate values following the existing YAML structure at the top
of the file. Ensure these fields are included along with the other frontmatter
fields like file_type, title, description, version, last_updated, owners, tags,
and status to fully comply with the repository's documentation standards.
In @.github/projects/active/awesome-github-site/openspec/README.md:
- Around line 1-16: The YAML frontmatter is missing the required fields
`stability` and `domain`; update the top-of-file frontmatter (next to existing
keys like `title`, `description`, `version`, `created_date`, `last_updated`,
`status`, `owners`, `tags`) to add `stability:` and `domain:` with appropriate
values (e.g., stability: stable|experimental and domain:
website|opsx|documentation) so the file conforms to repository guidelines;
ensure proper YAML syntax and place the new fields within the existing
frontmatter block.
In @.github/projects/active/awesome-github-site/phase-1/README.md:
- Around line 1-16: Add the missing required YAML frontmatter keys "stability"
and "domain" to the document's existing frontmatter block (which already
contains file_type, title, description, version, created_date, last_updated,
status, owners, and tags); set "stability" to an appropriate level (e.g.,
stable/experimental/prototype) and "domain" to the relevant project domain name
or tag so the file conforms to the repository standard that mandates file_type,
title, description, version, last_updated, owners, tags, status, stability, and
domain.
In @.github/projects/active/awesome-github-site/phase-2/README.md:
- Around line 1-16: The YAML frontmatter at the top of the README is missing the
required stability and domain fields. In the existing frontmatter block (the
section beginning with file_type, title, description, version, created_date,
last_updated, status, owners, tags), add stability and domain keys with
appropriate values per the docs standard, keeping the existing fields unchanged.
Ensure these new keys are included within the same --- delimited block and
update last_updated if you modify the file.
In @.github/projects/active/awesome-github-site/README.md:
- Around line 1-17: Add the missing YAML frontmatter fields "stability" and
"domain" to the document's existing frontmatter block so it conforms to the
required schema (file_type, title, description, version, last_updated, owners,
tags, status, stability, domain); set "stability" to an appropriate value (e.g.,
stable/experimental/unstable) and "domain" to the relevant area (e.g., website,
opsx, open-spec) and ensure the fields are included alongside the existing keys
like file_type, title, description, version, last_updated, owners, tags, and
status in the top-of-file frontmatter.
In @.github/projects/active/awesome-github-site/RUN_LOG.md:
- Around line 1-16: The RUN_LOG markdown frontmatter is missing required
documentation fields, specifically stability and domain. Update the YAML
frontmatter in the RUN_LOG document to include those required keys alongside the
existing fields, keeping it consistent with the repository’s markdown metadata
standard and the current document’s structure.
In @.github/projects/active/next-issues-execution-plan.md:
- Line 5: Update the frontmatter version string because the document body
changed: locate the frontmatter key "version: v2.2.3" and increment it (e.g., to
"version: v2.2.4" or the next appropriate semantic version) so the frontmatter
matches the updated planning entries and table rows.
- Around line 24-31: The document lacks a top-level H1; add a single H1 (e.g. "#
Execution Log" or "# Planning History") above the first dated H2 block (the line
starting "## 2026-06-03 Awesome GitHub Site Planning Kickoff") so the file has
exactly one H1 and all subsequent headings remain sequential (no skipped
levels); ensure you place this H1 at the very top of the file and do not add any
other H1s.
---
Outside diff comments:
In @.github/projects/active/next-issues-execution-plan.md:
- Line 310: The "Related Workflows" section references a non-existent workflow
file `.github/workflows/readme-audit.yml`; update the entries that mention this
filename so they no longer point to a missing file by either removing the broken
link or changing the text to mark it as a proposed/future workflow (e.g.,
"proposed: .github/workflows/readme-audit.yml") and ensure any Markdown link
syntax is removed or replaced with plain text so the link checker won’t try to
resolve it; search for occurrences of `.github/workflows/readme-audit.yml` in
the "Related Workflows" text and update both instances accordingly.
---
Nitpick comments:
In @.github/projects/active/awesome-github-site/openspec/README.md:
- Around line 52-56: Update the README.md note that references RUN_LOG.md to use
an explicit relative path (e.g., ./RUN_LOG.md) so it matches the other relative
paths used in the Inputs section; locate the line mentioning RUN_LOG.md in the
"Notes" block and replace the bare filename with the relative path (RUN_LOG.md
-> ./RUN_LOG.md) to make the reference consistent and unambiguous.
In `@wceu-2026/website/mini-site-plan.md`:
- Around line 1-6: The YAML frontmatter is missing required fields; add the six
fields file_type, version, tags, status, stability, and domain to the existing
frontmatter (alongside title, description, last_updated, owners). Edit the top
YAML block in mini-site-plan.md to include file_type (e.g., "doc" or "plan"), a
semantic version string for version, an array for tags, a status value (e.g.,
"draft" or "published"), a stability value (e.g., "experimental" or "stable"),
and the domain string (e.g., "wceu" or appropriate area) so the file meets the
repository frontmatter policy.
In `@wceu-2026/website/page-copy-starter.md`:
- Around line 1-6: The frontmatter for "Page Copy Starter" is missing required
YAML fields; add the six missing keys (file_type, version, tags, status,
stability, domain) to the existing frontmatter block so it includes: file_type,
title, description, version, last_updated, owners, tags, status, stability,
domain; ensure values follow repo conventions (e.g., file_type: "page", version:
"1.0.0", tags: [..], status: "draft"/"final", stability:
"experimental"/"stable", domain: "<appropriate-domain>") and keep YAML syntax
consistent with the existing header.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: e531c660-1177-4f09-875e-7d4ece834e42
📒 Files selected for processing (11)
.github/projects/active/awesome-github-site/ISSUE_EXECUTION_PLAN.md.github/projects/active/awesome-github-site/README.md.github/projects/active/awesome-github-site/RUN_LOG.md.github/projects/active/awesome-github-site/briefs/mini-site-plan.md.github/projects/active/awesome-github-site/briefs/page-copy-starter.md.github/projects/active/awesome-github-site/openspec/README.md.github/projects/active/awesome-github-site/phase-1/README.md.github/projects/active/awesome-github-site/phase-2/README.md.github/projects/active/next-issues-execution-plan.mdwceu-2026/website/mini-site-plan.mdwceu-2026/website/page-copy-starter.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Testing
- GitHub Check: coderabbit-gate
- GitHub Check: check
🧰 Additional context used
📓 Path-based instructions (2)
**/*.md
📄 CodeRabbit inference engine (.github/instructions/markdown.instructions.md)
**/*.md: Use one H1 (#) per file; keep heading levels sequential (never skip from H2 to H4)
Use fenced code blocks with explicit language tags (bash,yaml,markdown, etc.)
Keep links relative for in-repo files; verify they resolve before merging
Use1.for ordered lists and-for unordered lists
Keep all wording in UK English (optimise, organisation, colour, behaviour, analyse)
Do not add areferences:frontmatter field — use inline links or a footer section instead
Blank lines before and after headings, code blocks, and block-level elements
Maximum line length: 120 characters (soft limit; prefer wrapping at natural sentence boundaries)
All.mdfiles in this repository should include YAML frontmatter with required fields: file_type, title, description, version, last_updated, owners, tags, status, stability, domain
Every image (![]()) must have descriptive alt text explaining the image's purpose, not its appearance. Empty alt (![ ]()) is valid only for purely decorative images
Link text must describe the destination — never use 'click here', 'read more', or bare URLs as visible text
Every table must have a header row (| Header |). Avoid merged cells
Use headings to communicate document structure, not for visual styling
Do not rely on colour alone to convey information in diagrams or callout blocks
Mermaid diagrams must includeaccTitleandaccDescrattributes for accessibility
Specify language in frontmatter; use plain language, avoid jargon where possibleDo not add a
referencesfrontmatter field to files; use inline links or footer sections instead
Files:
wceu-2026/website/page-copy-starter.mdwceu-2026/website/mini-site-plan.md
**/*.{md,js,ts,jsx,tsx,json,php,yml,yaml}
📄 CodeRabbit inference engine (CLAUDE.md)
Use UK English throughout (optimise, organisation, colour, behaviour)
Files:
wceu-2026/website/page-copy-starter.mdwceu-2026/website/mini-site-plan.md
🪛 GitHub Actions: Meta Agent / 2_front-matter-validate.txt
.github/projects/active/next-issues-execution-plan.md
[error] 1-1: Frontmatter freshness validation failed: body changed but version was not updated (v2.2.3).
🪛 GitHub Actions: Meta Agent / 3_lint-and-links.txt
.github/projects/active/next-issues-execution-plan.md
[error] 1-1: lycheeverse/lychee-action failed: Cannot find file. Error: file:///home/runner/work/.github/.github/.github/projects/active/.github/workflows/readme-audit.yml | Cannot find file: File not found. Check if file exists and path is correct.
🪛 GitHub Actions: Meta Agent / front-matter-validate
.github/projects/active/next-issues-execution-plan.md
[error] 1-1: Frontmatter freshness validation failed: body changed but version was not updated (v2.2.3). Step: npm run validate:frontmatter:changed (validate-frontmatter-freshness.js).
🪛 GitHub Actions: Meta Agent / lint-and-links
.github/projects/active/next-issues-execution-plan.md
[error] 1-1: lycheeverse/lychee-action failed (exit code 2). Cannot find file: File not found. Check if file exists and path is correct. Missing file referenced: file:///home/runner/work/.github/.github/.github/projects/active/.github/workflows/readme-audit.yml.
🪛 LanguageTool
.github/projects/active/awesome-github-site/openspec/README.md
[uncategorized] ~24-~24: Use a comma before “and” if it connects two independent clauses (unless they are closely connected and short).
Context: ... it after the planning docs are approved and the phase split is locked. ## Expected...
(COMMA_COMPOUND_SENTENCE_2)
[style] ~32-~32: Would you like to use the Oxford spelling “normalization”? The spelling ‘normalisation’ is also correct.
Context: ...chitecture and page map 3. Phase 1 copy normalisation 4. MVP site scaffold and page build 5. ...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~55-~55: Would you like to use the Oxford spelling “normalized”? The spelling ‘normalised’ is also correct.
Context: ...se 2 proposal files separate. - Use the normalised briefs as the initial source for `/opsx...
(OXFORD_SPELLING_Z_NOT_S)
.github/projects/active/awesome-github-site/README.md
[style] ~25-~25: Would you like to use the Oxford spelling “normalized”? The spelling ‘normalised’ is also correct.
Context: ...he phase 1 issue chain first, using the normalised briefs in briefs/ as the source of tr...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~48-~48: Would you like to use the Oxford spelling “Normalized”? The spelling ‘Normalised’ is also correct.
Context: ...expansion planning and issue sequence - Normalised source briefs aligned to repo conventio...
(OXFORD_SPELLING_Z_NOT_S)
.github/projects/active/awesome-github-site/briefs/mini-site-plan.md
[style] ~61-~61: Would you like to use the Oxford spelling “Normalize”? The spelling ‘Normalise’ is also correct.
Context: ... structural guide, not a copy target. - Normalise talk-centric wording into site-centric ...
(OXFORD_SPELLING_Z_NOT_S)
.github/projects/active/awesome-github-site/phase-2/README.md
[style] ~33-~33: Would you like to use the Oxford spelling “organization”? The spelling ‘organisation’ is also correct.
Context: ...y flows - stronger metadata and content organisation - fuller references and acknowledgement...
(OXFORD_SPELLING_Z_NOT_S)
.github/projects/active/awesome-github-site/phase-1/README.md
[uncategorized] ~22-~22: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...lue: ships a small but real site quickly so the project has a usable first outcome....
(COMMA_COMPOUND_SENTENCE_2)
[style] ~45-~45: Would you like to use the Oxford spelling “normalized”? The spelling ‘normalised’ is also correct.
Context: ... readable. - The copy is aligned to the normalised briefing docs. - The page structure is ...
(OXFORD_SPELLING_Z_NOT_S)
.github/projects/active/awesome-github-site/ISSUE_EXECUTION_PLAN.md
[uncategorized] ~22-~22: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...s the website a strict delivery sequence so the first release stays small and usefu...
(COMMA_COMPOUND_SENTENCE_2)
[style] ~32-~32: Would you like to use the Oxford spelling “normalization”? The spelling ‘normalisation’ is also correct.
Context: ...chitecture and page map 3. Phase 1 copy normalisation from the briefing docs 4. MVP site scaf...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~68-~68: Would you like to use the Oxford spelling “normalized”? The spelling ‘normalised’ is also correct.
Context: ...waiting for phase 2 detail. - Treat the normalised briefs in briefs/ as the source of tr...
(OXFORD_SPELLING_Z_NOT_S)
[typographical] ~72-~72: If specifying a range, consider using an en dash instead of a hyphen.
Context: ...tance Criteria - Phase 1 is bounded to 1-3 pages and can be launched independently...
(HYPHEN_TO_EN)
.github/projects/active/next-issues-execution-plan.md
[style] ~30-~30: Would you like to use the Oxford spelling “normalized”? The spelling ‘normalised’ is also correct.
Context: ...yle site expansion - Source briefs were normalised into the project folder so the phase sp...
(OXFORD_SPELLING_Z_NOT_S)
[uncategorized] ~30-~30: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ... were normalised into the project folder so the phase split can be planned without ...
(COMMA_COMPOUND_SENTENCE_2)
.github/projects/active/awesome-github-site/briefs/page-copy-starter.md
[uncategorized] ~22-~22: The official name of this software platform is spelled with a capital “H”.
Context: ...e that explains how LightSpeed uses the .github repository as a practical control plan...
(GITHUB)
[uncategorized] ~30-~30: The official name of this software platform is spelled with a capital “H”.
Context: ...les and workflows. This project treats .github as an operating layer instead: - temp...
(GITHUB)
[uncategorized] ~39-~39: The official name of this software platform is spelled with a capital “H”.
Context: ...te is informed by the open structure of github/awesome-copilot and by the LightSpeed ...
(GITHUB)
🔇 Additional comments (2)
wceu-2026/website/mini-site-plan.md (1)
4-5: LGTM!wceu-2026/website/page-copy-starter.md (1)
4-5: LGTM!
🔍 Reviewer Summary for PR #753CI Status: ✅ Recommendations
|
ashleyshaw
dismissed
coderabbitai[bot]’s stale review
Resolved in follow-up commits: metadata, tracker heading, and link fixes applied.
1 participant
Summary
This PR creates the new
Awesome GitHubplanning pack under.github/projects/active/awesome-github-site/and updates the live execution tracker to reflect the two-phase delivery plan.Changelog
Added
Awesome GitHubplanning.Changed
.github/projects/active/next-issues-execution-plan.mdwith the new project row and kickoff note.wceu-2026/website/mini-site-plan.mdandwceu-2026/website/page-copy-starter.mdfrontmatter.CHANGELOG.mdreferences to the consolidated docs paths.Fixed
Risk Assessment
Low. This is documentation and planning-only work. No runtime code, workflows, or production paths were changed. The main risk was link-validation breakage in repository documentation, which has been corrected.
How to Test
npm test.lint-and-linksandfront-matter-validate.Checklist