Spec-kit: the GitHub development kit
In this series on Spec Driven Development, we’ll cover several frameworks that implement the Spec Kit concept in different ways. Today we start with GitHub’s spec-kit, one of the most well-known.
Continuously evolving and released around mid-August 2025, it now has roughly 9k forks, over 145 releases and more than 101k stars on GitHub. This SDD kit is a popular choice.
You can install it locally with uv, a Python package manager, in a single command:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v[tag release]
After that, just initialize the project by passing the name and the agent you’ll use:
specify init my-project --integration copilot
cd my-project
Before starting implementation, the documentation suggests defining the project’s principles by creating a kind of constitution. The /speckit.constitution command creates a file with that name, which contains guidance on project structure, governance rules and restrictions, principles and everything relevant to consider during development. This file is created only once.
Next, specify what needs to be created in this spec with /speckit.specify. The goal here is not how to build it, but what and why. A folder is created with the spec number and name, and inside it you’ll find a .spec.md file together with requirements.md.
Files created:
spec.md/checklists/requirements.md
The spec contains information such as functional requirements, key entities, edge cases, user stories and other details inferred by the agent. This document is very valuable and should be read carefully for problem refinement. Additionally, requirements.md is generated.
This other file is more direct: it lists what will be done and what was understood, indicating what’s missing and what’s already done in the spec process.
After this first step, it’s time to document how we’ll technically solve the problem: which technologies, libraries, frameworks and the full stack choices.
Using /speckit.plan, several documents are generated at this stage:
data-model.mdquickstart.mdresearch.mdResearch.mdplan.md
The data model maps the models used in the process and the flow of data. The quickstart explains key files, commands and prerequisites.
The research document serves as the agent’s research: it records why and how each technology was chosen, architecture, testing strategies, insights and more. It also notes open questions or ambiguities.
The plan records technical context, summary, branch, constitution compatibility checks, and stores technical justifications. It contains valuable info about implementation approach, performance, scope and limitations.
After planning, we must break the plan into tasks. Use /speckit.tasks so the agent splits implementation into tasks across phases, categorizing infra, project tasks, user stories, dependencies and ordering. It’s a rich file to track progress objectively.
If something requires correction or review during the process, use
speckit.clarify.
Then implement using /speckit.implement. Ideally, use different context windows: a more capable model to generate plans and a simpler one to implement. With a clear, unambiguous plan and step-by-step instructions, the implementing agent has less room to hallucinate or deviate. Development becomes predictable, clear and transparent.
Issues
This Spec Kit is extremely thorough and makes projects well-documented and easy to share with other developers, but it’s token-hungry. I don’t recommend it for very small or quick tasks.
Because it has many steps, initial speed may be impacted. If you need something structured but fast, this might not be ideal. The process can feel somewhat bureaucratic, and not all generated documents may make sense for the project’s size.
