blockscout To tickets
Break a spec into a set of tickets: tracer-bullet vertical slices, each declaring the tickets that block it. Its input is the spec and open questions.
The ticket model is defined in ../../tasks/concepts.md. Layout and file ownership
are in ../../tasks/structure.md. This skill carries the steps only.
Feasibility is the forcing function. Every gap you hit here — a requirement the spec never pinned, an executor question the spec can't answer — is a gap that spec should have closed. Ask the developer to fill it and note it, rather than guessing.
Step 1 — Load
Resolve the task folder from the issue number or the branch (issue-<number>), and read its spec.md,
questions.md and .agents/delegation.md.
Step 2 — Explore the codebase (optional)
If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect CONTEXT.md in the area you're touching.
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
Step 3 — Draft slices
Break the work into tracer bullet tickets.
- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — a vertical slice.
- A completed slice is demoable or verifiable on its own
- Each slice is sized to fit in a single fresh context window
- Any prefactoring should be done first
Give each ticket its Blocked by edges — the blockers that must clear before it can start, each prefixed by
kind: T<NN> for a ticket that must complete first, Q<NN> for an open question that must be answered
first. A ticket with no blockers can start immediately.
Defer what can't be scoped. A ticket blocked on a prototype, a spike, or an answer nobody has yet gets a brief.md and no spec.md; a later to-tickets run scopes it — writing its spec.md, or a fresh brief.md if it still can't be scoped.
Step 4 — Quiz the user
Present the proposed breakdown as a numbered list. For each ticket, show:
- Title: short descriptive name
- Blocked by: which other tickets (if any) must complete first
- What it delivers: the end-to-end behaviour this ticket makes work
Ask the user:
- Does the granularity feel right? (too coarse / too fine)
- Are the blocking edges correct: does each ticket only depend on the tickets and questions that genuinely gate it?
- Should any tickets be merged or split further?
Iterate until the user approves the breakdown.
Step 5 — Front-load the executor inputs
For every [agent] leaf that runs a project skill (add-new-page, add-api-resource, add-env-var, …),
open that skill and run its user-facing interview now, against the spec — from the skill's current text,
not from memory of its questions (e.g. add-new-page Step 0). Record the answers in the ticket's Skill
inputs section, grouped by skill. Where the spec answers a question, take the answer from it and move on;
where it has a genuine gap, ask the developer. This is what lets the later implement-ticket run go
uninterrupted.
Step 6 — Write the files
Per approved ticket, write tickets/NN-<slug>/spec.md from ticket-template.md — What
to build, Acceptance criteria (tagging (human) per the ticket model), the Skill inputs from Step 5, the
Leaf worklist with each leaf tagged [agent] / [human] per .agents/delegation.md, and the header's
Blocked by edges (T<NN> / Q<NN>). A ticket that can't be scoped gets a brief.md instead — its goal,
the known context, and the blocking unknowns with their owners.
Create (or append to) progress.md from progress-template.md — one checkbox line
per ticket. When scoping a deferred ticket, append its siblings and retarget the Blocked by edges that
pointed at the deferred one; never renumber, never nest.