github/spec-kit
💫 Toolkit to help you get started with Spec-Driven Development
snapshot: 2026-06-05
scraped_at: 2026/06/05 1:51
period stars: +321
stars: 108,601
forks: 9,599
Language: Python
Summary
一覧カードと同じ provider の要約本文です。
Highlights
Spec Kit は「仕様を実行可能にする」ことで実装生成まで導くオープンソースのツールキットです。README にある通り、uv を使って specify-cli をインストールし（例: ）、 からプロジェクトを開始します。主要なワークフローは でプロジェクト原則を作成し、 で「何を作るか」を記述、 で技術的実装計画を作り、 → でタスク生成と実装実行を行います。
Translation
要約とは別に生成された翻訳本文です。
概要: Spec-Driven Development を始めるためのオープンソースツールキット。製品シナリオと予測可能な成果に集中し、ゼロから手探りでコードを書く手間を減らします。
Spec Kit は仕様（spec）を実行可能なアーティファクトとして扱い、仕様から直接実装を導出することで開発を高速化します。つまり、仕様は単なる設計書ではなく、実装を生成・検証するキーです。
Spec-Driven Development は従来の「コードが主役で仕様は補助」から転換し、仕様を実行可能にして実装を直接導出するワークフローです。
依存ツール: uv が必要です（ドキュメント: https://docs.astral.sh/uv/）。最新タグ vX.Y.Z を使って Specify CLI をインストールします。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
プロジェクト初期化:
specify init my-project --integration copilot cd my-project
プロジェクト原則の設定: エージェントのスラッシュコマンドで憲章（constitution）を作成します。
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements
仕様を作成: 何を作るか（what・why）に集中します。
/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.
README
取得した README 原文です。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Zspecify init my-project --integration copilot/speckit.constitution/speckit.specify/speckit.plan/speckit.tasks/speckit.implementREADME に明記されている具体機能:
specify integration list で確認）specify self upgrade 等の自己管理コマンドと uv 前提のインストール動作説明specify extension add / specify preset add による拡張・プリセット導入/speckit.* 系のスラッシュコマンド）と CLI 管理手順は、AI エージェント中心のワークフローへ直接組み込みやすく、実務導入の敷居を下げます。技術的実装計画の作成:
/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.
タスク分割:
/speckit.tasks
実装実行:
/speckit.implement
CLI の自己管理やアップグレード例:
specify self check
specify self upgrade --dry-run
specify self upgrade
specify self upgrade --tag vX.Y.Z[suffix]
uv tool ベースのインストールでは内部的に uv tool install specify-cli --force --from <git ref> を実行します。SPECIFY_UPGRADE_TIMEOUT_SECS でタイムアウトを制限できます（デフォルト: 無制限）。
ドキュメントサイト: https://github.github.io/spec-kit/
主なコンテンツ:
注意: コミュニティ提供の拡張やプリセットは各作者が独立して管理しています。導入前にソースを確認してください。
貢献ガイド:
30+ のエージェント（CLI/IDE）と連携。詳細はインテグレーションリスト（https://github.github.io/spec-kit/reference/integrations.html）を参照。
インストール済みバージョンで利用可能な統合を確認するには:
specify integration list
コアワークフロー向けの主要コマンド:
/speckit.constitution — プロジェクトの原則と開発ガイドラインを作成/更新/speckit.specify — 要件・ユーザーストーリーとして作るものを定義/speckit.plan — 選んだ技術スタックで実装計画を作成/speckit.tasks — 実装のための実行可能なタスクリストを生成/speckit.taskstoissues — タスクリストを GitHub issue に変換して追跡/speckit.implement — 計画に従ってタスクを実行し機能を構築追加の品質向上・検証用コマンド:
/speckit.clarify — 不明瞭な点の明確化（/speckit.plan 前に推奨）/speckit.analyze — アーティファクト間の整合性/カバレッジ分析（/speckit.tasks 後、/speckit.implement 前）/speckit.checklist — 要件の完全性・一貫性を検証するカスタムチェックリスト生成specify extension search, specify extension add <extension-name>specify preset search, specify preset add <preset-name>優先順位（上が高い）:
Project-Local Overrides: .specify/templates/overrides/
Presets: .specify/presets/templates/
Extensions: .specify/extensions/templates/
Spec Kit Core: .specify/templates/
テンプレートはランタイムで解決され、上から順に最初の一致を使用します。プリセットや拡張はインストール時にコマンドファイルがエージェントディレクトリに書き込まれます。
spec-driven.md とドキュメントサイトを参照してください。※ この翻訳は README 抜粋を基にした要約と日本語訳です。コマンド、URL、バージョンタグは原文のまま保持しています。
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.
Requires uv (install uv). Replace vX.Y.Z with the latest tag from Releases:
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.
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.
# 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).
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.
/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements
Use the /speckit.specify command to describe what you want to build. Focus on the what and why, not the tech stack.
/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.
Use the /speckit.plan command to provide your tech stack and architecture choices.
/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.
Use /speckit.tasks to create an actionable task list from your implementation plan.
/speckit.tasks
Use /speckit.implement to execute all tasks and build your feature according to the plan.
/speckit.implement
For detailed step-by-step instructions, see our comprehensive guide.
Want to see Spec Kit in action? Watch our video overview!
Explore community-contributed resources on the Spec Kit docs site:
[!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.
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.
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.
Essential commands for the Spec-Driven Development workflow:
| Command | Agent Skill | Description |
|---|---|---|
/speckit.constitution | speckit-constitution | Create or update project governing principles and development guidelines |
/speckit.specify | speckit-specify | Define what you want to build (requirements and user stories) |
/speckit.plan | speckit-plan | Create technical implementation plans with your chosen tech stack |
/speckit.tasks | speckit-tasks | Generate actionable task lists for implementation |
/speckit.taskstoissues | speckit-taskstoissues | Convert generated task lists into GitHub issues for tracking and execution |
/speckit.implement | speckit-implement | Execute all tasks to build the feature according to the plan |
Additional commands for enhanced quality and validation:
| Command | Agent Skill | Description |
|---|---|---|
/speckit.clarify | speckit-clarify | Clarify underspecified areas (recommended before /speckit.plan; formerly /quizme) |
/speckit.analyze | speckit-analyze | Cross-artifact consistency & coverage analysis (run after /speckit.tasks, before /speckit.implement) |
/speckit.checklist | speckit-checklist | Generate custom quality checklists that validate requirements completeness, clarity, and consistency (like "unit tests for English") |
For full command details, options, and examples, see the CLI Reference.
Spec Kit can be tailored to your needs through two complementary systems — extensions and presets — plus project-local overrides for one-off adjustments:
| Priority | Component Type | Location |
|---|---|---|
| ⬆ 1 | Project-Local Overrides | .specify/templates/overrides/ |
| 2 | Presets — Customize core & extensions | .specify/presets/templates/ |
| 3 | Extensions — Add new capabilities | .specify/extensions/templates/ |
| ⬇ 4 | Spec Kit Core — Built-in SDD commands & templates | .specify/templates/ |
.specify/templates/overrides/) let you make one-off adjustments for a single project without creating a full preset.specify extension add or specify preset add, command files are written into agent directories (e.g., .claude/commands/).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.
# 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.
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.
# 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.
| Goal | Use |
|---|---|
| Add a brand-new command or workflow | Extension |
| Customize the format of specs, plans, or tasks | Preset |
| Integrate an external tool or service | Extension |
| Enforce organizational or regulatory standards | Preset |
| Ship reusable domain-specific templates | Either — presets for template overrides, extensions for templates bundled with new commands |
Spec-Driven Development is a structured process that emphasizes:
| Phase | Focus | Key Activities |
|---|---|---|
| 0-to-1 Development ("Greenfield") | Generate from scratch | <ul><li>Start with high-level requirements</li><li>Generate specifications</li><li>Plan implementation steps</li><li>Build production-ready applications</li></ul> |
| Creative Exploration | Parallel implementations | <ul><li>Explore diverse solutions</li><li>Support multiple technology stacks & architectures</li><li>Experiment with UX patterns</li></ul> |
| Iterative Enhancement ("Brownfield") | Brownfield modernization | <ul><li>Add features iteratively</li><li>Modernize legacy systems</li><li>Adapt processes</li></ul> |
Our research and experimentation focus on:
If you encounter issues with an agent, please open an issue so we can refine the integration.
You can use the Specify CLI to bootstrap your project, which will bring in the required artifacts in your environment. Run:
specify init <project_name>
Or initialize in the current directory:
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
In an interactive terminal, you will be prompted to select the coding agent integration you are using. In non-interactive sessions, such as CI or piped runs, specify init defaults to GitHub Copilot unless you pass --integration. You can also proactively specify the integration directly in the terminal:
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
The CLI will check if you have Claude Code, Gemini CLI, Cursor CLI, Qwen CLI, opencode, Codex CLI, Qoder CLI, Tabnine CLI, Kiro CLI, Pi, Forge, Goose, or Mistral Vibe installed. If you do not, or you prefer to get the templates without checking for the right tools, use --ignore-agent-tools with your command:
specify init <project_name> --integration copilot --ignore-agent-tools
Go to the project folder and run your coding agent. In our example, we're using claude.
You will know that things are configured correctly if you see the /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, and /speckit.implement commands available.
The first step should be establishing your project's governing principles using the /speckit.constitution command. This helps ensure consistent decision-making throughout all subsequent development phases:
/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.
This step creates or updates the .specify/memory/constitution.md file with your project's foundational guidelines that the coding agent will reference during specification, planning, and implementation phases.
With your project principles established, you can now create the functional specifications. Use the /speckit.specify command and then provide the concrete requirements for the project you want to develop.
[!IMPORTANT] Be as explicit as possible about what you are trying to build and why. Do not focus on the tech stack at this point.
An example prompt:
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.
After this prompt is entered, you should see Claude Code kick off the planning and spec drafting process. Claude Code will also trigger some of the built-in scripts to set up the repository.
Once this step is completed, you should have a new branch created (e.g., 001-create-taskify), as well as a new specification in the specs/001-create-taskify directory.
The produced specification should contain a set of user stories and functional requirements, as defined in the template.
At this stage, your project folder contents should resemble the following:
.
├── .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
With the baseline specification created, you can go ahead and clarify any of the requirements that were not captured properly within the first shot attempt.
You should run the structured clarification workflow before creating a technical plan to reduce rework downstream.
Preferred order:
/speckit.clarify (structured) – sequential, coverage-based questioning that records answers in a Clarifications section.If you intentionally want to skip clarification (e.g., spike or exploratory prototype), explicitly state that so the agent doesn't block on missing clarifications.
Example free-form refinement prompt (after /speckit.clarify if still needed):
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.
You should also ask Claude Code to validate the Review & Acceptance Checklist, checking off the things that are validated/pass the requirements, and leave the ones that are not unchecked. The following prompt can be used:
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.
It's important to use the interaction with Claude Code as an opportunity to clarify and ask questions around the specification - do not treat its first attempt as final.
You can now be specific about the tech stack and other technical requirements. You can use the /speckit.plan command that is built into the project template with a prompt like this:
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.
The output of this step will include a number of implementation detail documents, with your directory tree resembling this:
.
├── 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
Check the research.md document to ensure that the right tech stack is used, based on your instructions. You can ask Claude Code to refine it if any of the components stand out, or even have it check the locally-installed version of the platform/framework you want to use (e.g., .NET).
Additionally, you might want to ask Claude Code to research details about the chosen tech stack if it's something that is rapidly changing (e.g., .NET Aspire, JS frameworks), with a prompt like this:
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.
During this process, you might find that Claude Code gets stuck researching the wrong thing - you can help nudge it in the right direction with a prompt like this:
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.
[!NOTE] Claude Code might be over-eager and add components that you did not ask for. Ask it to clarify the rationale and the source of the change.
With the plan in place, you should have Claude Code run through it to make sure that there are no missing pieces. You can use a prompt like this:
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.
This helps refine the implementation plan and helps you avoid potential blind spots that Claude Code missed in its planning cycle. Once the initial refinement pass is complete, ask Claude Code to go through the checklist once more before you can get to the implementation.
You can also ask Claude Code (if you have the GitHub CLI installed) to go ahead and create a pull request from your current branch to main with a detailed description, to make sure that the effort is properly tracked.
[!NOTE] Before you have the agent implement it, it's also worth prompting Claude Code to cross-check the details to see if there are any over-engineered pieces (remember - it can be over-eager). If over-engineered components or decisions exist, you can ask Claude Code to resolve them. Ensure that Claude Code follows the constitution in
.specify/memory/constitution.mdas the foundational piece that it must adhere to when establishing the plan.
With the implementation plan validated, you can now break down the plan into specific, actionable tasks that can be executed in the correct order. Use the /speckit.tasks command to automatically generate a detailed task breakdown from your implementation plan:
/speckit.tasks
This step creates a tasks.md file in your feature specification directory that contains:
[P] to optimize development workflowThe generated tasks.md provides a clear roadmap for the /speckit.implement command, ensuring systematic implementation that maintains code quality and allows for incremental delivery of user stories.
Once ready, use the /speckit.implement command to execute your implementation plan:
/speckit.implement
The /speckit.implement command will:
tasks.md[!IMPORTANT] The coding agent will execute local CLI commands (such as
dotnet,npm, etc.) - make sure you have the required tools installed on your machine.
Once the implementation is complete, test the application and resolve any runtime errors that may not be visible in CLI logs (e.g., browser console errors). You can copy and paste such errors back to your coding agent for resolution.
For support, please open a GitHub issue. We welcome bug reports, feature requests, and questions about using Spec-Driven Development.
This project is heavily influenced by and based on the work and research of John Lam.
This project is licensed under the terms of the MIT open source license. Please refer to the LICENSE file for the full terms.