github/spec-kit

🌱 Spec Kit

Build high-quality software faster.

An open source toolkit that allows you to focus on product scenarios and predictable outcomes instead of vibe coding every piece from scratch.

Table of Contents

• 🤔 What is Spec-Driven Development?
• ⚡ Get Started
• 📽️ Video Overview
• 🌍 Community
• 🤖 Supported AI Coding Agent Integrations
• 🔧 Specify CLI Reference
• 🧩 Making Spec Kit Your Own: Extensions & Presets
• 📚 Core Philosophy
• 🌟 Development Phases
• 🎯 Experimental Goals
• 🔧 Prerequisites
• 📖 Learn More
• 📋 Detailed Process
• 💬 Support
• 🙏 Acknowledgements
• 📄 License

🤔 What is Spec-Driven Development?

Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the “real work” of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.

⚡ Get Started

1. Install Specify CLI

Requires uv (install uv). Replace vX.Y.Z with the latest tag from Releases:

1

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

See the Installation Guide for alternative methods, verification, upgrade, and troubleshooting.

2. Initialize a project

1
2

specify init my-project --integration copilot
cd my-project

To check for updates or upgrade the installed CLI, use the self-management commands. See the Upgrade Guide for detailed scenarios and customization options.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Check whether a newer release is available (read-only — does not modify anything)
specify self check

# Preview what would run, without actually upgrading
specify self upgrade --dry-run

# Upgrade in place to the latest stable release (auto-detects uv tool vs pipx install)
specify self upgrade

# Or pin a specific release tag (replace vX.Y.Z[suffix] with your desired release tag)
specify self upgrade --tag vX.Y.Z[suffix]

Bare specify self upgrade executes immediately, matching the no-prompt behavior of commands like pip install -U and npm update. For uv tool installs, it runs uv tool install specify-cli --force --from <git ref> under the hood so pinned release tags work, including dev, alpha/beta/rc, or build metadata suffixes. uvx (ephemeral) runs and source checkouts are detected and produce path-specific guidance instead of running an installer. Set SPECIFY_UPGRADE_TIMEOUT_SECS to cap how long the installer subprocess may run (default: no timeout — interrupt with Ctrl+C if needed).

3. Establish project principles

Launch your coding agent in the project directory. Most agents expose spec-kit as /speckit.* slash commands; Codex CLI in skills mode uses $speckit-* instead.

Use the /speckit.constitution command to create your project’s governing principles and development guidelines that will guide all subsequent development.

1

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

4. Create the spec

Use the /speckit.specify command to describe what you want to build. Focus on the what and why, not the tech stack.

1

/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.

5. Create a technical implementation plan

Use the /speckit.plan command to provide your tech stack and architecture choices.

1

/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.

6. Break down into tasks

Use /speckit.tasks to create an actionable task list from your implementation plan.

1

/speckit.tasks

7. Execute implementation

Use /speckit.implement to execute all tasks and build your feature according to the plan.

1

/speckit.implement

For detailed step-by-step instructions, see our comprehensive guide.

📽️ Video Overview

Want to see Spec Kit in action? Watch our video overview!

🌍 Community

Explore community-contributed resources on the Spec Kit docs site:

• Extensions — commands, hooks, and capabilities
• Presets — template and terminology overrides
• Walkthroughs — end-to-end SDD scenarios
• Friends — projects that extend or build on Spec Kit

[!NOTE] Community contributions are independently created and maintained by their respective authors. Review source code before installation and use at your own discretion.

Want to contribute? See the Extension Publishing Guide or the Presets Publishing Guide.

🤖 Supported AI Coding Agent Integrations

Spec Kit works with 30+ AI coding agents — both CLI tools and IDE-based assistants. See the full list with notes and usage details in the Supported AI Coding Agent Integrations guide.

Run specify integration list to see all available integrations in your installed version.

Available Slash Commands

After running specify init, your AI coding agent will have access to these slash commands for structured development. For integrations that support skills mode, passing --integration <agent> --integration-options="--skills" installs agent skills instead of slash-command prompt files.

Core Commands

Essential commands for the Spec-Driven Development workflow:

Optional Commands

Additional commands for enhanced quality and validation:

🔧 Specify CLI Reference

For full command details, options, and examples, see the CLI Reference.

🧩 Making Spec Kit Your Own: Extensions & Presets

Spec Kit can be tailored to your needs through two complementary systems — extensions and presets — plus project-local overrides for one-off adjustments:

