mattpocock-to-spec-to-tickets
mattpocock/to-spec → to-tickets
Two skills that turn a finished conversation into a published spec, then a graph of tracer-bullet tickets.
to-spec: Do NOT interview the user; just synthesize what you already know. to-tickets: Break a plan, spec, or conversation into a set of tickets: tracer-bullet vertical slices, each declaring the tickets that block it. implement-spec then builds the graph.
Who it is for
You have already grilled the idea (or charted it with wayfinder) and want it on the tracker as work an agent can grab.
What you get
One spec issue, N ticket issues (or .scratch files) with blocking edges, all labelled ready-for-agent.
Talk First, Then Write It Down Once
Both skills refuse to start from nothing: they synthesize what the conversation already holds.
This skill takes the current conversation context and codebase understanding and produces a spec.
Work from whatever is already in the conversation context.
"Make the change easy, then make the easy change."
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
A Spec Is The What; Tickets Are A Task Graph
Seams
The fewer seams across the codebase, the better - the ideal number is one.
Tracer bullets
Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer
Size
Each slice is sized to fit in a single fresh context window
Graph
The tickets are not a list of steps. They are a task graph with blocking relationships between them.
## Problem Statement ## Solution ## User Stories (a LONG, numbered list) ## Implementation Decisions ## Testing Decisions ## Out of Scope ## Further Notes
The to-spec template headings.
Spec, Tickets, Then Code
Click a part. Quotes are checked against the file named under each.
One Conversation Becomes A Merged Branch
- grill Talk it through
grill-with-docs or a finished wayfinder map
- /to-spec Publish the spec
template + ready-for-agent
- /to-tickets Publish the graph
quiz, then blockers first
- /implement-spec Build in parallel
worktrees + tdd + merger + code-review
Where The Text Disagrees With Itself
From reading every file at 5beb35b. No scripts ship, and nothing was run against a live tracker.
Gap README says to-spec quizzes you
The README’s workflow list says quizzes you about which modules you're touching before creating a spec, but its own skill list says No interview, just synthesizes what you've already discussed. The skill sits between: no interview, one seam check.
Gap ready-for-agent may not exist
Both skills apply ready-for-agent, but setup only writes the label vocabulary in Section B, and only when the triage skill is installed. Without it the label may be missing on your tracker.
Gap “tracker doc’s operation” for sub-issues
to-tickets says to make each ticket a sub-issue via the tracker doc, but only the GitHub tracker doc defines a sub-issue operation; the GitLab and local docs do not.
Cost Context-window sizing is a judgment call
“A single fresh context window” is not measured; size slices by feel or borrow wayfinder’s 100K-token yardstick.
Copy No file paths in specs
Specs and tickets stay valid while code moves. Prototype snippets are the only allowed exception.
pstack Covers What Happens Inside Each Ticket
| pstack skill | What pstack says it does | How it pairs |
|---|---|---|
architect | “Sketch types, signatures, and module structure before code” | Run before to-spec to settle Implementation Decisions as real types. |
blast-radius | “Find what a change could break somewhere else before it ships” | Sizes expand–contract batches; to-tickets even uses the phrase “blast radius”. |
tdd | “Use only when the user explicitly asks for TDD” | implement-spec’s implementers call Matt’s tdd; pstack’s is narrower and opt-in. |
interrogate | “Multiple LLM reviewers challenge changes from independent angles” | A heavier swap for the final code-review step. |
create-verification-skill | “Generate a project-local verification skill that drives your app the way a user does” | Gives “demoable or verifiable on its own” a real check. |
“the single most important skill that should be in your toolkit is verification”Lauren Tan (poteto), stream with Matt Pocock, 16:14
Set Up The Tracker First
- skills/engineering/to-spec/SKILL.md
- skills/engineering/to-tickets/SKILL.md
- skills/engineering/implement-spec/SKILL.md
- skills/engineering/setup-matt-pocock-skills/triage-labels.md
- mattpocock/setup-matt-pocock-skills: all three need it
- mattpocock/wayfinder: produces the decisions a spec synthesizes
- github.com/mattpocock/skills: the repo and its README
- skills.sh/mattpocock/skills: install counts per skill
- Inside pstack: the pstack explainer on this site
- Matt Pocock with poteto, live: the stream quoted here