"Done" is the most expensive word a coding agent says.
You ask for a feature, the agent works for a while, and then it reports that everything is implemented. Sometimes it is. Sometimes one user story is half-built, a requirement was quietly reinterpreted, or a task was skipped because the agent decided it wasn't needed. The agent isn't lying. It's grading its own homework against a goal that was never written down.
The fix isn't a better prompt at the end. It's defining "done" before the agent starts, then checking the code against that definition afterwards. That's what Spec Kit, GitHub's open-source toolkit for Spec-Driven Development (SDD), is built around. This article walks through its workflow with one question in mind: at which step does "done" get defined, and at which step does it get checked?
What Spec Kit is, briefly
Spec Kit gives your coding agent a set of slash commands (or skills, depending on the agent) that turn a feature request into a chain of files: a project constitution, a spec, a plan, a task list, and then code. You review each file before moving on.
The README describes the core idea in one line: "Define what to build and why, then turn the specification into a plan, tasks, and working code." The point is that the agent implements against something you've read and agreed to, not against a sentence it interpreted on its own.
Install it in two commands
From the official README, you need Python 3.11+, uv and a supported AI coding agent on Linux, macOS or Windows. Then:
uv tool install specify-cli specify init my-project --integration copilot cd my-project The example uses GitHub Copilot. Spec Kit works with other agents too; you pick the integration at init time. One thing that trips people up: the command syntax depends on the agent. The docs write commands as /speckit.specify, Copilot's default skills mode uses /speckit-specify, and some agents such as Codex use $speckit-specify. Check the invocation syntax for yours.
After that, you launch your agent in the project folder and run the commands in the agent's chat, not in your terminal, one at a time.
The nine commands, grouped by what they do to "done"
The full order in the command reference is:
constitution -> specify -> clarify -> plan -> checklist -> tasks -> analyze -> implement -> converge Only specify is strictly required before plan. clarify, checklist and analyze are optional quality gates for anything with meaningful ambiguity. Here's how I group them.
1. Define "done": constitution and specify
/speckit.constitution sets the project's standing principles, the rules every later phase is evaluated against. You run it once and update it when your principles change. For example:
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements. /speckit.specify turns your plain-language description into the feature spec. The docs are clear that this step is about the what and why, the user-facing behavior and goals, not the tech stack. That separation matters: if the spec says "albums are never nested inside other albums", that's a requirement the code can later be checked against. If it just says "use SQLite", there's nothing to verify about the user's experience.
2. Tighten "done": clarify and checklist
/speckit.clarify asks up to five targeted questions about underspecified parts of the spec and writes your answers back into spec.md. You can run it several times, each time on a different area, and pass a focus:
/speckit.clarify Focus on the task card behavior: status changes, comment limits, and who can be assigned. /speckit.checklist is the step I'd skip least. The docs call it "unit tests for your requirements". It doesn't test code; it checks whether the spec itself is complete, clear and consistent, with questions like "Is behavior specified for a deleted assigned user?"
There's a detail here worth knowing. In a custom checklist, a checked box means a reviewer decided the requirement is good enough. It does not mean the work is done. The docs say the agent must not silently self-approve these checklists, and that /speckit.implement reads the checkbox state as a gate: it counts unchecked items and asks before proceeding if any remain. In other words, a human stays in the loop exactly where the definition of "done" is still soft.
3. Plan the work: plan and tasks
/speckit.plan is where the tech stack and architecture go:
/speckit.plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite. /speckit.tasks breaks the plan into a dependency-ordered tasks.md: a Setup phase, a Foundational phase for blocking prerequisites, one phase per user story in priority order, and a final Polish phase. Tasks that can run in parallel are marked.
4. Check "done" before any code: analyze
/speckit.analyze is a read-only consistency check across spec.md, plan.md and tasks.md. It reports conflicts, gaps and ambiguities, for example a task with no matching requirement, or a plan choice that contradicts the spec. It never edits files.
This is the cheapest moment to catch a mismatch. If it finds a requirement problem, you go back to specify or clarify; a design problem goes back to plan; a task problem means regenerating tasks. Then you re-run analyze until it comes back clean.
5. Build, then check "done" against the code: implement and converge
/speckit.implement executes the tasks in dependency order. For bigger features, the docs recommend working in stages so you don't overload the agent's context, for example "Implement only the Setup and Foundational phases… Stop before the user-story features", then validating before you continue.
And then comes the step that answers the opening problem. /speckit.converge assesses the codebase against the spec, plan and tasks to confirm nothing was missed. It's append-only: it never edits or deletes code, and the only thing it can write is new tasks in tasks.md.
It ends in one of two ways:
- Converged. No gaps found,
tasks.mdis left unchanged, and you can move on to review or a pull request. - Tasks appended. Gaps were found and added under a Convergence section in
tasks.md. You run/speckit.implementagain, then/speckit.convergeagain, and repeat until it reports converged.
That's the shift. "Done" is no longer the agent's opinion at the end of a long session. It's a separate pass that compares the code with documents you reviewed, and when something's missing, the result is a task, not a reassuring summary.
Lean path or full path?
You don't need all nine commands every time. The README's minimal flow is six steps:
/speckit-constitution Create principles focused on code quality, testing, and maintainability. /speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album. /speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite. /speckit-tasks /speckit-implement /speckit-converge My rule of thumb: use the lean path for small, well-understood features, and add clarify, checklist and analyze when the feature has rules you could argue about (permissions, edge cases, anything touching data). Whichever path you take, keep converge at the end. It's the step that turns "the agent says it's done" into "the code matches what we agreed".
Beyond features
The README also lists two bundled extensions for other kinds of work, each with a clear final verdict:
- Bug fixing (
specify extension add bug): assess the cause, fix, then test. The final verdict isverified,partialorfailed, and onlyverifiedconfirms the fix. - Idea assessment (
specify extension add assess): ends withgo,needs-clarificationorkill.
Same idea in both: the agent's work ends with an explicit, recorded result you can check, not just a message that it's finished.
Quick checklist
- [ ] Constitution written once, updated when principles change
- [ ] Spec describes behavior and goals, not the tech stack
- [ ]
clarifyrun on every area you could argue about - [ ] Custom checklist reviewed by a person, never self-approved by the agent
- [ ]
analyzecomes back clean before implementing - [ ] Large features implemented in stages, each one validated
- [ ]
convergerepeated until it reports Converged - [ ] A human review or PR still happens after convergence
Where to go next
If you want the whole workflow on a few pages, start with the free Spec Kit Quick-Start: what SDD is, installing the Specify CLI, the nine-command workflow as a quick reference, lean vs production paths, and a compact first-run walkthrough.
When you're ready to go deeper, Spec Kit: The Complete Guide has a chapter on every command, extensions, presets and bundles, brownfield and legacy projects, a 30-day adoption plan, common pitfalls, Spec Kit for teams, and a full worked example through all nine phases.
This article was written with the assistance of AI and reviewed by the author. Commands and behaviors are taken from the official Spec Kit README and command reference (latest release v1.3.3 at the time of writing). PromptMaster guides are independent and not affiliated with or endorsed by GitHub.
