The Spec-Driven Development Action Pack

Eleven templates. Every one is a markdown file. That is the entire toolchain.

You do not need a CLI, a subscription, or a skill to work this way. If a vendor has told you otherwise, they were selling something. Copy the blanks, fill them in, keep them in the repo next to the code they govern.

This is not a Claude thing. The worked examples show Claude Code because that is what we build with. Nothing in the pack is tied to it. All eleven templates are plain markdown with no tool in them at all, so the method works exactly the same on Codex, Cursor, Copilot, Gemini CLI, Windsurf, or whatever your team has settled on this quarter, and it works with no agent whatsoever on a codebase written entirely by people. The six skills are portable too: they are SKILL.md files following the open Agent Skills standard, which Claude Code, Codex and Cursor all read, so they are not the Claude-only part either. The one place your tool shows up is the file you point it at, and those filenames are listed further down.

What’s in the download

sdd-action-pack/
├── README.md      <- this file. The layout, the loop, and how to wire it to your agent
├── templates/     <- the eleven blanks. This is the method. Copy these into your repo
├── examples/      <- the same eleven, filled in for one worked feature, to read not to copy
└── skills/        <- six optional agent skills, SKILL.md, and a README about trusting them

templates/ is the pack. Everything else exists to explain it. If you only ever open one folder, open that one, and use the numbered order below to decide what goes where.

Where the files go

Loose templates are useless. They only start working when they live in the repository, in a layout that makes it obvious which document governs what. This is that layout.

your-project/
├── CLAUDE.md                            <- or AGENTS.md, .cursorrules, etc. Points at 11
├── docs/
│   └── spec/
│       ├── constitution.md              <- 11  the standing rules everything is built under
│       ├── definition-of-done.md        <- 09  the gate, agreed once, applied to every feature
│       ├── decision-log.md              <- 06  the overview: every decision, one line each
│       │
│       ├── features/
│       │   ├── 001-user-login/
│       │   │   ├── problem-brief.md     <- 01  the problem this feature exists to solve
│       │   │   ├── feature-spec.md      <- 03  the criteria, checkable by a stranger
│       │   │   ├── not-building.md      <- 04  what this feature deliberately excludes
│       │   │   ├── tasks.md             <- 05  criteria cut into verifiable work
│       │   │   ├── decision-log.md      <- 06  the decisions taken building this feature
│       │   │   ├── change-and-drift.md  <- 07  append only, decided change vs silent drift
│       │   │   └── traceability.md      <- 08  filled in by someone who didn't build it
│       │   │
│       │   └── 002-password-reset/
│       │       └── ... the same seven
│       │
│       └── audits/
│           └── 2026-02-11-spec-tasker.md  <- 10  one per skill, before you run it
│
├── src/
└── ...

Four things about that layout are deliberate.

The feature folder is the unit, not the project. Everything needed to specify, build, verify and audit one piece of work sits in one directory, and nothing about the system as a whole has to be settled before you open the first one. That is the difference between this and waterfall. A big spec at the root, written once, is exactly the artefact this method is trying to replace. You can start at 001 on a Tuesday knowing nothing about 007.

Three files sit above the features, and none of them is a spec. The constitution is the standing rules the work runs under: coding standards, security posture, how anything gets built. The definition of done is the standard every feature is measured against, agreed once by the team, because a gate you restate per feature is a gate you renegotiate every time you approach it. The decision log is an overview, described below. All three are the same on Tuesday as they are for feature 007, which is exactly why they are not in a feature folder. What is not up there is any description of the system you are building.

Two logs, and they answer different questions. The decision log records why a choice was made. The change and drift register records what moved in the spec. Drift only means anything measured against a particular set of criteria, so the register is always per feature: a change is a change to this feature’s spec, and drift is this feature’s build wandering off it.

Decisions are the other way round, because their whole value is that someone else finds them. The copy in the feature folder is the working log, written as you build. The copy at the top is the overview: one line per decision across the project, with the date, the decision in a sentence, and the feature folder holding the full entry. Anything that belongs to no single feature, the password hashing algorithm, the error format, gets written out in full up there instead. The test is simple. If a future feature could be affected by it, it needs a line in the overview, and if you cannot be bothered to add the line then the decision was probably not worth logging.

It is docs/spec/, not spec/. A top-level spec/ is already the test directory in Ruby, JavaScript and a dozen other ecosystems, and you do not want your contract fighting your test runner for a folder name. If your project has no docs/, make one.

The number on the folder is the feature’s ID. Template 03 has an ID field: use 001. Template 05 numbers its tasks [ID]-01, so the work for that feature is 001-01, 001-02, and so on, and the traceability matrix in the same folder can point at a criteria and a task without anyone having to guess which feature is meant.

Template 02 is optional, and often skipped. The Spec is for when several features share one contract and you need a parent for them to point at. If you are not there, skip it, the feature spec is the contract. When you do need one, give it its own folder beside the features, docs/spec/epics/001-accounts/spec.md, and fill in the Parent spec field on each feature spec that answers to it. What it should never become is one document at the root describing the whole system, agreed up front, before anyone has built anything.

Wiring the constitution into your agent

Writing a constitution the agent never reads is worse than not writing one, because you will believe the rules are in force.

Every coding agent looks for its own instructions file, and the obvious move is to paste the rules into it. Do not. You will end up with two versions, they will drift apart within a fortnight, and the one the agent obeys will be the stale one. Make the tool’s file a pointer and keep the content in the constitution, so there is exactly one copy to change and one file to review when it changes.

CLAUDE.md in the repository root, in full:

# How work is done here

Read `docs/spec/constitution.md` before doing anything. It is the source of truth for the
standing rules of this repository and it overrides anything in this file.

