Team recap · 27 July 2026
A session that began as a question about one skill’s behaviour and ended with a committed, reviewed plan to change it. No product code moved — what shipped is the design.
The work started from a plain question: what does the build skill do when you give it no plan? It stops, and tells you to go run a different command. The session turned that dead end into a designed, reviewed proposal for walking the user through to a finished plan instead.
The finding that shaped everything came early. The pipeline this work needed already existed, wired in the opposite direction. The task was never “build a pipeline” — it was “let one skill enter the pipeline that is already there.” That reframing cut the estimated change from three files to roughly twenty-five lines in one.
Everything is committed as 3c37605. Nothing is implemented: the plan’s status is todo.
Captures why this work should happen, with each decision dated and each rejected alternative named, so nobody re-argues a settled point. Four appendices ground the claims in real evidence — including a trace of a genuine defect in how these skills inherit their model.
Twelve steps, fourteen acceptance criteria, and a test section that is honest about its own limits. Every step carries why it exists and how to confirm it worked.
A five-reviewer panel produced three high-severity findings, each verified against the source files before being accepted rather than taken on trust. Two later rounds narrowed the design further: first repairing a flaw that a concrete usage scenario exposed, then scoping the whole feature to the explicit command.
| Situation | Today | After this plan |
|---|---|---|
| No plan named, none found | Stops, tells you to run another command | Walks you through proposal, plan, review |
| No plan named, one found | Silently uses it | Offers it, plus “write a new one” |
| No plan named, many found | Asks which one | Offers 3 at most, says how many were hidden |
| A goal was given | Not possible — no way to pass one | Search skipped; your goal wins |
| Mistyped filename | Stops, names the paths tried | Unchanged, deliberately |
| “build a todo app” as plain text | Needs an existing plan; routes away | Unchanged, deliberately |
| Which model writes the code | Whatever the session was using | Pinned, so it stops inheriting the reviewer’s |
| Version bump for the release | — | Major, not minor |
build.The handoffs between the three skills are already wired. Re-implementing them would mean a new flag on a neighbouring skill plus a guard against infinite loops, spread across three files.
build sequencing the stages itself (touches three files, duplicates existing logic); a fourth skill owning the pipeline (cleanest boundaries, but a whole new skill to avoid ~25 lines).The proposal skill handles a small, well-understood idea by just answering it — producing no document. Running it unconditionally would leave the chain holding nothing.
Otherwise a forgotten plan sitting in the directory can quietly win over the goal the user just typed.
That prompt is the only place the user is asked whether to build. Treating it as declining just the inner step would build the thing they declined seconds earlier.
Kept even after a reviewer argued against it, because the alternative is inheriting whatever the previous stage happened to set.
The existing test file documents, in its own comments, a whole-file search passing against a change that deleted all five rules it was supposed to protect.
The repository’s own rule classifies changes to how a command accepts input as major. The automated check only enforces “newer than the main branch,” so it would never have caught the undersized bump.
The goal becomes a parameter you pass, not a phrase that triggers the skill. This removes an entire class of false matches instead of trying to word around it.
Resolved during review. One appendix of the proposal described the old “not yet” behaviour that step 7 of the plan overrides. Automated review pushed on it, so the appendix now documents path-based resolution plus an explicit rule covering both “not yet” and “run as a workflow”, and names the reading it replaces.
todo, twelve steps, nothing applied.todo, in-progress, or completed, recorded at the top of the plan.