edkuksa/skills
1
0
Fork 0
mirror of https://github.com/mattpocock/skills.git synced 2026-07-29 02:52:42 +07:00
Code Issues Packages Projects Releases Wiki Activity

docs: thread code-review through the full build-chain flow

Browse Source 
The build chain now ends at code-review. Update every flow doc that draws
the chain so it reads end-to-end:

    grill-with-docs → to-prd → to-issues → implement → code-review

- grill-with-docs / to-prd / to-issues: extend the diagram; point the
  downstream neighbour at implement (which drives tdd internally).
- tdd: reframe from "final step" to the engine inside implement's step.
- implement: extend the diagram to include the review pass.
- ask-matt: narrate the flow ending in review (docs) and note that
  /implement closes out with /code-review (SKILL.md).
- writing-docs guide: refresh the example chain.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Matt Pocock
2026-07-01 12:05:16 +01:00
co-authored by Claude Opus 4.8
parent 14c13c5bf9
commit 8010ddb2bb
8 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/engineering/ask-matt/SKILL.md
+2
View File
@@ -23,6 +23,8 @@ The route most work travels. You have an idea and want it built.
- **Yes** → **`/to-prd`** (turn the thread into a PRD) → **`/to-issues`** (split the PRD into independently-grabbable issues). Because the issues are independent, **clear context between each one**: start a fresh session per issue and kick off **`/implement`** by passing it the PRD and the single issue to work on.
- **No** → **`/implement`** right here, in the same context window.
Either way, `/implement` closes out by running **`/code-review`** — a two-axis review (Standards + Spec) of the diff — before committing. Reach for **`/code-review`** on its own whenever you want to review a branch or PR against a fixed point.
### Context hygiene
Keep steps 1–3 in **one unbroken context window** — don't compact or clear until after `/to-issues` — so the grilling, PRD, and issues all build on the same thinking. Each `/implement` then starts fresh, working from the issue.