You know the failure mode. You ask an agent to build something. It starts writing files immediately. Half your requirements never make it into the code. The other half get "interpreted" into whatever pattern was common in the training data.
That pattern has a name now: vibe coding. GitHub's open-source Spec Kit is the loudest attempt to kill it. The repo has crossed well past 100K stars (digest said 95K; docs now show 121K+). MIT licensed. Works with 30+ coding agents including Copilot, Claude Code, Cursor, Codex, and Gemini CLI.
The core idea is almost boring, which is why it works. Force the agent to understand what you want before it touches implementation.
Spec-Driven Development in plain English
Spec Kit treats the specification as a living artifact that drives the rest of the process. Your job is to steer and verify. The agent's job is to draft the heavy text and then implement small, checkable chunks.
The default flow:
- Constitution (
/speckit.constitution): project rules, standards, non-negotiables - Specify (
/speckit.specify): what you're building and why, focused on user journeys, not frameworks - Clarify (
/speckit.clarify): the agent asks questions before it invents answers - Plan (
/speckit.plan): stack, architecture, constraints - Tasks (
/speckit.tasks): ordered, reviewable units of work - Implement (
/speckit.implement): build task by task against the locked plan
Older GitHub blog posts describe a shorter Specify → Plan → Tasks → Implement loop. The constitution and clarify steps are the maturity upgrade. They catch the two places agents usually hallucinate: unspoken team norms and ambiguous product intent.
| Step | Slash command | What locks in |
|---|---|---|
| Constitution | /speckit.constitution | Team rules and non-negotiables |
| Specify | /speckit.specify | User journeys, not frameworks |
| Clarify | /speckit.clarify | Ambiguities asked before invented |
| Plan | /speckit.plan | Stack, architecture, constraints |
| Tasks | /speckit.tasks | Ordered, reviewable units |
| Implement | /speckit.implement | Build against the locked plan |
Why this spreads when "just write a PRD" never did
Teams have always had docs. Agents ignore docs that aren't in the critical path. Spec Kit wins because the markdown artifacts are the interface the agent is trained to consume at each step. Each phase feeds the next file. Context is structured instead of "here's a Notion page, good luck."
It also matches how strong human seniors already work. You don't let a junior open a PR titled "stuff" after one Slack message. You align on the problem, constraints, and sequencing. Spec Kit is that discipline encoded as slash commands.
There's a second reason for the star count: agent fatigue. People got burned by impressive demos that collapsed on real codebases. A toolkit that slows the agent down feels like relief, not bureaucracy.
How to try it without boiling the ocean
Install path from the docs:
uv tool install specify-cli specify init my-project --integration copilot
Or the older one-liner still floating around:
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
Then run the slash commands inside your agent of choice. Practical tips from using this style of workflow on client work:
- Start with a thin vertical slice, not the whole product vision.
- Put auth, data ownership, and "what happens when the API fails" into clarify answers explicitly. Agents love happy paths.
- Keep tasks small enough to review in one sitting. "Build authentication" is a wish. "Add email registration endpoint with format validation and tests" is a task.
- Revisit the spec when reality changes. A frozen wrong spec is worse than vibe coding.
| Approach | What happens first | Failure mode |
|---|---|---|
| Vibe coding | Agent writes files immediately | Half the requirements never land |
| Spec Kit | Spec → plan → tasks → implement | Overhead on one-line fixes (skip it there) |
When Spec Kit is overkill
Not every change needs a constitution ceremony.
Skip the full ritual for:
- One-line fixes and obvious refactors
- Throwaway prototypes where learning speed beats correctness
- Exploratory spikes where you genuinely don't know the shape yet
Use it when:
- Multiple agents or teammates will touch the same feature
- Requirements are fuzzy and stakeholders disagree
- You're integrating with legacy systems or compliance constraints
- You've already watched an agent "finish" a feature that missed the actual job to be done
The community ecosystem (extensions, presets, alternate workflows) is growing fast. That is both power and noise. Start with the core SDD path before installing half the catalog.
How this pairs with multi-agent tools
Antigravity 2.0, Claude Code subagents, and Cursor Cloud Agents all make it easy to parallelize work. Parallelism without a shared spec is how you get four conflicting implementations of the same button.
Spec Kit is the serialization layer in front of the fan-out. Specify and plan once. Then let tasks run in parallel where the graph allows. If your team is adopting multi-agent desktops, put SDD upstream or you'll spend your week reconciling PRs.
Takeaway
Spec Kit's popularity is a market signal. Developers don't just want faster codegen. They want control over intent. The winning agent stacks in 2026 will look less like autocomplete on steroids and more like structured workflows with checkpoints humans actually use.
If you're wiring Spec-Driven Development into an applied AI delivery process (or trying to stop agents from shipping confident nonsense), book a free discovery call. Happy to compare notes on what holds up in production.