Ticket Work

---
name: ticket-work
description: The seven-step sequence for ticket-granularity work: implementing a component, fixing a non-trivial bug, refactoring a module, adding a feature. Invoke at the start of such work.
---

# Ticket work

1. **Clarify.** Resolve ambiguous acceptance criteria or constraints from the codebase, the assets, or git history. If that fails, ask **one** question, whichever ambiguity blocks the most work. One question, never a list of them.
2. **Judge the design.** Creative or architectural work (new UI, a new pattern, a choice between credible alternatives) is proposed with its alternatives and implemented only after the user approves.
3. **Plan.** One sentence of goal, the files to create or edit with one line each, the acceptance criteria, and the verification commands (`bun run check` / `bun run test` / build / manual smoke test, as applicable). Enter plan mode when the user asked for a plan.
4. **Check the interaction, when it is complex.** Wizards and multi-step forms, auth or session flows, async guards, permission branching: lay out the states, the initial one, the actions as guarded transitions, the invariants that must hold, and the flows that must never happen. Then attack it. Hunt a path whose every guard holds and that still breaks one of them, and a sequence of individually-allowed actions whose combination reaches an effect the design would refuse if asked for it directly: a required step skipped, one action replayed for a second effect, a privileged state entered by a route nobody weighed, an authority kept after it was revoked. The moves that find these: back, reload, cancel, retry, double-submit, a second tab, and a session or permission change mid-flow. An action you cannot place is a gap in the design, not licence to assume one. Fix the design before implementing.
5. **Implement.** The parent implements directly, and delegates only to keep an investigation's raw output out of its context, or to run independent units at once. The tests that go with what you add follow AGENTS.md's Testing section. When debugging, reproduce the failure and check what changed recently before forming a hypothesis, then test that hypothesis with the smallest possible change. Never try changes to see which one sticks.
6. **Self-check.** Read the full diff. Run `bun run check` and `bun run test`, fixing every error. Confirm step 3's acceptance criteria, reading the diff yourself for anything a subagent implemented rather than its summary.
7. **Review, then commit.** Dispatch the `code-reviewer` agent on the uncommitted diff, telling it what changed and why, what is out of scope, and what you are least sure of. Apply the fix each finding returns, and ask the user where one needs a decision. Then propose the commit split and wait for the user.