Spec Kit tells you how to write a spec. It doesn’t tell you what goes in one.
Spec-driven development fixed the handoff to the coding agent. It didn’t fix the input. This is where the spec’s content comes from — evidence, instead of whatever you happened to believe on Tuesday.
- Steps
- 5
- Tools
- 6
- Metrics
- 3
- Read
- 4 min
A technical founder running the Specify → Plan → Tasks → Implement loop with Claude Code. Shipping faster than ever, and quietly unsure whether any of it is the right work.
Composite blueprint. This is the loop and the wiring — assembled from workflows our early design partners run — not a single named customer’s audited results. Every number on this page is a metric to instrument, not a result we’re claiming.
What the week looked like
Spec-driven development genuinely worked. Same spec, same result, far less rework — the agent stopped improvising.
But /specify starts from a blank prompt, and whatever went into it was the ceiling on everything downstream.
So the specs were beautifully structured descriptions of my own assumptions. Well-planned, well-tested, well-implemented guesses.
Six weeks of clean features nobody had asked for. The process was not the problem — the input was.
The spec arrives with its reasoning already done: clustered from real signals, with the quotes attached. Spec Kit runs exactly the same loop. It just stops starting from a blank prompt.
The tools this loop runs on
Native connectors where they exist, and an honest label where they don't — anything else reaches Specky over MCP, the REST API, or an automation hop.
Signals in, theme out, approved spec with citations. The layer that runs before /specify.
Seed /specify with the approved Specky spec instead of typing a fresh description. Its Plan → Tasks → Implement stages are unchanged.
Complementary, not competing — it holds how you build here. Specky holds what’s worth building. Both belong in the agent’s context.
Reads the approved spec and its evidence over MCP, so the context is a tool call rather than a paste.
Same server, same spec. Running both against one spec is a cheap test of whether the spec is actually specific.
Merged work syncs back and attaches to the opportunity it came from, so next month’s spec is written against a longer history.
How it actually runs
Every step is labelled by who does it. The steps marked 'you review' are the ones worth keeping human.
The signals arrive without you
AutomaticSupport threads, calls, reviews, and analytics land in the graph continuously. Nothing here is a spec yet — this is just the raw material that a blank /specify prompt does not have access to.
Specky does the part Spec Kit doesn’t
AgentCluster the signals, score the opportunity against everything else on the board, and draft the problem statement with each claim cited. This is the work spec-driven development assumes you’ve already done offline.
You approve the problem, not the prose
You reviewThe judgement call is whether this is worth a week. That stays human. Everything before it was retrieval and everything after it is execution — this is the only step that needs you.
/specify starts from evidence
AgentFeed the approved Specky spec into Spec Kit’s Specify stage — pasted, piped, or read over MCP. Plan, Tasks, and Implement run exactly as before. The difference is upstream and it changes everything downstream.
The merge writes itself back
AutomaticShipped work attaches to the opportunity that produced it, and the outcome becomes evidence for the next spec. Spec Kit gives you a repeatable process; the graph is what makes the process compound.
The numbers to watch — not the ones we'd like to quote
We're not going to invent a percentage for you. These are the three metrics that tell you whether the loop is real, and how to compute each one from data the graph already holds.
Specs whose problem statement cites a customer
The number you’d be comfortable reading aloud
Cited problem statements ÷ total specs. If it’s low, spec-driven development is making you efficient at building your own assumptions.
Rework rate after merge
Falling, not just stable
Merged PRs that get materially reverted or reworked within 30 days. Spec Kit already cuts the implementation half of this; evidence cuts the other half — the reworks caused by specifying the wrong thing correctly.
Shipped features with no usage after 30 days
The most uncomfortable number on this page
Join your analytics to the opportunity each feature came from. Most teams never compute it, which is exactly why it stays high.
Start here, not everywhere
Keep Spec Kit exactly as it is
Nothing about the Specify → Plan → Tasks → Implement loop changes. This is a change to what you paste into the first stage, not a replacement for any stage.
Connect one signal source before your next spec
Support desk or issue tracker is enough to start. One connected source means your next problem statement can cite something, which is the whole point and takes an afternoon.
Let the agent read the spec rather than carrying it
Point Claude Code or Codex at Specky’s MCP server so it can follow a citation to the source when the spec is ambiguous. A spec you can interrogate beats a spec you pasted.
https://www.specky.space/api/mcpClaude Code · Codex · Cursor · Claude Desktop · ChatGPT · n8n
Frequently asked questions
Does this replace Spec Kit?+
No, and it would be a worse product if it tried. Spec Kit solves the structure and sequencing of a spec, which is a genuinely hard problem it solves well. Specky solves what belongs in one. They’re adjacent layers, and the combination is stronger than either — use both.
Isn’t this just “put the PRD in the prompt”?+
Mechanically, yes — and that’s the point, it’s not a new workflow to learn. What changes is provenance: the PRD was assembled from real signals rather than typed from memory, each claim links to the source, and the agent can follow those links mid-implementation instead of guessing at intent.
How does this relate to AGENTS.md?+
Different axis, no overlap. AGENTS.md tells an agent how you build here — conventions, commands, structure. Specky tells it what’s worth building and why anyone asked. Both belong in the agent’s context and neither substitutes for the other; a repo with perfect conventions still ships the wrong feature.
Run this loop on your own product.
One source, one agent, one approval gate. You’ll know inside a week whether it holds.
14-day free trial · No credit card required · Cancel anytime