Spec Kit 0.8.13 · May 2026
Spec-Driven
Development
The complete guide to all commands, flows, and best practices for using Spec Kit from start to finish on a real project.
specify-cli · install via uv tool install
EXPLORE
↓
Overview
Spec Kit works in
two distinct layers
Terminal
Setup Layer
Installation, project initialization, AI agent integration management, extensions, presets, and workflows. All via command line.
$ specify init my-app --integration opencode
AI Agent
Development Layer
The real Spec-Driven development flow: from the constitution all the way to implementation. Commands used in the agent chat after specify init.
/speckit.specify → /speckit.plan → /speckit.implement
Agent Commands
The complete flow,
step by step
/speckit.constitution
What you provide
- Architecture rules (Clean Arch, SOLID, etc.)
- Quality and testing standards
- UX and security rules
- Code and naming conventions
- Performance constraints
What is generated
.specify/memory/constitution.md
The permanent laws of the project. Every subsequent command will respect these rules.
example.txt
/speckit.constitution # Project laws — fullstack No business logic in controllers, visual components, or infrastructure.
Backend exposes clear, versioned, and documented contracts.
Frontend consumes APIs through isolated services/hooks.
Every important behavior must have test coverage.
No feature creates a duplicate concept without checking existing ones.
UX prioritizes empty states, loading, error, and clear feedback.
Security: validate on the backend, protect routes, handle permissions.
Performance: avoid N+1, large payloads, and unnecessary renders.
GPT-5.5 thinking: high
Typical use
- At the start of any new project, before any other command
- When resuming an old project with no defined constitution
Also use when...
- The stack or architecture changes significantly
- The team adopts a new testing or security standard
- A new team member joins and needs to understand the project rules
/speckit.specify
What you provide
- WHAT the system must do
- WHY — business motivation
- Unambiguous business rules
- Measurable success criteria
- Edge cases and key constraints
⚠ No React, Spring, PostgreSQL here. The stack goes in /plan.
What is generated
specs/001-feature-name/spec.md branch created feature folder
GPT-5.5 thinking: high
Typical use
- After the constitution, to describe the first module or feature
- Start of each new development cycle
Also use when...
- A demand arises outside current scope — update the spec before implementing
- The business rule changes and needs to be reflected in the documentation
- You want to split a large module into smaller, independent specs
/speckit.clarify
What you provide
- Non-obvious business rule points
- Edge cases to detail
- Security and permission questions
- Minimum screens/flows for MVP
- Behavior for similar values
What is generated
Update and refinement of spec.md — forces the agent not to assume implicit things.
GPT-5.5 thinking: high
Typical use
- After /specify, before moving on to /plan
- When the spec has vague points the agent could misinterpret
Also use when...
- The domain is complex and involves financial, legal, or security rules
- There are multiple possible behaviors for the same use case
- You want to ensure edge cases are covered before technical planning
/speckit.checklist
What you provide
- Can be empty (uses default criteria)
- Domain focus: "validate security requirements"
- Validation of error/loading/empty states
- Check of measurable criteria
What is generated
Requirements quality checklist. Points out gaps before spending time on technical planning.
Typical use
- After /clarify (or directly after /specify in lean flows)
- As a quality gate before investing time in technical planning
Also use when...
- The spec was written by someone else and you want to validate completeness
- The scope grew and you want to check if acceptance criteria still make sense
- You want to focus the validation on a specific domain, such as security or UX
/speckit.plan
What you provide
- Full stack (framework, language, database)
- Architecture (monorepo, microservices, etc.)
- Authentication and authorization
- Main libs and dependencies
- Mandatory technical patterns
- Testing strategy
What is generated
plan.md research.md data-model.md contracts/ quickstart.md
GPT-5.5 thinking: medium-high
Typical use
- After spec validated by /checklist, to define how to build technically
- Once per feature or module, before generating tasks
Also use when...
- The stack changes and the previous plan needs to be redone
- A new integration or external service is added to the scope
- The data model needs a deep architectural revision
/speckit.tasks
What you provide
Usually empty. The agent reads plan.md, data-model.md, contracts/ and research.md automatically.
What is generated
tasks.md
Implementable tasks with dependencies, parallelism markers, and execution order.
GPT-5.5 thinking: medium
Typical use
- Right after /plan has been reviewed and approved
- To turn the architecture into concrete, implementable steps
Also use when...
- The plan was updated and the old tasks became outdated
- You want to identify which tasks can be parallelized across devs
- You need to export the work to GitHub Issues with /taskstoissues
/speckit.analyze
What you provide
Usually empty. The agent cross-checks spec, plan, and tasks automatically.
What it detects
- Spec mentions X but tasks didn't create an endpoint
- Plan uses PostgreSQL but tasks didn't create a migration
- Constitution requires tests but tasks don't include them
- Model missing fields needed by the spec
Typical use
- After generating tasks, as the last gate before /implement
- To ensure spec, plan, and tasks are consistent with each other
Also use when...
- The spec or plan changed after the tasks were already generated
- You suspect some requirement wasn't covered by the tasks
- You want an audit before a big PR or sprint delivery
/speckit.implement
What you provide
Usually empty. The agent executes tasks from tasks.md in sequence.
⚠ The agent may run npm, dotnet, and other local commands. Make sure you have the required tools installed.
What is generated
Real code. File structure, entities, migrations, endpoints, screens, tests — all according to spec + plan + tasks.
GPT-5.5 thinking: medium
Typical use
- After /analyze confirms consistency — this is the moment to code
- To execute tasks in sequence, generating real code
Also use when...
- You want to implement only a subset of tasks (specify which ones)
- Resuming a paused implementation from a specific task
- You need to re-implement a task that caused a bug or was incomplete
/speckit.taskstoissues
What you provide
- Target repository
- Labels to apply
- Milestone and priority
What is generated
GitHub Issues created from tasks.md, ready for triage and assignment.
Typical use
- After /tasks, when the project is managed via GitHub Issues
- To sync the Spec Kit backlog with the team's board
Also use when...
- The team doesn't use Spec Kit directly but follows along via GitHub
- You want to assign milestones, labels, or priorities before implementing
- You need to recreate the issues after a major task revision
Terminal Layer
specify commands
| Command | When to use |
|---|---|
| uv tool install specify-cli --from git+https://github.com/github/[email protected] | Install globally the current version (0.8.13) |
| uvx --from git+https://github.com/github/spec-kit.git specify init <project> | Run without installing globally |
| specify init <project> --integration opencode | Create new project already configured with OpenCode |
| specify init --here --integration opencode | Initialize in the current folder (existing project) |
| specify init --here --force --integration opencode | Initialize in existing folder, overwriting |
| specify init <project> --script sh | Force Bash/Zsh scripts |
| specify init <project> --script ps | Force PowerShell scripts |
| specify check | Check if all required tools are installed |
| specify version | View current CLI version |
| specify version --features | View features supported in this version |
| specify self check | Check if a newer version is available |
| Command | When to use |
|---|---|
| specify integration list | View all supported AI agents |
| specify integration install <key> | Add integration (e.g.: opencode, claude, copilot, cursor-agent) |
| specify integration uninstall [key] | Remove installed integration |
| specify integration switch <key> | Switch the active default integration |
| specify integration use <key> | Use already installed integration without changing the default |
| specify integration upgrade [key] | Update integration files to the newer version |
Supported agents:
copilot · claude · codex · gemini · roo · opencode · qwen · cursor-agent · windsurf | Command | When to use |
|---|---|
| specify extension search [query] | Search for available extensions in the catalog |
| specify extension add <name> | Install an extension (Jira, GitHub Issues, Security Review, etc.) |
| specify extension remove <name> | Remove an installed extension |
| specify extension list | List extensions installed in the project |
| specify extension info <name> | View details of a specific extension |
| specify extension update [name] | Update one or all extensions |
| specify extension enable <name> | Enable a disabled extension |
| specify extension disable <name> | Disable without removing |
| specify extension set-priority <name> <priority> | Resolve priority conflict between extensions |
| specify extension catalog list | List available extension catalogs |
| specify extension catalog add <url> | Add an external extension catalog |
| specify extension catalog remove <name> | Remove a catalog |
💡 Extension = add new capability to the flow (Jira, GitHub Issues, wireframe, QA, architecture, security review, etc.)
| Command | When to use |
|---|---|
| specify preset search [query] | Search for available presets |
| specify preset add [preset_id] | Install a preset |
| specify preset remove <preset_id> | Remove an installed preset |
| specify preset list | List installed presets |
| specify preset info <preset_id> | View details of a preset |
| specify preset resolve <name> | See which template will be used for a given command |
| specify preset enable <preset_id> | Enable a disabled preset |
| specify preset disable <preset_id> | Disable without removing |
| specify preset set-priority <preset_id> <priority> | Set priority between conflicting presets |
| specify preset catalog list | List preset catalogs |
| specify preset catalog add <url> | Add an external preset catalog |
| specify preset catalog remove <name> | Remove a catalog |
💡 Preset = change the format and behavior of existing templates (e.g.: compliance preset, company preset, preset for a specific architecture)
| Command | When to use |
|---|---|
| specify workflow run <source> | Run automated flow (e.g.: Full SDD Cycle) |
| specify workflow resume <run_id> | Resume a flow that paused or failed |
| specify workflow status [run_id] | View current status of a workflow |
| specify workflow list | List installed workflows |
| specify workflow add <source> | Install a new workflow |
| specify workflow remove <workflow_id> | Remove a workflow |
| specify workflow search [query] | Search for available workflows in the catalog |
| specify workflow info <workflow_id> | View details of a workflow |
| specify workflow catalog list | List workflow catalogs |
| specify workflow catalog add <url> | Add an external catalog |
| specify workflow catalog remove <index> | Remove a catalog |
💡 Workflow = automate a sequence of commands with gates and checkpoints. The "Full SDD Cycle" chains specify → plan → tasks → implement with review points.
Golden Rule
The ideal flow for
real projects
constitution
Permanent laws
→
specify
Problem & business rules
→
clarify
Removes ambiguities
→
checklist
Validates requirements
→
plan
Stack & architecture
→
tasks
Implementable steps
→
analyze
Detects contradictions
→
implement
Real code
🔄 New out-of-scope demand? Never implement directly.
Whenever something new comes up, always run first:
/speckit.specify Update the current spec to include the new demand below, without creating
duplicate concepts and keeping compatibility with the existing architecture:
[new demand] # Then continue normally: /speckit.plan → /speckit.tasks → /speckit.analyze → /speckit.implement
⚠ Vibe coding anti-patterns
- Asking "do everything at once" in a giant prompt with no spec, plan, or tasks
- Implementing directly without going through the flow (duplicate entities guaranteed)
- Putting the tech stack in
/speckit.specify— it belongs in/speckit.plan - Skipping
/speckit.analyzeand going straight to implement — contradictions turn into bugs - Not using
constitution— without global rules the agent invents new patterns on every feature