When working on a feature, read every file in that feature's folder under
`docs/spec/features/` first. The feature spec is the contract and `not-building.md` is
binding. If a request conflicts with either, stop and say so rather than deciding for
yourself.

That last sentence is the one that earns its place. Left to itself an agent resolves a conflict silently and plausibly, and you find out three hundred commits later. Told to stop and ask, it behaves like the junior developer who walked over to your desk.

Same three lines, different filename, depending on what you run:

These filenames move about as vendors change their minds, so check your tool’s current docs. The principle survives the renaming: one canonical constitution in the repo, every tool pointed at it, nothing important living only inside a vendor’s config file. Run several agents and they all point at the same file, which is the entire reason the constitution is tool-agnostic.

The eleven templates

How to actually use it

Once, at the start. Copy template 11 to docs/spec/constitution.md and fill it in, then wire it into your agent’s instructions file as above. Copy template 09 to docs/spec/definition-of-done.md and agree it as a team, once, so nobody is negotiating the bar at the point they most want it lowered. Create docs/spec/decision-log.md from template 06 and leave it empty; it wants to exist before the first decision worth recording happens.

That is the whole project-level setup: two documents to write and one to open. There is no system spec to agree, no up-front design phase to sit through, and nothing else to do before you start on the first feature.

Per feature, before any code. Make docs/spec/features/NNN-name/. Work down the folder in order: the problem brief first, because it is the one that stops you building the wrong thing well; then the feature spec, with criteria a stranger could check; then the not-building register, with a reason on every line, because “out of scope” is a restatement of the heading and not a reason; then the task breakdown. If a task cannot be verified on its own, it is two tasks.

While building. Point the agent at the constitution and at this feature’s folder. Every decision nobody had already made goes in the feature’s decision-log.md as it is taken, not reconstructed afterwards, and anything a later feature could trip over gets a line in the overview at docs/spec/decision-log.md at the same time. Anything that moves the spec goes in change-and-drift.md, which keeps decided change and silent drift apart, and that separation is the whole point of the document.

Before you call it done. Someone who did not build it fills in traceability.md, mapping every criteria to the test that proves it. Unmapped criteria is the finding. Then run the feature against docs/spec/definition-of-done.md. Both are gates, and a gate you skip when you are busy is not a gate.

Before you run anyone’s agent skill. Copy template 10 into docs/spec/audits/ with the skill’s name and the date, and work through it. That includes the six skills in this pack.

How they fit together

01 Problem Brief
      |
      v
02 The Spec  <--->  04 Not Building Register     (02 only if several
      |                     ^                     features share a contract)
      v                     |
03 Feature Spec       07 Change & Drift Register
      |                     ^
      v                     |
05 Task Breakdown ----------+
      |
      v
   [ build ]  ------>  06 Decision Log
      |    ^
      |    |  governed throughout by
      |   11 The Constitution  (standing rules, read by every agent + human)
      v
08 AC Traceability Matrix
      |
      v
09 Definition of Done

11 and 09 happen once per project: the standing rules, and the standard everything is measured against. 01, 03, 04, 05 and 08 happen once per feature. 07 is a living document inside the feature folder. 06 is living too, and lives in both places, the working log with the feature and the overview at the top. 08 and 09 are gates. 02 is for the occasional epic. 10 you reach for before running anyone’s skill.

Rules

1. These live in the repo. In git, next to the code, reviewed in pull requests. A spec in Confluence is a document. A spec in the repo is a contract.
2. Non-goals are a first-class artefact. Template 04 is standalone for a reason. Non-goals buried inside a spec get quietly overturned by whoever’s tired at 4pm on a Friday.
3. If an acceptance criteria can’t be checked by someone who wasn’t in the room, it isn’t one. Rewrite it or delete it.
4. Nothing here is mandatory on every task. The overhead is real. If you’d be annoyed at someone interpreting it differently than you meant, spec it. If you’d fix it in one follow-up, don’t. Ceremony applied indiscriminately is how this becomes waterfall.
5. The constitution is tool-agnostic on purpose. Keep the canonical copy in the repo, not in CLAUDE.md or .cursorrules; let those point at it, as above. The tool you use will change. The rules shouldn’t have to move house when it does.

The worked examples

Every template ships with a filled-in example in examples/. Ten of them describe the same feature, user login for a product called Kestrel, carried the whole way through: specced, decomposed, built, drifted, verified, audited. Read those ten in order and you have the entire method. The eleventh, the Skill Audit Checklist example, necessarily uses a different fixture: it audits a fictional third-party skill (spec-tasker) rather than the login feature, because you can’t demonstrate auditing someone else’s skill on a feature you built yourself.

It’s a deliberately boring feature. Every method looks good on something interesting.

To see the layout above with the words filled in: put examples/11 at docs/spec/constitution.md and examples/09 at docs/spec/definition-of-done.md, drop examples/01, 03, 04, 05, 06, 07 and 08 into docs/spec/features/001-user-login/ under the filenames in the tree, and examples/10 into docs/spec/audits/. That is a finished feature, start to audit, in the shape your own repo should take.

The skills

skills/ holds six optional skills, one per stage of the loop plus one for bringing an existing codebase into it. Each is a folder containing a SKILL.md, which is the open Agent Skills standard, so they are not Claude-only: copy the folders into whichever skills directory your agent reads. At the time of writing that is .claude/skills/ for Claude Code, .agents/skills/ for Codex, and Cursor reads .cursor/skills/ as well as both of those. Those paths move as often as the instruction filenames do, so check your tool’s current docs.

They automate the repetitive parts. They do not confer the discipline, and you can run the whole method without them. Read skills/README.md before you run any of them, and put them through template 10 first.