GitHub’s toolkit for spec-driven development with AI coding agents. Establishes a project constitution of engineering principles, then drives each feature through specify, plan, tasks, implement and converge as agent slash commands, with artifacts scaffolded into a .specify/ directory by the specify CLI. MIT licensed and maintained by GitHub, though published as a toolkit rather than a specification.
Spec Kit
Spec Kit is GitHub’s take on spec-driven development: agree the what and the why as written artifacts, then let the coding agent work against them rather than against a chat transcript. It is installed as the specify CLI, scaffolds its artifacts into a .specify/ directory, and is MIT licensed.
- A constitution, then a loop - The project is set up once with
/speckit-constitution, which writes the engineering principles every later step is held against. Each feature then runs/speckit-specify→/speckit-plan→/speckit-tasks→/speckit-implement→/speckit-converge, repeating implement and converge until convergence reports done. - Quality gates as opt-in steps - Clarification, checklists and consistency analysis are separate commands you add when a feature warrants them, rather than phases everything must pass through.
- Bug fixing kept separate - An opt-in extension, added with
specify extension add bug, supplies an assess → fix → test sequence that writes to.specify/bugs/<slug>/, deliberately keeping diagnosis apart from repair so the agent fixes the cause it assessed and re-checks the original symptom. - Templates, not a schema - The artifacts are Markdown produced from templates the CLI scaffolds. There is no schema to validate against and no conformance notion; the CLI and the docs define the shape.
Spec Kit is the heavyweight of the spec-driven trio, and its rivals say so — OpenSpec pitches itself explicitly as the lighter alternative with fewer phase gates. The comparison is worth taking with salt in both directions, but the structural difference is real: Spec Kit front-loads a constitution and offers more gates, where OpenSpec starts at the change folder. Both sit in the same markdown control layer as AGENTS.md and Agent Skills, and both borrow the scenario habit of BDD.
Despite the GitHub name this is not a standard. There is no specification document, no governing body beyond the repository’s maintainers, and no interoperability with the other spec-driven toolkits — a .specify/ tree does not read as an openspec/ tree or as a Kiro spec. Treat it as a well-adopted vendor toolkit whose conventions can move with a release.
Practices this standard realizes
The ways of working this standard exists to serve. A standard rarely arrives on its own — it is usually the artifact some practice needed before it could be more than an argument.
Spec-Driven Development
GitHub's SDD toolkit: a project constitution, then specify, plan, tasks, implement and converge.
