Spec-driven development and the backlog

Spec-driven development is the practice of writing a structured specification before any code, having a coding agent turn it into a technical plan and a list of tasks, and then implementing against those tasks with the spec as the source of truth. It became popular as agents took on larger pieces of work, where prompting your way through a feature one message at a time produces code that drifts from what anyone intended. AWS launched Kiro, a development environment built around specs, in July 2025, and GitHub released Spec Kit, which it called an experiment, that September.

Tools such as GitHub's Spec Kit, AWS's Kiro and the open-source OpenSpec build the workflow in. This article explains what the approach adds, how the tools implement it, how its artefacts map onto a backlog you may already have, and the decision that matters most: where the spec should live.

Recent changes

• Spec Kit moved GitHub issues into an extension. Since version 1.1.0 (October 2), the core command that turned a feature's tasks into GitHub issues is deprecated, and the opt-in github extension creates the issues instead, in dependency order. The latest release is 1.2.2, from October 19.
• Kiro added workflows. Announced on September 30 and off by default, they run a multi-agent plan in which each step starts with a fresh context. The bundled feature pipeline gathers requirements, designs and reviews a solution, writes the code with independent reviewers working in parallel, and finishes by checking the result against the original requirements.

Every tool fact on this page was checked against the vendors' own documentation on October 20, 2026; the sources are listed at the end.

What the approach adds

A spec-driven workflow separates three questions that a single prompt tends to blur.

• What and why. Requirements and user-facing behaviour, written without reference to the implementation.
• How. A technical plan: the architecture, the data model, the interfaces, the constraints.
• In what order. Tasks small enough to implement and check one at a time.

The agent works through the tasks, and the spec stays the reference it is checked against. Spec Kit's quickstart puts the first rule plainly: "Focus on the what and why, not the tech stack." The discipline is not new; it is the separation between requirements, design and work items that good backlogs have always had. What is new is that the reader of all three documents is now often an agent, which follows them more literally than a person would.

How long the spec matters varies. In her survey of the tools, Birgitta Böckeler distinguishes three levels: spec-first, where a spec guides the task in hand; spec-anchored, where the spec is kept and used to evolve the feature afterwards; and spec-as-source, where people edit only the spec and never the generated code. Most teams start spec-first. Whether you can go further depends on where the spec lives, which is the decision at the end of this article.

How the tools implement it

GitHub Spec Kit is an open-source, MIT-licensed toolkit. Its specify command-line tool sets a project up for your coding agent, and the workflow then runs as a sequence of agent commands: a constitution of project-wide principles, specify for requirements and user stories, plan for the technical design, tasks to break the plan into ordered steps, implement to execute them, and converge, which assesses the implementation against the spec, plan and tasks and adds the work still missing. Three optional gates sit between them: clarify resolves ambiguity before planning, checklist generates checklists of requirements quality after the plan, and analyze checks the documents for consistency before implementation. The exact spelling of each command depends on the agent you use it with.

Kiro, from AWS, builds specs into its IDE, its command-line tool and its web app. A feature spec produces three files: requirements.md, holding user stories with acceptance criteria written in EARS notation (WHEN a condition occurs, THE SYSTEM SHALL respond in a stated way), design.md and tasks.md. You can start from the requirements or from the design, and a quick spec writes all three files in one pass, without the approval steps, for a feature you already understand. A bugfix spec uses bugfix.md in place of the requirements file. Tasks run one at a time or all together: Kiro builds a dependency graph from tasks.md and runs independent tasks in parallel, in waves.

OpenSpec is an open-source, MIT-licensed tool built for existing codebases as well as new ones. Each proposed change gets its own folder with a proposal, a design, a task list and spec changes written as additions, modifications and removals. When the change is archived, those edits merge into the main specs, which describe how the system behaves now. Of the three, it is the clearest example of a spec-anchored tool: the spec outlives the task.

Without a dedicated tool, the same shape works in any agent. Claude Code, Codex, Cursor and GitHub Copilot in VS Code each have a plan mode that drafts a plan for you to review before the agent changes any code. Anthropic's guidance for Claude Code goes further for larger features: have the agent interview you, write the result to a spec file, and then start a fresh session to implement it, so that the implementation starts with a clean context and a written reference.

