概要
Spec Kit は、スペック駆動開発を実現するオープンソースの CLI ツールキットです。スペックの作成、実装計画の生成、AI コーディングアシスタントと連携したタスクの実行を行うコマンドを提供し、開発者がプロダクトシナリオと予測可能な成果に集中できるよう支援します。
README プレビュー
\n \n 🌱 Spec Kit\n Build high-quality software faster.\n\n\n\n An open source toolkit that allows you to focus on product scenarios and predictable outcomes instead of vibe coding every piece from scratch.\n\n\n\n \n \n \n \n\n\n---\n\n## Table of Contents\n\n- [🤔 What is Spec-Driven Development?](#-what-is-spec-driven-development)\n- [⚡ Get Started](#-get-started)\n- [📽️ Video Overview](#️-video-overview)\n- [🧩 Community Extensions](#-community-extensions)\n- [🎨 Community Presets](#-community-presets)\n- [🚶 Community Walkthroughs](#-community-walkthroughs)\n- [🛠️ Community Friends](#️-community-friends)\n- [🤖 Supported AI Coding Agent Integrations](#-supported-ai-coding-agent-integrations)\n- [🔧 Specify CLI Reference](#-specify-cli-reference)\n- [🧩 Making Spec Kit Your Own: Extensions & Presets](#-making-spec-kit-your-own-extensions--presets)\n- [📚 Core Philosophy](#-core-philosophy)\n- [🌟 Development Phases](#-development-phases)\n- [🎯 Experimental Goals](#-experimental-goals)\n- [🔧 Prerequisites](#-prerequisites)\n- [📖 Learn More](#-learn-more)\n- [📋 Detailed Process](#-detailed-process)\n- [🔍 Troubleshooting](#-troubleshooting)\n- [💬 Support](#-support)\n- [🙏 Acknowledgements](#-acknowledgements)\n- [📄 License](#-license)\n\n## 🤔 What is Spec-Driven Development?\n\nSpec-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.\n\n## ⚡ Get Started\n\n### 1. Install Specify CLI\n\nChoose your preferred installation method:\n\n> **Important:** The only official, maintained packages for Spec Kit are published from this GitHub repository. Any packages with the same name on PyPI are **not** affiliated with this project and are
FAQ (5)
トラブル対応「specify init --ai codex」を実行した際に、SKILL.md内でconstitution.mdが参照されないのはなぜですか？
これはSpecify CLI v0.8.0のバグで、Codex AIを使用した初期化において、.specify/memory/constitution.mdを読み込む指示が省略されていました。この問題は修正されましたので、最新バージョンにアップグレードしてください。
トラブル対応'specify init --ai claude' を実行しても CLAUDE.md が生成されないのはなぜですか？
これは SpecKit v0.4.1 の既知のバグです。回避策として、プロジェクトルートに次の内容で CLAUDE.md を手動で作成してください：
## Claude's Role
Read `.specify/memory/constitution.md` first. It is the authoritative source of truth for this project. Everything in it is non-negotiable.
## SpecKit Commands
- `/speckit.specify` — generate spec
- `/speckit.plan` — generate plan
- `/speckit.tasks` — generate task list
- `/speckit.implement` — execute plan
## On Ambiguity
If a spec is missing, incomplete, or conflicts with the constitution — stop and ask. Do not infer. Do not proceed.このファイルにより、Claude Code はセッション開始時に SpecKit の方法論と憲章を認識します。公式の修正は https://github.com/github/spec-kit/issues/1983 で追跡しています。
トラブル対応カタログが新しいバージョンを告知した後に、ピン留めされた古いコンポーネントに対して `specify bundle install` が失敗するのはなぜですか？
正確な catalog-release および bundle-pin 解決（マルチバージョンカタログとバンドラーの修正）を含む Spec Kit リリースにアップグレードしてください。install-allowed カタログは、URL、checksum、requirements を含むバージョン固有の releases メタデータに古いリリースを保持する必要があり、トップレベルのフィールドは引き続き現在のリリースを識別します。その後、specify bundle install を実行します。バンドラーは、競合解決で勝ち残った trusted ソースから各コンポーネントの正確にピン留めされたバージョンを解決し、checksum とダウンロードされた ID/バージョンを検証し、現在のリリースに置き換えることはなくなりました。リリースを手動で選択するには specify <family> add <id> --version <version> を使用し、利用可能なリリースは specify <family> info <id> --versions で確認します。バンドルの場合、specify bundle add <id> --version <version> はバンドルリリース自体を選択するものであり、bundle.yml 内のコンポーネントピンを上書きしません。trusted な install-allowed ソースのいずれにも要求されたバージョンが含まれていない場合、コマンドは明示的に失敗します。Discovery-only のコミュニティカタログは current-tip のリストのままであり、過去のインストールソースとして使用することはできません。
トラブル対応AI agentsがPR reviewsを繰り返しのコメントごとの返信で溢れさせるのを防ぐ方法？
AGENTS.mdに「PRレビューコメントへの対応」セクションを追加し、以下のルールを設定する：(1) レビューラウンドごとに、個々のレビューコメントではなく、1件のトップレベルのサマリーコメントを投稿する。(2) インライン返信は、不同意、先送り、または明白でない修正の場合のみ使用する。(3) 「会話を解決」をクリックしない。(4) 絵文字、祝賀的なテキスト、またはレビュアーの指摘事項の言い換えを避ける。(5) すべてのフィードバックに対応した後、一度だけ再レビューを依頼する。また、エージェントの自己開示（エージェント名、モデル、人間のアクター）を必須とする。
ハウツートークンを保存せずに GitHub CLI (gh) の認証情報で Specify を認証する方法
Specify にはまだネイティブな github-cli 認証モードがありません(issue #4953 で提案されています)。回避策として、既存の token_env モードを使用します。~/.specify/auth.json で GitHub プロバイダーを "auth": "token_env" および "token_env": "GH_TOKEN" に設定し、トークンをオンデマンドで解決してコマンドを実行します: GH_TOKEN="$(gh auth token)" specify <command>。これにより auth.json にトークンを保存せずに済みますが、呼び出しごとに変数をエクスポートするか、シェルプロファイルで設定する必要があります。計画されている github-cli モードでは、gh auth token が自動的に実行され(実行ごと・ホストごとに一度だけキャッシュされ、シェルは使用せず、gh が見つからない場合や未認証の場合に対するタイムアウトとエラーハンドリングを備えます)、"auth": "github-cli" で設定します。