• Templates are resolved at runtime — Spec Kit walks the stack top-down and uses the first match.
• Project-local overrides (.specify/templates/overrides/) let you make one-off adjustments for a single project without creating a full preset.
• Extension/preset commands are applied at install time — when you run specify extension add or specify preset add, command files are written into agent directories (e.g., .claude/commands/).
• If multiple presets or extensions provide the same command, the highest-priority version wins. On removal, the next-highest-priority version is restored automatically.
• If no overrides or customizations exist, Spec Kit uses its core defaults.

Extensions — Add New Capabilities

Use extensions when you need functionality that goes beyond Spec Kit’s core. Extensions introduce new commands and templates — for example, adding domain-specific workflows that are not covered by the built-in SDD commands, integrating with external tools, or adding entirely new development phases. They expand what Spec Kit can do.

1
2
3
4
5

# Search available extensions
specify extension search

# Install an extension
specify extension add <extension-name>

For example, extensions could add Jira integration, post-implementation code review, V-Model test traceability, or project health diagnostics.

See the Extensions reference for the full command guide. Browse the community extensions for what’s available.

Presets — Customize Existing Workflows

Use presets when you want to change how Spec Kit works without adding new capabilities. Presets override the templates and commands that ship with the core and with installed extensions — for example, enforcing a compliance-oriented spec format, using domain-specific terminology, or applying organizational standards to plans and tasks. They customize the artifacts and instructions that Spec Kit and its extensions produce.

1
2
3
4
5

# Search available presets
specify preset search

# Install a preset
specify preset add <preset-name>

For example, presets could restructure spec templates to require regulatory traceability, adapt the workflow to fit the methodology you use (e.g., Agile, Kanban, Waterfall, jobs-to-be-done, or domain-driven design), add mandatory security review gates to plans, enforce test-first task ordering, or localize the entire workflow to a different language. The pirate-speak demo shows just how deep the customization can go. Multiple presets can be stacked with priority ordering.

See the Presets reference for the full command guide, including resolution order and priority stacking.

When to Use Which

📚 Core Philosophy

Spec-Driven Development is a structured process that emphasizes:

• Intent-driven development where specifications define the “what” before the “how”
• Rich specification creation using guardrails and organizational principles
• Multi-step refinement rather than one-shot code generation from prompts
• Heavy reliance on advanced AI model capabilities for specification interpretation

🌟 Development Phases

🎯 Experimental Goals

Our research and experimentation focus on:

Technology independence

• Create applications using diverse technology stacks
• Validate the hypothesis that Spec-Driven Development is a process not tied to specific technologies, programming languages, or frameworks

Enterprise constraints

• Demonstrate mission-critical application development
• Incorporate organizational constraints (cloud providers, tech stacks, engineering practices)
• Support enterprise design systems and compliance requirements

User-centric development

• Build applications for different user cohorts and preferences
• Support various development approaches (from vibe-coding to AI-native development)

Creative & iterative processes

• Validate the concept of parallel implementation exploration
• Provide robust iterative feature development workflows
• Extend processes to handle upgrades and modernization tasks

🔧 Prerequisites

• Linux/macOS/Windows
• Supported AI coding agent.
• uv for package management (recommended) or pipx for persistent installation
• Python 3.11+
• Git

If you encounter issues with an agent, please open an issue so we can refine the integration.

📖 Learn More

• Complete Spec-Driven Development Methodology - Deep dive into the full process
• Detailed Walkthrough - Step-by-step implementation guide

📋 Detailed Process

1

specify init <project_name>

1
2
3
4
5
6
7

specify init .
# or use the --here flag
specify init --here
# Skip confirmation when the directory already has files
specify init . --force
# or
specify init --here --force

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

specify init <project_name> --integration copilot
specify init <project_name> --integration gemini
specify init <project_name> --integration codex

# Or in current directory:
specify init . --integration copilot
specify init . --integration codex --integration-options="--skills"

# or use --here flag
specify init --here --integration copilot
specify init --here --integration codex --integration-options="--skills"

# Force merge into a non-empty current directory
specify init . --force --integration copilot

# or
specify init --here --force --integration copilot

1

specify init <project_name> --integration copilot --ignore-agent-tools