How spec artefacts map onto a backlog

If your team keeps a backlog, you already have most of these artefacts under other names.

Spec-driven artefact	Backlog equivalent
Constitution, or project principles	The repository's instruction file, plus accepted architecture decisions
Requirements and acceptance criteria	An epic and its stories, each with acceptance criteria
Technical plan or design	Design notes, architecture decision records and diagrams linked to the stories
Tasks	Sub-tasks, or one story per task when each task is a reviewable change
Implementation	Branches and pull requests linked to the stories they implement

The mapping matters because it shows the real choice. Spec-driven development does not ask you to create new kinds of document. It asks you to write the ones you have more precisely, and it forces a decision about where they live.

Where the spec should live

There are two reasonable answers, and one unreasonable one.

In the repository, as Markdown next to the code. The spec is versioned with the change, reviewed in the same pull request, and read by the agent without any extra connection; Kiro's own guidance takes this view, with one spec per feature rather than one for the whole codebase. The costs: people who do not read the repository (product managers, testers, support, leadership) do not see it; it has no status, owner or links to tests and defects; and once the feature ships, nothing prompts anyone to keep it current. For a single team or an open-source project where everyone works in the repository, this is often the right answer.

In the tracker, as the stories, acceptance criteria and linked designs. Everyone sees it, it has owners and status, and it links to the tests and defects that come later. The cost is that the agent needs access to it. A pasted copy goes stale the moment someone edits the story, which is why this option only works well when the agent reads the tracker directly, typically over MCP. See backlog access for coding agents over MCP.

In both, maintained by hand, is the unreasonable answer. Two copies of a specification drift apart as soon as one is edited, and an agent reading the stale one builds the wrong thing with complete confidence. Anthropic's AI-native SDLC playbook states the rule as "name one system as the source of truth" for each artefact. If the spec lives in the repository, link to it from the story. If it lives in the tracker, give agents read access; a Markdown copy in the repository can still serve as a working copy, provided everyone knows the tracker wins and the two link to each other.

Stride takes the second approach: stories, acceptance criteria, designs and decisions are linked records in one graph, served to coding agents over MCP. We think it is the better default for teams where people outside engineering need to read and change the spec, and we would not argue a small team out of a repository-first spec that works for them.

What spec-driven development does not fix

A precise spec is not a correct one.

• A well-specified wrong feature is still wrong. The spec needs review by someone who knows what the user needs, and that review is worth more than any amount of review of the code.
• Nobody reads a spec that is too long. Specs that run to many pages get approved unread, exactly like oversized pull requests. Split the feature.
• Small changes do not need the ceremony. A one-line fix or a rename needs a clear request and a check, not requirements, a plan and a task list. Anthropic's guidance makes the same point about planning in general: when you could describe the change in one sentence, skip the plan.
• Specs go stale after launch unless something keeps them current. OpenSpec merges each change into the main specs when it is archived, Spec Kit's converge step catches gaps during implementation, and Kiro's Sync Files adds tasks when the requirements change. After the feature ships, someone still has to own the spec, or mark it as historical.

A lightweight way to start

You do not need a new tool to try the approach on your next feature.

1. Have the agent interview you and draft the requirements, with acceptance criteria for each story, including the "must not" cases.
2. Review and approve the requirements before any design work. This is the most valuable review in the whole process.
3. Have the agent propose a technical plan, in its plan mode if it has one, and record any real decision in it as an architecture decision record linked to the stories.
4. Break the plan into tasks that are each one reviewable pull request, and put them in the backlog as stories or sub-tasks.
5. Implement one task per session, test-first, and review each pull request against its task's acceptance criteria.
6. When implementation reveals the spec was wrong, change the spec first, then the code.

Sources

Checked on October 20, 2026:

• GitHub Spec Kit: repository, quickstart, command reference, releases and the launch post (September 2, 2025).
• Kiro: specs, spec best practices, introducing workflows (September 30, 2026) and introducing Kiro (July 14, 2025).
• OpenSpec: repository and concepts.
• Anthropic: Claude Code best practices and the AI-native SDLC playbook (August 21, 2026).
• Plan modes: Codex, Cursor and GitHub Copilot in VS Code.
• Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com (October 15, 2025).