GitHub’s Spec Kit is a new toolkit for AI coding. Its goal is to help developers practice Spec-Driven Development.
The problem it tackles is straightforward: many AI coding workflows today feel too much like “chat while coding.” A human gives a rough idea, and an Agent immediately starts changing code. It looks fast in the short term, but the requirement boundaries, acceptance criteria, technical trade-offs, and task breakdown often never settle into anything durable. Once a project becomes even slightly complex, it easily turns into one-off vibe coding.
Spec Kit takes the opposite route: write the spec clearly first, then move into planning, tasks, and implementation. Code is no longer the first step. The spec is.
What Is Spec Kit?
Spec Kit is GitHub’s open-source toolkit for spec-driven development. It provides the specify CLI, templates, scripts, and commands for AI coding agents, allowing teams to advance development around the same set of structured artifacts.
Its emphasis is not “make AI ask fewer questions.” Instead, it asks AI to generate and refine these things before writing code:
- Project principles: the team’s constraints around quality, testing, experience, performance, and similar concerns;
- Feature specs: what to build, why to build it, user stories, and functional requirements;
- Technical plans: which technology stack to use, how to implement it, and what architecture decisions are involved;
- Task lists: breaking the plan into executable steps;
- Implementation process: changing code step by step according to tasks, instead of making one chaotic batch of edits.
This workflow makes AI coding feel more like engineering collaboration, rather than a one-time prompt performance.
Basic Usage Flow
The official README describes a getting-started flow roughly like this:
|
|
After initialization, the project gets a .specify directory, templates, scripts, and commands for Agent integration. You then use /speckit.* commands inside a supported AI coding agent to move development forward.
A typical sequence is:
|
|
Here, /speckit.constitution establishes project principles, /speckit.specify describes product requirements, /speckit.clarify fills in ambiguity, /speckit.plan generates a technical plan, /speckit.tasks breaks the work into tasks, and /speckit.implement finally performs the implementation.
This is very different from directly telling an Agent, “Help me build an app.” Spec Kit asks you to first make clear what to build and how it will be accepted, then let the Agent start working.
It Changes the Entry Point of AI Coding
Traditional AI coding often starts with code:
|
|
Spec Kit is closer to this:
|
|
This shift matters. AI is very good at executing from context, but if the context itself is loose, faster execution can also mean faster drift. Spec Kit turns context into files and templates, so requirements, plans, and tasks can all be reviewed, revised, and version-controlled.
In other words, it is not making AI more “free.” It is giving AI clearer engineering rails on which to work freely.
How to Understand the Core Commands
/speckit.constitution
This is the project’s “constitution.” It creates or updates .specify/memory/constitution.md, which records long-term principles for the project, such as code quality, testing standards, user experience consistency, performance requirements, and rules for technical decisions.
This step is best for writing down team consensus, not requirements for a single feature.
/speckit.specify
This is the feature specification phase. You describe what you want to build, who the users are, what problem it solves, and what the core flows are.
The official guidance specifically emphasizes that this phase should not focus too early on the technology stack. First make the what and why clear, then discuss the how.
/speckit.clarify
This is the phase for filling gaps. Many requirements have holes the first time they are written: how should permissions work? What are the error states? Does the data need to be persisted? How should edge cases be accepted?
The value of /speckit.clarify is that it lets the Agent actively find uncertain points in the spec and write the answers back into the specification document, reducing rework later.
/speckit.plan
This is the technical planning phase. Only here do you start to define the framework, database, architecture, APIs, testing strategy, and constraints.
If /speckit.specify is product language, then /speckit.plan is engineering language.
/speckit.tasks
This step breaks the plan into executable tasks. A good task list should let the Agent advance step by step, while still letting humans understand the purpose of each step.
/speckit.implement
Only at the end do you enter implementation. The Agent modifies code according to the specs, plans, and tasks that have already been settled. At this point, it is no longer guessing requirements from a single large prompt; it is executing inside a set of structured documents.
Why It Fits AI Coding
Spec Kit’s value is not in any single magic command. It is in restoring the things most easily lost in AI coding:
- Requirements can be reviewed;
- Plans can be discussed;
- Tasks can be traced;
- Decisions have context;
- Artifacts can enter Git history;
- Teams can reuse templates and principles;
- The Agent’s implementation no longer depends only on a one-time chat record.
This is especially useful for complex projects. The more a project involves multiple collaborators, long-term maintenance, or high quality requirements, the less it can rely only on temporary prompts to drive development.
Extensions and Presets
Spec Kit also provides two kinds of customization:
- Extensions: add new commands, new templates, or integrations with external tools;
- Presets: change the format and terminology of existing spec, plan, and task templates.
In simple terms, use an Extension when you want to add new capability; use a Preset when you want to reshape the workflow style.
For example, a team can use a Preset to require security review, compliance traceability, domain terminology, or test-first rules. It can also use an Extension to add Jira integration, code review, project health checks, and other new phases.
This means Spec Kit is not trying to lock every team into the same workflow. It provides an extensible skeleton for spec-driven development.
Who Is It For?
Spec Kit is suitable for scenarios like these:
- Using an AI coding agent to prototype a new project;
- Turning vibe coding into a repeatable workflow;
- Standardizing the requirement and planning format before teams let AI generate code;
- Projects that need clear acceptance criteria and testing requirements;
- Bringing requirements, plans, tasks, and implementation history into version control;
- Teams exploring GitHub Copilot, Claude Code, Codex CLI, and similar tools in a team setting.
It is not necessarily a good fit for very small one-off scripts. For problems that can be solved in a few lines of code, the full spec workflow may feel heavy. But once a task involves multiple pages, multiple modules, state management, permissions, data models, or long-term maintenance, Spec Kit’s structure starts to pay off clearly.
My Take
Spec Kit represents an important turn in AI coding tools: from “make the Agent write code faster” toward “make the Agent participate in software engineering more reliably.”
Earlier AI coding focused on prompts and model capability. Spec Kit focuses more on process, artifacts, and constraints. It reminds us that the faster AI writes code, the less we can afford to skip specs, plans, and acceptance criteria.
If you are already used to letting AI implement features directly, you can try changing the starting move with Spec Kit:
First let AI help you write the requirement as a spec, then let it write the code.
That step may look slower, but in practice it reduces the later rework of “the code is done, but it is not what I wanted.”