はじめに
specify init を実行すると、さっきまで空だったフォルダに、いくつかのディレクトリとファイルが一気に生成されます。「これは何のファイル？」「勝手にできたけど触っていいの？」——最初に戸惑うのがこの部分です。
ですが、中身の役割さえ分かってしまえば、Spec Kit が「AI への指示（プロンプト）＋プロジェクトのルール（constitution）＋各種テンプレート」の組み合わせで動いていることが見えてきます。この記事では、生成される .github / .specify / .vscode の3つを順にのぞいて、それぞれが何を担っているのかを解説します。
この記事で分かること
-
specify initが生成する3つのディレクトリの役割が分かる -
.github/agentsと.github/promptsの違いと、なぜ両方あるのかが分かる - カスタムエージェントとスラッシュコマンドの関係が理解できる
-
constitution/scripts/templatesがそれぞれ何を担うか分かる - どこを触るべきで、どこは触らなくていいかが判断できる
以下の説明は、コーディングエージェントに GitHub Copilot（VS Code） を選んだ場合の構成です。Claude Code や Codex CLI など別のエージェントを選んだ場合は、それぞれの仕様に沿った別の場所・ファイル名で生成されます。基本的な考え方（指示・ルール・テンプレート）は共通です。
第1章：まず全体像 ― 生成される3つのディレクトリ
初期化直後のプロジェクトは、ざっくり次の3つに分かれます。
ファイルツリーにすると、Copilot を選んだ場合はおおむね次のような形になります（含まれるコマンドやファイル名はバージョンによって変わります）。
人事管理システム/
├── .github/
│ ├── agents/ # 選択して使うエージェント本体
│ │ ├── speckit.constitution.agent.md
│ │ ├── speckit.specify.agent.md
│ │ ├── speckit.plan.agent.md
│ │ ├── speckit.tasks.agent.md
│ │ ├── speckit.analyze.agent.md
│ │ └── ... # コマンドごとに1ファイル
│ └── prompts/ # スラッシュコマンド用（agents と対になる）
│ ├── speckit.constitution.prompt.md
│ ├── speckit.specify.prompt.md
│ └── ...
├── .specify/
│ ├── memory/
│ │ └── constitution.md # プロジェクトの憲法（ルール）
│ ├── scripts/ # SpecKit が内部で使うスクリプト
│ │ ├── bash/ # .sh 版
│ │ └── powershell/ # .ps1 版
│ └── templates/ # 生成ドキュメントのひな形
│ ├── plan-template.md
│ ├── spec-template.md
│ ├── tasks-template.md
│ └── agent-file-template.md
└── .vscode/
└── settings.json # エディタ設定
それぞれ詳しく見ていきましょう。
第2章：.github ― エージェントとスラッシュコマンド
.github の中には agents と prompts という2つのフォルダが入っています。ここが Spec Kit のコマンド群の実体です。
agents：エージェント本体（指示の中身）
agents フォルダには、speckit.analyze.agent.md のように コマンドごとに1ファイル が並びます。中を開くと、かなり長い英語のプロンプト（AI への詳細な指示）が書かれています。これが「そのコマンドで AI に何をさせるか」を定義している本体です。
このファイル群は、VS Code の Copilot チャットにある エージェントの選択ドロップダウン に追加されます。標準では Ask（質問）・Edit（編集）・Agent（実装）・Plan（計画）といった組み込みのエージェントが用意されていますが、そこに Spec Kit 由来のエージェントが加わる形です（組み込みの顔ぶれはバージョンで変わり得ます）。
VS Code の「カスタムエージェント」は、以前は「カスタムチャットモード（.chatmode.md）」と呼ばれていた機能が名前と形式を変えたものです。.github/agents フォルダに置いた .agent.md ファイルが、独自のエージェントとして認識されます。名前・説明・使えるツール・MCP サーバなどをフロントマターに書いて、エージェントの振る舞いを定義できます。
prompts：スラッシュコマンド用（agents を参照）
一方 prompts フォルダには、speckit.analyze.prompt.md のようなファイルが入っています。こちらは中身がとてもシンプルで、多くは対応する agents 側の定義（speckit.analyze）を参照するだけの作りになっています。
これは、Copilot チャットで /（スラッシュ）を入力したときに出てくる スラッシュコマンド の入り口です。/speckit.specify のように打つと、対応する処理を呼び出せます。
なぜ agents と prompts の両方があるのか
この二重構成には経緯があります。以前はエージェントを選ぶ仕組みがなく、スラッシュコマンド（prompts）だけ で Spec Kit を使っていました。その後、エージェントを選択して切り替えられる仕組み（agents）が加わったため、こちらの方が便利に使えるようになりました。
ただし、従来どおりスラッシュコマンドで使っている人もいます。そこで スラッシュコマンドも残したまま、prompts 側から agents を参照する ことで、「エージェント選択」と「スラッシュコマンド」のどちらの入り口からでも同じ処理を呼べるようにしているわけです。
図のとおり、入り口は2つでも、最終的にたどり着く指示の本体（agents 側）は共通です。だから、どちらで呼んでも同じ動作になります。
agents と prompts の中身は Spec Kit が管理する部分です。仕組みの理解として眺めるのは有益ですが、通常の開発でここを直接書き換える必要はほとんどありません。挙動を細かく調整したいときだけ、内容を把握したうえで慎重に触るのが安全です。
第3章：.specify ― プロジェクトの記憶とテンプレート
.specify の中には memory / scripts / templates の3つが入っています。ここは Spec Kit がドキュメント生成を進めるための土台です。
memory/constitution.md：プロジェクトの憲法
memory には constitution.md（憲法）が入っています。フォルダ名が「記憶（memory）」である通り、ここにはプロジェクトの一番ベースとなるルールが記録されていきます。
初期状態では、英語で書かれたテンプレートが入っています。中を見ると Core Principles（コア原則）という項目があり、例として Library-First（機能はまず独立したライブラリとして作る）のような原則が挙げられています。これはあくまでひな形で、実際には後のステップ（/speckit.constitution の実行など）を通じて、プロジェクト固有の非交渉ルールがここに書き込まれていきます。以降の計画・タスク・実装は、この憲法に従って進みます。
scripts：Spec Kit が内部で使うスクリプト
scripts には、計画を立てる・タスクを作るといった工程で Spec Kit が使うスクリプトが入っています。Bash（.sh）版と PowerShell（.ps1）版の両方が用意されており、OS に応じて使い分けられます。これらは Spec Kit が必要に応じて自動で実行するので、基本的に自分でいじる場所ではありません。
templates：生成ドキュメントのひな形
Spec Kit は「AI がドキュメントを生成しながら進める」ツールです。templates には、その生成物のひな形が入っています。たとえば plan-template.md は計画ドキュメントのテンプレート、spec-template.md は仕様、tasks-template.md はタスク一覧のテンプレートです。それぞれの Markdown が生成されるときに、対応するテンプレートが下敷きになります。ここも通常は気にしなくて構いません。
.vscode ― エディタ設定
最後は .vscode です。中には settings.json が入っており、これは VS Code エディタ自体の設定を書く場所です。
Spec Kit の初期化では、ここに Spec Kit のエージェントやコマンドを有効にするための設定（true などの値）がマージされます。おかげで、生成されたエージェント／コマンドが自動的に使える状態になっています。ここも自分で書き換える必要は基本的にありません。
まとめ：どこを触る？触らない？
specify init が最初に生成するファイル群は、実装中に自分で開いたり書き換えたりすることはほとんどない部分です。「仕組みを理解しておくためのもの」と捉えておけば十分です。役割を早見表にまとめます。
| 場所 | 役割 | 普段触る？ |
|---|---|---|
.github/agents |
エージェント本体（AIへの指示の中身） | 基本さわらない |
.github/prompts |
スラッシュコマンド用（agents を参照） | 基本さわらない |
.specify/memory/constitution.md |
プロジェクトのルール（憲法） | コマンド経由で更新される |
.specify/scripts |
内部実行スクリプト（sh / ps1） | さわらない |
.specify/templates |
生成ドキュメントのひな形 | さわらない |
.vscode/settings.json |
エディタ設定（エージェント有効化など） | さわらない |
理解度チェックリスト
-
.githubはAIへの指示・コマンド、.specifyはルールとテンプレート、.vscodeはエディタ設定、と役割を言える -
agentsはエージェント本体、promptsはスラッシュコマンド用で agents を参照している、と説明できる - スラッシュコマンドとエージェント選択の「入り口は2つ・本体は共通」の関係が分かる
-
constitution.mdがプロジェクトの一番の土台（ルール）だと理解した -
scriptsとtemplatesは自動で使われる部分で、基本さわらないと把握した - 別のエージェント（Claude Code / Codex CLI 等）では生成場所が変わることを知っている
仕組みが分かると、Spec Kit が「魔法」ではなく、丁寧に用意されたプロンプトとルールの集合体だと腑に落ちます。ここを押さえておくと、次のステップで実際に /speckit.* コマンドを回していくときも、何が起きているのかを見失わずに進められます。