git:20260809.21f29b0 to git:20260809.5c2aad2

- description: Turns an already-discussed plan into a written spec and a set of tracer-bullet tickets — synthesizing rather than re-interviewing, slicing work end-to-end rather than by layer, and gating entry/exit with a written Definition of Ready and Definition of Done rather than by feel. Use when the user asks to turn a conversation or plan into a spec, break work into tickets, or size and sequence a set of tasks before implementation starts.

- A spec synthesizes what's already been decided; it does not re-interview the user from scratch. And a ticket is not "ready to start" or "done" by feel — both are gated by a written, agreed checklist, so two people (or two sessions) apply the same bar instead of a different one each time.

- ## Phase 1 — Synthesize the spec

- Pull together what the conversation, plan, or existing notes have already established — problem statement, scope, explicit non-goals, and any real constraints (technical, timeline, dependency) — into one written document. This is a **synthesis** step, not a fresh discovery interview: if a genuine open question surfaces that nothing already discussed has answered, ask it once, narrowly, rather than re-covering ground already settled.

- - **The problem**, in one or two sentences — what's wrong or missing, for whom.

- - **Non-goals** — explicitly named, not left to be inferred. An unstated non-goal is the most common source of scope creep once tickets are underway.

- ## Phase 2 — Slice into tracer-bullet tickets

- A **tracer bullet** ticket is a thin, complete slice through the whole system — enough to prove the path works end-to-end — rather than a horizontal layer (all the backend work, then all the frontend work). Slice work the same way `tdd` builds it: one vertical slice, working and demonstrable, before the next.

- - State what it delivers as a testable outcome, not a task description — "a user can submit the form and see a confirmation" instead of "build the form."

- - Keep it small enough to land in one focused work session — a ticket that can't be described in a sentence or two is usually two tickets wearing one number.

- ## Phase 3 — Apply INVEST to each ticket

- | **Valuable** | a ticket whose outcome doesn't matter to a user or the system on its own — usually a sign it should be folded into the ticket it's actually in service of |

- | **Estimable** | a ticket too vague to size — usually missing the acceptance outcome from Phase 2 |

- | **Small** | a ticket that spans more than one focused session — split it along another real seam |

- | **Testable** | a ticket with no way to verify it's done — see Phase 5's Definition of Done |

- ## Phase 4 — Definition of Ready (entry gate)

- - [ ] No open question remains that would change the approach — an unresolved question here is a hidden re-scope waiting to happen mid-implementation.

- A backlog of tickets that haven't cleared this gate is fine to hold — starting one that hasn't is how a "small" ticket turns into a multi-day detour chasing an answer that should have been settled first.

- ## Phase 5 — Definition of Done (exit gate) and handoff

- - [ ] The acceptance outcome from Phase 2 is demonstrably true — not "the code is written," but the actual outcome the ticket promised.

- Implementation itself is `tdd`'s job and merging is `code-review`'s gate — this skill's job ends at handing off a ticket that's genuinely ready, and confirming it against Done once work claims to be finished.