To Tickets

To Tickets

Wide refactors are the exception to vertical slicing.

• Blocked by: which other tickets (if any) must complete first
• What it delivers: the end-to-end behaviour this ticket makes work Ask the user: - Does the granularity feel right? (too coarse / too fine)
• Are the blocking edges correct — does each ticket only depend on tickets that genuinely gate it?
• Should any tickets be merged or split further? Iterate until the user approves the breakdown. ### 5. Publish the tickets to the configured tracker Publish the approved tickets. How depends on the tracker /setup-matt-pocock-skills configured — the tickets are the same either way, only the shape of the blocking edges changes: - Local files → write one file per ticket under .scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered from 01 in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below — one ticket per file, never a single combined file.
• A real issue tracker (GitHub, Linear, …) → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the ready-for-agent triage label unless instructed otherwise — the tickets are agent-grabbable by construction. Work the frontier: any ticket whose blockers are all done. For a purely linear chain that means top to bottom. Do NOT close or modify any parent issue. # — What to build: the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list. Blocked by: the numbers/titles of the tickets that gate this one, or "None — can start immediately". Status: ready-for-agent - [ ] Acceptance criterion 1
• Acceptance criterion 2 ## Parent A reference to the parent issue on the tracker (if the source was an existing issue, otherwise omit this section). ## What to build The end-to-end behaviour this ticket makes work, from the user's perspective — not layer-by-layer implementation. ## Acceptance criteria - [ ] Criterion 1
• Criterion 2 ## Blocked by - A reference to each blocking ticket, or "None — can start immediately". In either form, avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.