fix: correct stale claims in the router and the READMEs

Coherence pass over the rewritten docs set. The recurring defect was a
refactor whose removals landed and whose replacements did not.

- tdd: restore the pointer to /codebase-design that the v1.0 changelog
  and ask-matt both claim exists. The inline deep-module notes were
  deleted then; nothing replaced them.
- ask-matt: /grilling and /resolving-merge-conflicts were missing from
  the router entirely. Split grill-me from grill-with-docs on the
  working directory rather than on whether the subject is code.
- READMEs: wayfinder maps decision tickets, not investigation tickets;
  the diagnosing-bugs loop starts by building a loop that goes red;
  improve-codebase-architecture is a survey, not a rescue; grilling
  resolves a design tree and is the primitive behind five skills.
- Drop the /implement reliability claim from the implement and tdd
  pages.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/engineering/codebase-design.md

@@ -65,7 +65,7 @@ No, and Matt has been consistent about that under repeated pushback. [Issue #95]
 
 **Does `tdd` actually use this vocabulary?**
 
-Not yet, in the sense you'd expect. `tdd` talks about seams heavily, but it defines "seam" itself — as "the public boundary you test at" — and contains no reference to `codebase-design`. It uses "boundary", the word this skill's glossary bans. The inline deep-module notes that used to live inside `tdd` were removed in favour of this shared skill, but the pointer replacing them was never added. Matt has acknowledged the gap publicly: "Yeah I have a /codebase-design skill, might be that TDD needs to point there too." In practice that means invoking `/tdd` will not reliably pull this vocabulary in — say so explicitly if you want it.
+It does now. For a long time it did not. The inline deep-module notes that used to live inside `tdd` were removed in v1.0 in favour of this shared skill, but the pointer replacing them was never added — so `tdd` defined "seam" for itself and referenced nothing. Matt acknowledged the gap publicly ("Yeah I have a /codebase-design skill, might be that TDD needs to point there too") and the pointer is now in the skill, reached when the shape of the interface is the open question rather than the tests. `tdd` still owns "seam" as the boundary you *test* at; this skill owns the module shape behind it.
 
 **Does the design-it-twice pattern work outside Claude Code?**
 

docs/engineering/grill-with-docs.md

@@ -12,7 +12,7 @@ Reach for it at the start of a change, in a repo, when the plan is still fuzzy a
 
 | What you have | Reach for |
 | --- | --- |
-| An idea, no repo — or a subject that isn't code | [grill-me](https://aihero.dev/skills-grill-me) |
+| You aren't working in a working directory at all | [grill-me](https://aihero.dev/skills-grill-me) |
 | A repo, and a change you can settle in one session | `grill-with-docs` |
 | An effort too big to hold in one session — a greenfield build, a large feature | [wayfinder](https://aihero.dev/skills-wayfinder) |
 | A repo with no domain docs at all, and no particular feature in mind | `grill-with-docs`, aimed at the repo rather than a change |

docs/engineering/implement.md

@@ -44,14 +44,10 @@ One run covers one ticket. The tickets [to-tickets](https://aihero.dev/skills-to
 
 The idea the skill runs on is the **seam**: the public boundary you observe behaviour at, without reaching inside. Tests live at seams. Working at a seam agreed before any code is written is what keeps the tests durable, because the implementation underneath can be rewritten without the tests moving.
 
-The word "pre-agreed" is doing real work, and it is also the skill's weakest joint. Nothing inside `implement` agrees the seams. `tdd` is the skill that asks, and it refuses to write a test at an unconfirmed seam. So in practice the agreement happens either upstream in the spec, or in the first exchange of the run. If it happens nowhere, the precondition never fires and the run quietly becomes "just write the code". That failure is common enough to be the first question below.
+The word "pre-agreed" is doing real work, and it is also the skill's weakest joint. Nothing inside `implement` agrees the seams. `tdd` is the skill that asks, and it refuses to write a test at an unconfirmed seam. So in practice the agreement happens either upstream in the spec, or in the first exchange of the run. If it happens nowhere, the precondition never fires and the run quietly becomes "just write the code". Naming the seams in the spec is what stops that.
 
 ## Common questions
 
-**It implemented the work but never ran `/tdd` or `/code-review`. Is that expected?**
-
-It is a known, open bug, and it is the single most reported thing about this skill. One reporter estimated `/tdd` fails to fire in about 80% of runs. The diagnosis in the issue thread is context burial: the skill's text is injected once at invocation, and by the time the implementation is done the closing steps are hundreds of lines back with nothing re-surfacing them, so they are the first thing dropped. Others report the opposite inconsistency, with `code-review` running some sessions and not others, or firing per ticket when they didn't ask for it. Matt rejected the proposed fix of stronger completion wording as a no-op, on the grounds that "must" buried 500 lines back reads the same as "should". Until it is fixed structurally, the reliable move is to invoke `/tdd` and `/code-review` yourself rather than expect the chain to hold.
-
 **It finished, but my ticket is still open and the acceptance criteria are still unchecked.**
 
 Correct, and expected. `implement` has no completion step. It ends at the commit and never touches the work item, confirmed on GitHub Issues and on the local markdown tracker, so it is not a tracker integration problem. It also does not act on the findings `code-review` produced, and does not tick the `- [ ]` boxes on the originating issue. Close the ticket and reconcile the criteria yourself. This bites hardest on a dependency chain, because `to-tickets` defines the frontier as tickets whose blockers are all closed. If nothing gets closed, nothing ever becomes visibly unblocked.

docs/engineering/tdd.md

@@ -54,10 +54,6 @@ Because the refactor step was removed and the description was not. Matt dropped
 
 This is the most-reported friction with the skill ([issue #607](https://github.com/mattpocock/skills/issues/607)). The prompt lists candidate seams by name only, with nothing about what each one catches or misses, so you are choosing between labels. There is no fix shipped yet. The practical workaround is to ask the agent for the trade-offs before answering — what does the component-level seam miss that the integration seam catches, and how much slower is it. It is also why the chain agrees seams up front in `to-spec`, where you have the whole feature in view rather than one prompt.
 
-**I ran `/implement` and it never invoked `/tdd`.**
-
-Known and common. One user's estimate on [issue #479](https://github.com/mattpocock/skills/issues/479) is that `/implement` fails to trigger `/tdd` in about 80% of runs. Two structural reasons: `implement` says to use `tdd` "where possible, at pre-agreed seams", which is satisfied by doing TDD-shaped work without ever invoking the skill, and by the time implementation finishes the instruction is hundreds of lines back in the transcript. Naming it explicitly at the start of the run, or invoking `/tdd` yourself per slice, is the reliable path today.
-
 **It wrote the implementation before the test, even though the skill says red first.**
 
 It happens. One user pushed the model on it and got an unusually honest answer: "I knew the skill said 'one test at a time, watch it fail for the right reason' — I read it. I just defaulted to my normal habit." Matt's position is to live with it: "I've not managed to get agents to do anything 100% of the time. Being too forceful about this is also negative because we don't want to restrict an agent's creativity. So what I've done is I've just accepted that sometimes it will not follow TDD strictly. But overall I still get better results." If strict adherence matters for a particular slice, watch the run rather than trusting the skill to enforce it.