How is it different from just prompting an agent?

A prompt lives in one session. A spec is an artifact: it is reviewed, it is version controlled, it is reused across sessions and agents, and the work can be verified against it. That is what makes it usable by more than one person.

What tools do spec-driven development?

GitHub Spec Kit, AWS Kiro, OpenSpec and BMAD-METHOD are the open toolkits most teams try. They differ in shape: Spec Kit and Kiro run a fixed phase order, OpenSpec works in change folders on existing code, BMAD sizes the process to the change.

Does spec-driven development mean waterfall?

It can slide that way. Reviewers have reported thousands of lines of generated markdown for a single feature, and Thoughtworks put the technique at Assess in November 2025 partly for that reason. Keeping the spec small, and writing it with the people who will review the result, is what stops it.

How does a team do spec-driven development together?

Agree on the intent before generating anything, keep one artifact per change rather than a spec per person, give every task acceptance criteria someone can check, and make sure each agent starts from the agreed version. That is the part the single-player toolkits leave to you.

Concept

Spec-driven development, and what changes when a team does it

Spec-driven development means writing a specification of what to build and why, then having an AI coding agent work from that spec instead of from a prompt. The spec is the source of truth: it is reviewed, kept in version control, and the finished code is checked back against it. GitHub's own framing when it released Spec Kit was the move "from code is the source of truth to intent is the source of truth".

On your own, that is a discipline. With two or more people it becomes a coordination problem, and that is where most of the toolkits stop.

The loop

The tools differ in naming, but the loop is the same in all of them:

IntentWhat to build and why, in words a person can argue with. No code yet.
ClarifyThe unresolved questions get answered and written back into the spec, not left in a chat.
PlanHow it will be built: the approach, the constraints, the shape of the change.
TasksThe plan broken into pieces small enough to build and check, in an order that works.
BuildThe coding agent works through the tasks.
VerifyThe result is checked against the spec, and the spec is updated when reality changed.

Birgitta Böckeler's survey on martinfowler.com sorts the practice into three levels that are worth knowing before you pick a tool: spec-first, where the spec is written up front and may be thrown away; spec-anchored, where it is kept and evolved; and spec-as-source, where people edit only the spec and the code is generated from it.

The tools people try

Tool	Shape	What it writes
GitHub Spec KitOpen source (MIT), installs its commands as agent skills, supports 40 named agents.	A fixed order: constitution, specify, clarify, plan, checklist, tasks, analyze, implement, converge.	A constitution, then per feature a numbered folder with spec.md, plan.md, tasks.md and checklists.
AWS KiroTied to its own editor.	Three phases: requirements, design, tasks.	requirements.md, design.md and tasks.md per spec, inside the Kiro IDE.
OpenSpecOpen source, installed with npm.	Change folders rather than locked phases, aimed at existing code.	A proposal, delta specs, design and tasks per change; archiving merges the deltas into the main specs.
BMAD-METHODOpen source (MIT), installed as skills.	Agent roles and a process sized to the change, from direct implementation to deeper planning.	Documents per role, held in the repo.

Spec Kit is the one most teams meet first. Our page on running GitHub Spec Kit with a team goes through its command flow and the places teams get stuck.

What breaks when more than one person is involved

These are not hypotheticals. They are the questions teams file against the toolkits themselves.

Two people, one numberSequentially numbered spec folders collide when two engineers start a feature on the same day, and the merge conflict lands in the spec itself.
Nobody owns the specWhen several people edit one spec, the toolkits leave the process to you: a shared branch, pull requests, and an agreement about who decides.
Review loadOne reviewer measured 2,577 lines of generated markdown for a single feature, and three and a half hours of review, against about fifteen minutes when working iteratively.
Two sources of truthA constitution in the toolkit and a CLAUDE.md or AGENTS.md in the repo drift apart, and each agent reads a different one.
Tasks marked done that were notChecklists get ticked while the code holds a placeholder, which only a check against the spec catches.
More than one repoA change that spans services has no single place to live.

Thoughtworks put spec-driven development at "Assess" in November 2025, warning that the workflows are elaborate and the spec files hard to review. That is the honest state of the practice: worth doing, not yet solved.

Running it as a team, in Hamster

Hamster keeps the same loop and moves the artifacts to where a team can share them. The intent is a Brief the team edits, reacts to and agrees on, with the decision trail attached. The Plan is generated from the agreed Brief: scoped tasks, dependencies, and acceptance criteria per task. Technical specs attach to the Brief they belong to, so the spec and the reason for it stay together.

From there the work goes to whichever agent each person uses. hamster sync writes the Briefs and Plans into .hamster/ in the repo and generates a project-context skill, so Claude Code, Cursor, Codex, Gemini CLI and Copilot all start from the same agreed version. An MCP server does the same for tools that prefer it. The pull request is then reviewed against the acceptance criteria the team wrote, and a Routine can check that the work matches them.

Your existing method still applies. Spec Kit, BMAD or your own house process can live in Hamster as a Method with its Skills, so the team runs the process it already chose, together, instead of each person running it alone.

Get started free Get started free See how it works

Free for 10 Briefs a month. Unlimited free viewer seats, pay only for creators.

Questions people ask

What is spec-driven development?: Spec-driven development is writing a specification of what to build and why, then having an AI coding agent work from that spec instead of from a prompt. The spec, not the chat history, is the source of truth, and the code is checked back against it.
How is it different from just prompting an agent?: A prompt lives in one session. A spec is an artifact: it is reviewed, it is version controlled, it is reused across sessions and agents, and the work can be verified against it. That is what makes it usable by more than one person.
What tools do spec-driven development?: GitHub Spec Kit, AWS Kiro, OpenSpec and BMAD-METHOD are the open toolkits most teams try. They differ in shape: Spec Kit and Kiro run a fixed phase order, OpenSpec works in change folders on existing code, BMAD sizes the process to the change.
Does spec-driven development mean waterfall?: It can slide that way. Reviewers have reported thousands of lines of generated markdown for a single feature, and Thoughtworks put the technique at Assess in November 2025 partly for that reason. Keeping the spec small, and writing it with the people who will review the result, is what stops it.
How does a team do spec-driven development together?: Agree on the intent before generating anything, keep one artifact per change rather than a spec per person, give every task acceptance criteria someone can check, and make sure each agent starts from the agreed version. That is the part the single-player toolkits leave to you.

Sources

Checked September 15, 2026.