To tickets plus

To Tickets Plus

Break a plan, spec, or conversation into tickets — tracer-bullet vertical slices, each declaring the tickets that block it.

Pipeline position: to-spec-plus (record) → to-tickets-plus (slice) → implement-plus (build one ticket per session).

Process

1. Gather context

Work from whatever is already in the conversation. If the user passes a reference (a spec path, an issue id or URL), fetch it and read its full body and comments.

2. Explore the codebase

If you haven't already, explore to understand the current state. Ticket titles and descriptions use the project's domain vocabulary (CONTEXT.md/glossary if present) and respect ADRs in the area.

Look for opportunities to prefactor — restructure first so the feature lands cleanly. "Make the change easy, then make the easy change." Prefactors become the first tickets.

3. Draft vertical slices

Break the work into tracer bullet tickets:

• Each slice cuts a narrow but COMPLETE path through every layer it needs — for a typical Laravel feature: migration → model/factory → behavior (controller / FormRequest / action / job / Livewire / Filament) → route → feature test. Vertical, never a horizontal slice of one layer ("all migrations", "all the tests").
• A completed slice is demoable or verifiable on its own — a route you can hit, a command you can run, a test you can watch pass.
• Each slice is sized to fit one fresh agent session.
• Prefactoring tickets come first.

Give each ticket its blocking edges — the tickets that must complete before it can start. A ticket with no blockers can start immediately.

Wide refactors are the exception to vertical slicing. A wide refactor is one mechanical change — rename a column, retype a shared value object — whose blast radius fans across the codebase so no vertical slice can land green. Sequence it as expand–contract:

1. Expand — add the new form beside the old so nothing breaks (new nullable column + dual-write; new method delegating to old).
2. Migrate — move call sites/data over in batches sized by blast radius (per module, per directory), each batch its own ticket blocked by the expand. A data backfill is its own ticket — a one-time operation leaving no permanent infra.
3. Contract — drop the old form once no caller remains, in a ticket blocked by every migrate batch. The contract migration is the only destructive step and lands last.

When even batches can't stay green alone, keep the sequence but share an integration branch, all blocking a final integrate-and-verify ticket — green is promised only there.

4. Approve the breakdown

Present the proposal as a numbered list — per ticket: Title, Blocked by, What it delivers (the end-to-end behavior it makes work).

Then put the review through AskUserQuestion rather than an open-ended "thoughts?":

• Granularity — right-sized (recommended, if you believe it) / too coarse, split more / too fine, merge some.
• Blocking edges — correct / over-constrained (tickets could parallelize) / missing edges.
• Follow-ups per adjustment the user picks, until they approve.

Iterate on the list until approved. Do not publish an unapproved breakdown.

5. Publish

Publishing creates external artifacts — do it only after step 4's approval.

Tracker fast path: follow docs/agents/issue-tracker.md if present, else an ## Issue tracker section in AGENTS.md/CLAUDE.md, else detect (Linear MCP → Linear; GitHub remote + gh → GitHub Issues; neither → local markdown) and confirm once with AskUserQuestion, offering to persist the choice.

Publish in dependency order — blockers first — so each ticket's edges reference real identifiers:

• Linear — one issue per ticket via save_issue; parentId = the spec/parent issue if there is one; blockedBy = native blocking relations; apply the ready-for-agent label.
• GitHub — one issue per ticket via gh issue create; native sub-issue/dependency APIs where available, Blocked by: #a, #b body lines where not (probe once, fall back without ceremony); apply the ready-for-agent label.
• Local markdown — one file per ticket under .scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered from 01 in dependency order. Never a single combined file.

Do NOT close or modify any parent issue.

Ticket templates

Tracker issue:

## Parent

Reference to the parent spec/issue (omit if none).

## What to build

The end-to-end behaviour this ticket makes work, from the user's perspective —
not a layer-by-layer implementation list.

## Acceptance criteria

- [ ] Behavior statements — what a user/caller can now do, what data is
      persisted, what is forbidden (authorization) — never presentation
      ("page shows heading X") or implementation ("uses a repository")

## Blocked by

- Reference to each blocking ticket, or "None — can start immediately".

Local file: same sections plus a **Status:** ready-for-agent line under the title # <NN> — <Ticket title>.

In either form, avoid file paths and code snippets — they go stale fast. Exception: a prototype-derived snippet that encodes a decision more precisely than prose (state machine, schema, enum shape); trim to the decision-rich parts.

After publishing

Work the frontier — any ticket whose blockers are all done — one ticket at a time with implement-plus, clearing context between tickets. For a linear chain that means top to bottom.