Goal: decompose a product/engineering document into a high-level, product-oriented list of tickets, prioritized and dependency-aware, that can be created verbatim in an external tracker (Linear, GitHub Issues, Jira).
The output of this skill is intended to leave the repo. Tickets describe what to ship in product terms, not how to engineer it.
When to use this vs /create-implementation-plan
Both skills break work down, but they answer different questions for different audiences.
| Aspect | /create-tickets |
/create-implementation-plan |
|---|---|---|
| Question | What shippable units of work make up this thing? | How will we build this one thing, step by step? |
| Audience | Product + engineering | Engineering |
| Granularity | High-level, product-oriented, backlog-sized | Granular, task-by-task, file-aware |
| Scope | The whole feature, decomposed | A single ticket, planned |
| Destination | External tracker (Linear, GitHub Issues, Jira) | Stays in .specs/ |
| Sequence | Priority + declared dependencies | Phases, vertical slices, tracer bullet |
Typical flow: run /create-tickets first to decompose the feature into tickets the team can prioritize and import into a tracker. Then, for any ticket that warrants it, run /create-implementation-plan to plan that ticket's execution before building.
Routing
- Define product requirements →
/create-prd - Propose or decide on a change →
/create-rfc - Document architecture →
/create-technical-design - Plan a single ticket's execution →
/create-implementation-plan - Build the code for a ticket →
/implement
Process
Step 1 — Receive source and feature slug
Take the explicit path to the source document (PRD, RFC, TD, or similar). This skill never invents requirements — if no source path was provided, ask for one before doing anything else.
Derive the feature slug:
- If the source lives under
.specs/[slug]/..., reuse that slug. - Otherwise, ask the user for the feature slug.
The output always lives at .specs/[slug]/TICKETS.md regardless of where the source document came from. Create the directory if it does not exist.
Step 2 — Read the source end-to-end
Read the entire source document before decomposing anything. Extract:
- Discrete shippable units of work.
- Priorities, if the source uses P0/P1/P2 or an equivalent labelling.
- Dependencies and sequencing constraints stated or implied by the source.
- Acceptance signals — anything the source says about how to know a piece is done.
- Scope boundaries — anything explicitly out of scope.
Never invent work the source did not call for. This skill decomposes; it does not expand scope.
Step 3 — Lightweight interview (gaps only)
Use AskUserQuestion only when the source genuinely does not provide enough to decompose. Common gaps:
- Granularity — when the right ticket size is ambiguous (e.g. "should auth be one ticket or three?").
- Priorities — when the source has none.
- Acceptance signals — when a piece of work has no observable outcome stated.
Skip whatever the source already answers. Do not run a fixed questionnaire — ask only the questions that block decomposition.
Step 4 — Decompose
Apply the decomposition rules below. Produce one ticket per shippable unit of work.
Step 5 — Sort, number, validate, write
- Sort tickets by priority (P0 → P1 → P2).
- Within a priority, order so that a ticket appears before any ticket that depends on it.
- Assign in-file reference numbers (
#1, #2, …) in this final order. - Validate against the checklist below.
- Write
.specs/[slug]/TICKETS.mdusing the template below.
Step 6 — Summarize
Print the output summary.
Decomposition Rules
- One outcome per ticket. No "AND" in titles. Split anything that bundles outcomes.
- Product-oriented, shippable units. A ticket is something a PM or EM could place on the backlog. Avoid task-level granularity (file-by-file edits, refactor steps) — that belongs in the per-ticket implementation plan.
- Verifiable acceptance criteria. Each AC item is pass/fail and observable.
- Independently shippable once dependencies are met. Declare dependencies as in-file references (
#1,#3) using the final sorted numbering. - Vertical slices when they fit, infrastructural tickets when they don't. Prefer end-to-end user-visible slices, but tickets like "Provision database schema" or "Set up auth provider" are valid when downstream tickets genuinely depend on them. Judgment call — do not force vertical slicing onto work that does not fit.
- Inherit priority from the source when stated; otherwise infer and surface for confirmation in Step 3.
- No internal ID scheme. The tracker will assign the canonical ID on import. The in-file
#Nreferences exist only for navigation withinTICKETS.md.
TICKETS.md Template
# Tickets — [Feature Name]
| Field | Value |
| ------------- | ------------------------------ |
| Source | [path to PRD/TD/RFC] |
| Feature slug | [slug] |
| Total tickets | N |
| Created | YYYY-MM-DD |
> Tickets are sorted by priority (P0 → P1 → P2), then by dependency order.
> Reference numbers (`#N`) are for in-file navigation only — the tracker will assign canonical IDs on import.
## Tickets
### #1 — [Imperative title]
- **Priority:** P0
- **Depends on:** none
**Description**
[1–3 sentences. User-story form when applicable; plain prose when infrastructural.]
**Acceptance Criteria**
- [ ] [Verifiable outcome]
- [ ] [Verifiable outcome]
---
### #2 — [Imperative title]
- **Priority:** P0
- **Depends on:** #1
**Description**
[…]
**Acceptance Criteria**
- [ ] […]
Validation Checklist
Before writing the file, verify:
- Source document was read end-to-end, not skimmed.
- Every ticket has a title, priority, description, and at least one acceptance criterion.
- No title contains "AND".
- Every
Depends onreference resolves to an existing in-file number. - Tickets are sorted by priority, then by dependency order.
- Numbering (
#1, #2, …) is sequential and matches the final sorted order. - No ticket invents work absent from the source document.
- No ticket reads like engineering tasks (file edits, refactor steps) better suited to
/create-implementation-plan.
Common Anti-Patterns
Bundled tickets
- Wrong: "Build auth API and login UI."
- Right: Two tickets — "Add login API endpoint" and "Add login UI."
Engineering tasks disguised as tickets
- Wrong: "Refactor the user service to use the new auth client." — belongs in an implementation plan.
- Right: "Allow users to sign in with Google." — product-level outcome.
Unverifiable acceptance criteria
- Wrong: "Login works well."
- Right: "User with valid credentials is redirected to /dashboard within 1 second."
Inventing work the source did not call for This skill decomposes; it does not expand scope. If the source PRD says nothing about analytics, do not add an analytics ticket.
Everything is P0 If every ticket ends up P0, the priorities are not being used. Push back to the user when the source forces an all-P0 outcome.
Forcing vertical slices If the source legitimately requires foundational wiring before any user-visible work is possible, an infrastructural ticket is the honest answer. Do not synthesize a fake user-facing slice just to satisfy a slicing rule.
Output Summary
After generating, print:
Tickets created: "[Feature Name]"
File: .specs/[slug]/TICKETS.md
Total: N tickets (P0: X, P1: Y, P2: Z)
Source: [path to source doc]