cut-tickets
Installation
SKILL.md
Cut tickets
A ticket is a promise someone else can check. Cut them so each one is a complete, narrow path through every layer, demoable or verifiable on its own, and so the set as a whole has a frontier: the tickets whose blockers are done.
The rules
| Id | Rule | In practice |
|---|---|---|
| TICKET-1 | One ticket per real work item | Never one per checklist step. A vertical slice through schema, API, interface and tests, sized to one working session (one fresh context window for an agent). Any prefactoring goes first. |
| TICKET-2 | Acceptance and blockers | What to build from the user's perspective, acceptance criteria someone else can check, the tickets that block it. Native dependency links where the tracker has them; a "Blocked by" line otherwise. |
| TICKET-3 | No identifiers, secrets or names | No infrastructure identifiers, secret paths, partner URLs or colleagues' names. Describe the step and point to the internal runbook. The owner is a team or role. |
| TICKET-4 | Full links | Every reference to another change or ticket is a full link, never a bare number. |
| TICKET-5 | Approval before publishing | Show the breakdown as a numbered list: title, blocked by, what it delivers. Ask about granularity, blocking edges, merges and splits. Publish only after approval, and publishing is a post (ASK-3); on publish, apply the tracker's ready-for-agent label unless told otherwise (docs/agents/tracker.md). The parent item is never closed or edited by the breakdown. |
| TICKET-6 | Wide refactors use expand and contract | A mechanical change that breaks thousands of call sites at once cannot be a slice. Expand (add the new form beside the old), migrate in batches sized by blast radius, contract (delete the old form). Each batch its own ticket, blocked by the expand; the contract blocked by every batch. |