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

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 11:57:29 +01:00
parent 14c13c5bf9
commit 8010ddb2bb
8 changed files with 13 additions and 11 deletions

View file

@ -24,7 +24,7 @@ Reach for it whenever you're unsure which skill or flow a situation calls for: y
## Flows, not just skills
The idea `ask-matt` gives you to think with is the **flow** — a path *through* the skills rather than a single one. Most work runs along one **main flow** (idea → ship: grill → PRD → issues → implement), two **on-ramps** merge onto it (a triage lane for incoming bugs and requests; a codebase-health lane that generates ideas), and everything else is a **standalone** you reach for on its own. Ask a question and you get placed on the right flow, at the right step — not just handed a tool.
The idea `ask-matt` gives you to think with is the **flow** — a path *through* the skills rather than a single one. Most work runs along one **main flow** (idea → ship: grill → PRD → issues → implement → review), two **on-ramps** merge onto it (a triage lane for incoming bugs and requests; a codebase-health lane that generates ideas), and everything else is a **standalone** you reach for on its own. Ask a question and you get placed on the right flow, at the right step — not just handed a tool.
## Where it fits

View file

@ -44,7 +44,7 @@ What makes this variant its own skill is where the answers go. As the grill runs
`grill-with-docs` is the opening step of the main build chain:
```txt
grill-with-docs → to-prd → to-issues → implement
grill-with-docs → to-prd → to-issues → implement → code-review
```
It comes first, before anything is written down as a spec: it produces the shared understanding and settled vocabulary that [to-prd](https://aihero.dev/skills-to-prd) then synthesises into a PRD without re-interviewing you. Its close neighbours are [grilling](https://aihero.dev/skills-grilling), the same interview without the docs, and [domain-modeling](https://aihero.dev/skills-domain-modeling), the glossary-and-ADR discipline it drives. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.

View file

@ -30,10 +30,10 @@ Around that core it keeps the loop tight — typecheck often, run single test fi
## Where it fits
`implement` is the build step at the end of the main chain:
`implement` is the build step near the end of the main chain, just before the review:
```txt
grill-with-docs → to-prd → to-issues → implement
grill-with-docs → to-prd → to-issues → implement → code-review
```
Reach for it after the work has been specced and sequenced, not before. Its key neighbours are [to-issues](https://aihero.dev/skills-to-issues), which produces the independently-grabbable tickets it works through, and [tdd](https://aihero.dev/skills-tdd), which it drives internally to write the tests at each seam before running its own `/code-review` pass and committing. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.
Reach for it after the work has been specced and sequenced, not before. Its key neighbours are [to-issues](https://aihero.dev/skills-to-issues), which produces the independently-grabbable tickets it works through, and [tdd](https://aihero.dev/skills-tdd), which it drives internally to write the tests at each seam before running its own [code-review](https://aihero.dev/skills-code-review) pass and committing. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.

View file

@ -41,7 +41,7 @@ Refactoring only happens once the suite is green; never while red.
`tdd` is the red-green loop the main build chain runs to write code:
```txt
grill-with-docs → to-prd → to-issues → implement
grill-with-docs → to-prd → to-issues → implement → code-review
```
[implement](https://aihero.dev/skills-implement) is the chain's final step, and it drives `tdd` internally to build each ticket test-first — so `tdd` is the engine inside that step rather than a step of its own. You can also reach for it directly, whenever there's a concrete behaviour to build without a full spec. Its other neighbour is [codebase-design](https://aihero.dev/skills-codebase-design), which it leans on to find deep-module seams worth testing at. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.
[implement](https://aihero.dev/skills-implement) is the chain's build step, and it drives `tdd` internally to build each ticket test-first before handing off to [code-review](https://aihero.dev/skills-code-review) — so `tdd` is the engine inside that step rather than a step of its own. You can also reach for it directly, whenever there's a concrete behaviour to build without a full spec. Its other neighbour is [codebase-design](https://aihero.dev/skills-codebase-design), which it leans on to find deep-module seams worth testing at. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.

View file

@ -37,7 +37,7 @@ Before slicing, `to-issues` looks for prefactoring — "make the change easy, th
`to-issues` is a step in the main build chain:
```txt
grill-with-docs → to-prd → to-issues → implement
grill-with-docs → to-prd → to-issues → implement → code-review
```
It sits between [to-prd](https://aihero.dev/skills-to-prd), which hands it a settled spec with user stories to slice against, and [implement](https://aihero.dev/skills-implement), which builds each independently-grabbable issue, driving [tdd](https://aihero.dev/skills-tdd) internally to write the tests test-first. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.
It sits between [to-prd](https://aihero.dev/skills-to-prd), which hands it a settled spec with user stories to slice against, and [implement](https://aihero.dev/skills-implement), which builds each independently-grabbable issue, driving [tdd](https://aihero.dev/skills-tdd) internally to write the tests test-first, before its [code-review](https://aihero.dev/skills-code-review) pass. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.

View file

@ -53,7 +53,7 @@ That matters for agentic development: a good interface gives tests something dur
`to-prd` is a step in the main build chain:
```txt
grill-with-docs → to-prd → to-issues → implement
grill-with-docs → to-prd → to-issues → implement → code-review
```
Reach for it after the plan and domain language are resolved, and before you break the work into implementation tickets. Its key neighbours are [grill-with-docs](https://aihero.dev/skills-grill-with-docs), which sharpens the context so the PRD is precise, and [to-issues](https://aihero.dev/skills-to-issues), which turns the PRD into independently-grabbable issues for [implement](https://aihero.dev/skills-implement) to build. When you're unsure which skill or flow fits, [ask-matt](https://aihero.dev/skills-ask-matt) routes you.