To-tickets

Tracer-bullet vertical slices, not horizontal layers. Each ticket should be independently implementable and deliver end-to-end behavior, even if narrowly. Never "build the database layer" → "build the API" → "build the UI" as three tickets that are each individually useless.

The principle: make the change easy, then make the easy change. If a ticket requires prefactoring, that prefactoring is its own ticket listed as a blocker.

Process

1. Read the spec (or CONTEXT.md summary for script-tier) and .agent/state.json for the doc tier and issue tracker.
2. Gather context. Fetch referenced materials, explore the codebase to understand where changes land.
3. Break the work into tracer-bullet slices. Each slice:
   • Sized to one context window — small enough to implement and review inside a single fresh context, before the window fills and attention degrades (see the "Smart zone" note in reference/context-budget.md). One ticket ≈ one context window is the sizing rule, not a rough guideline. If a slice can't plausibly be finished and reviewed before a context reset, it's too big — split it.
   • Complete enough to demo or verify on its own.
   • Ordered with explicit blocking dependencies.
4. Special case — wide refactors. Use expand-contract:
   • Expand: add the new form alongside the old.
   • Migrate: batch changes by blast radius (smallest first).
   • Contract: remove the old form once no references remain.
5. Match granularity to tier:
   • Script / tool: flat list, dependencies rarely matter.
   • App / system: explicit dependency tracking (B depends on A).

6. Write tickets to the configured tracker (issue_tracker in state.json): local files in docs/agents/tickets/, or via GitHub/ Linear. Each ticket includes:

   • Title
   • Description of end-to-end behavior delivered
   • Acceptance criteria
   • Blocking dependencies (if any)

   Each ticket is self-contained — restate context rather than assuming the reader has the spec open.

7. Present the breakdown to the user — what each slice does, in what order, and why. If risk_posture is "careful", explicitly note that implementation will pause after each ticket for confirmation.
8. Hand off to wayfinder's implementation orchestration — it will invoke skills/implement/SKILL.md per ticket, respecting risk posture.

What this skill must never do

• Never produce horizontal-layer tickets where intermediate tickets don't independently do anything verifiable.
• Never silently reorder or drop a slice without flagging it.
• Never start implementation itself — hand off to wayfinder.