to-tickets

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From lynchypin/project-onboard, MIT.

More from lynchypin/project-onboard