1

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements. Include governance for how these principles should guide technical decisions and implementation choices.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Develop Taskify, a team productivity platform. It should allow users to create projects, add team members,
assign tasks, comment and move tasks between boards in Kanban style. In this initial phase for this feature,
let's call it "Create Taskify," let's have multiple users but the users will be declared ahead of time, predefined.
I want five users in two different categories, one product manager and four engineers. Let's create three
different sample projects. Let's have the standard Kanban columns for the status of each task, such as "To Do,"
"In Progress," "In Review," and "Done." There will be no login for this application as this is just the very
first testing thing to ensure that our basic features are set up. For each task in the UI for a task card,
you should be able to change the current status of the task between the different columns in the Kanban work board.
You should be able to leave an unlimited number of comments for a particular card. You should be able to, from that task
card, assign one of the valid users. When you first launch Taskify, it's going to give you a list of the five users to pick
from. There will be no password required. When you click on a user, you go into the main view, which displays the list of
projects. When you click on a project, you open the Kanban board for that project. You're going to see the columns.
You'll be able to drag and drop cards back and forth between different columns. You will see any cards that are
assigned to you, the currently logged in user, in a different color from all the other ones, so you can quickly
see yours. You can edit any comments that you make, but you can't edit comments that other people made. You can
delete any comments that you made, but you can't delete comments anybody else made.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

.
├── .specify
│   ├── memory
│   │   └── constitution.md
│   ├── scripts
│   │   └── bash
│   │       ├── check-prerequisites.sh
│   │       ├── common.sh
│   │       ├── create-new-feature.sh
│   │       ├── setup-plan.sh
│   │       └── setup-tasks.sh
│   └── templates
│       ├── plan-template.md
│       ├── spec-template.md
│       └── tasks-template.md
└── specs
    └── 001-create-taskify
        └── spec.md

1
2
3

For each sample project or project that you create there should be a variable number of tasks between 5 and 15
tasks for each one randomly distributed into different states of completion. Make sure that there's at least
one task in each stage of completion.

1

Read the review and acceptance checklist, and check off each item in the checklist if the feature spec meets the criteria. Leave it empty if it does not.

1
2
3

We are going to generate this using .NET Aspire, using Postgres as the database. The frontend should use
Blazor server with drag-and-drop task boards, real-time updates. There should be a REST API created with a projects API,
tasks API, and a notifications API.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

.
├── CLAUDE.md
├── .specify
│   ├── memory
│   │   └── constitution.md
│   ├── scripts
│   │   └── bash
│   │       ├── check-prerequisites.sh
│   │       ├── common.sh
│   │       ├── create-new-feature.sh
│   │       ├── setup-plan.sh
│   │       └── setup-tasks.sh
│   └── templates
│       ├── CLAUDE-template.md
│       ├── plan-template.md
│       ├── spec-template.md
│       └── tasks-template.md
└── specs
    └── 001-create-taskify
        ├── contracts
        │   ├── api-spec.json
        │   └── signalr-spec.md
        ├── data-model.md
        ├── plan.md
        ├── quickstart.md
        ├── research.md
        └── spec.md

1
2
3
4
5

I want you to go through the implementation plan and implementation details, looking for areas that could
benefit from additional research as .NET Aspire is a rapidly changing library. For those areas that you identify that
require further research, I want you to update the research document with additional details about the specific
versions that we are going to be using in this Taskify application and spawn parallel research tasks to clarify
any details using research from the web.

1
2
3
4
5
6
7

I think we need to break this down into a series of steps. First, identify a list of tasks
that you would need to do during implementation that you're not sure of or would benefit
from further research. Write down a list of those tasks. And then for each one of these tasks,
I want you to spin up a separate research task so that the net results is we are researching
all of those very specific tasks in parallel. What I saw you doing was it looks like you were
researching .NET Aspire in general and I don't think that's gonna do much for us in this case.
That's way too untargeted research. The research needs to help you solve a specific targeted question.

1
2
3
4
5

Now I want you to go and audit the implementation plan and the implementation detail files.
Read through it with an eye on determining whether or not there is a sequence of tasks that you need
to be doing that are obvious from reading this. Because I don't know if there's enough here. For example,
when I look at the core implementation, it would be useful to reference the appropriate places in the implementation
details where it can find the information as it walks through each step in the core implementation or in the refinement.

1

/speckit.tasks

1

/speckit.implement

💬 Support

For support, please open a GitHub issue. We welcome bug reports, feature requests, and questions about using Spec-Driven Development.

🙏 Acknowledgements

This project is heavily influenced by and based on the work and research of John Lam.

📄 License

This project is licensed under the terms of the MIT open source license. Please refer to the LICENSE file for the full terms.