グリル → スペック駆動開発は何をしますか？

2つのワークフローを連続して実行し、1つのハンドオフでつなぎます：

グリル（Matt Pocock、grill-me → to-spec）：ユーザーを設計ツリーとしてラウンドごとにインタビューし、暗黙の前提がなくなるまで続けます。その後、合意された理解をスペックにまとめます（新たな質問はしません）。
構築（DeepLearning.AI + JetBrains、コーディングエージェントによるスペック駆動開発）：スペックは日付付きディレクトリの下に requirements.md、plan.md、validation.md としてリポジトリに配置され、独自のブランチ上でタスクグループごとに実装され、validation.md に照らして検証され、チェンジログに記録され、マージされ、ロードマップが再計画されます。

グリルは、SDDコースの固定3質問インタビュー（スコープ/決定/コンテキスト）を完全な設計ツリーインタビューに置き換えます。SDDコースは、to-spec の「課題追跡システムに公開する」を、コードと共にあり変更と共に進化するスペックファイルに置き換えます。

概要

使用するタイミング：変更が大きく、事前に文書化した方が手戻りより安上がりな場合（新機能、ロードマップフェーズ、MVPスプリント、レガシーコードベースへのSDD導入など）。1行修正や純粋なバグハントにはスキップします（根本原因分析には pstack-engineering を使用）。

トリガーフレーズ： 「grill me then spec it」「grill to spec」「spec-driven」「SDD」「feature spec」「work on the next phase」「start the next feature」。

ハードゲート（絶対にスキップしない）：

ユーザーがグリルが共有理解に達したことを確認するまで、スペックファイルは書きません（ゲートA）。
ユーザーがスペックファイルを承認するまで、コードは書きません（ゲートB）。
validation.md のすべての項目がパスするまで、何もマージしません（ゲートC）。

実行手順

SPECS=${SDD_SPECS_DIR:-specs} と BASE=${SDD_BASE_BRANCH:-<リポジトリのデフォルトブランチ>} を開始時に解決します。以下のパスはプロジェクトルートからの相対パスです。

ステージ0 — 状況把握（事実確認はあなたの仕事）

プロジェクトの AGENTS.md / CLAUDE.md、README.md、および用語集やADRを読みます。リポジトリ自身のgitルール（ラッパー、ブランチ命名、force-push禁止）に従います。
憲法の存在を確認します：$SPECS/mission.md、$SPECS/tech-stack.md、$SPECS/roadmap.md。
- すべて存在する → 次の機能のためにステージ1へ進みます。
- 欠落している、新規プロジェクト → 最初のグリルは憲法そのものについて（ミッション、ターゲットユーザー、技術スタックのギャップ）です。その出力は3つのファイルで、roadmap.md は 非常に小さな フェーズ（それぞれ独立してリリース可能）に分割します。
- 欠落している、既存コードベース（レガシー） → まずコードを探索し、実際に存在するもの（スタック、規約、完了フェーズとしての出荷済み機能）から憲法をドラフトし、ギャップと将来のロードマップのみをグリルします。
ユーザーが機能名を指定しなかった場合、ターゲットは 次のフェーズ です。ロードマップの最初のセクションで、項目がすべて未チェック（[ ]）のものです。
機能が触れるコードを探索します。リポジトリ、ツール、ドキュメントで答えられる質問を決してユーザーに聞かないでください。広範な探索は、ハーネスにサブエージェント機能があれば新しいサブエージェントに委任し、関連のない質問をブロックしないでください。

ステージ1 — グリル（設計ツリーインタビュー）

共有理解に達するまで、ユーザーを容赦なくインタビューします。計画を設計ツリーとして扱います：すべての決定は、それに依存する決定へと分岐します。

ラウンドで作業します。フロンティアは、前提条件がすでに確定している未解決の決定すべてです。1ラウンドでフロンティア全体を質問し、回答を待ちます。
各質問に番号を付け、推奨回答を示します。「はい」が推奨を受け入れるように文言を調整します。
別の質問に依存し、その質問がまだ同じラウンドで未解決のものは、後のラウンドに属します。
ラウンドを通じて、少なくともSDDの軸をカバーします：スコープ（収集、公開、実行するもの、データ形状）、決定（ストレージ、可視性、バリデーション、UXパターン、アーキテクチャ）、コンテキスト（トーン、制約、スタック制限、未解決の質問）、およびテストシーム：機能がテストされる場所。既存のシームと可能な限り上位のシームを優先します。理想的には1つです。
新しい依存関係、スキーマ変更、公開API変更は常に明示的な質問であり、決して暗黙の前提としません（tech-stack.md が権威です）。

ラウンドのフォーマット：

❓ **Q1** - **<タイトル>**：<質問、オプションがある場合>

➡️ <推奨回答>

---

❓ **Q2** - ...

ハーネスに構造化質問ツール（Claude Codeの AskUserQuestion）がある場合、最大4つの選択肢があるラウンドにそれを使用できます。それ以外の場合は上記のテキストフォーマットを使用します。

グリルはフロンティアが空になった時点で終了します。確定した決定を短いリストにまとめ、ユーザーに確認を求めます。

ゲートA： ユーザーがサマリーを確認するまで先に進まないでください。

ステージ2 — スペック化（統合、新たな質問はしない）

会話をスペックに変換します。再度インタビューしてはいけません。本当のギャップが現れた場合、それはグリルが分岐を見逃したことを意味します。その質問1つだけを聞き、その後再開します。

$BASE からブランチを作成します：ロードマップフェーズの場合は phase-<N>-<ケバブ名>、それ以外の場合は feature/<ケバブ名>（またはリポジトリ独自の規則に従う）。
$SPECS/mission.md と $SPECS/tech-stack.md、および既存の機能スペックを再読してハウススタイルを把握します。
今日の日付で $SPECS/YYYY-MM-DD-<機能名>/ を作成し、references/spec-templates.md から3つのファイルを書き出します：
- requirements.md — to-spec の内容（問題、解決策、番号付きのユーザーストーリーの広範なリスト、実装上の決定、テスト上の決定、スコープ外）に加えて、SDDのスコープ/決定/コンテキストセクション。ファイルパスやコードスニペットは含めません。ただし、決定を散文より正確に固定するトリミングされたプロトタイプスニペットは除きます。
- plan.md — 番号付きのタスクグループ。それぞれが独立して実装可能かつテスト可能で、番号付きのサブタスクを持ちます。
- validation.md — 自動チェック（正確なコマンド）、手動ウォークスルー、エッジケース、ユーザー向けコピーのトーンチェック、およびDoneの定義。
オプション（ユーザーが要求した場合、またはリポジトリが課題で作業を追跡している場合）：要件を課題として公開もします（gh issue create）し、requirements.md からリンクします。
3つのファイルをユーザーに示します（パスと短い要約）。

ゲートB： 承認を待ちます。フィードバック（「Xのタスクグループを追加」「コンポーネントは独自のファイルに」）は最初にスペックに適用され、すべてのファイルは同期が保たれます。

ステージ3 — 実装

タスクグループを順番に実装します。各グループの後：プロジェクトのテストと型チェックを実行し、グループ名をメッセージに含めてコミットし、plan.md の該当ボックスにチェックを入れます。
実装によりスペックが間違っているか不完全であることが判明した場合、スペックから逸脱するコードと同じコミットでスペックを更新します。スペックとコードは決して乖離しません。
相互に依存関係のないグループは、並列サブエージェントに任せてもかまいません（各サブエージェントは独自のワークツリーを使用し、ホストのワークツリールールに従い、あなたがマージします）。
グループが「必要」としても、ユーザーの承認なしに新しい依存関係を追加してはいけません。

ステージ4 — 検証

validation.md のすべての自動チェックを実行し、実際の出力を貼り付けます。
手動チェックをウォークスルーします（UIの場合、実際に操作します：ブラウザ自動化またはスクリーンショット。「動作するはず」ではダメです）。
オプションの詳細レビュー：ブランチの差分に対して3つの視点（正確性、スペック準拠、保守性）からレビュアーを起動し、問題を修正します。
構築された内容に照らしてスペックを明確化する必要があるかどうかをユーザーに尋ねます。

ゲートC： Doneの定義のすべての項目がパスするか、ユーザーが明示的に1つを放棄します（放棄は validation.md に記録します）。

ステージ5 — ループを閉じる

$SPECS/roadmap.md でフェーズが完了したことをマークします（[x]）。
CHANGELOG.md を更新します（# Changelog、## YYYY-MM-DD 見出しは新しい順、最後に記録された日付以降の意味のある変更ごとに1つの箇条書き）。プロジェクトに changelog スキルが存在すればそれを使用します。
コミットし、$BASE に切り替え、ブランチをマージし、削除し、リポジトリのルールに従ってプッシュします。
再計画： 学んだことによって mission.md、tech-stack.md、またはロードマップが変更されるかどうかを尋ねます（フェーズのマージ、分割、または順序変更）。横断的な決定（例：「Vitestを使う」「レスポンシブUI」）は tech-stack.md / mission.md に入れ、既存のスペックにバックポートされます。
次のフェーズを提案します：再びステージ1から始まります。

環境変数

変数	デフォルト	説明
`SDD_SPECS_DIR`	`specs`	プロジェクトルートからの相対パスで、憲法と機能スペックのディレクトリ
`SDD_BASE_BRANCH`	リポジトリのデフォルトブランチ	機能ブランチを作成しマージするベースブランチ

検証チェックリスト

既知の落とし穴

永遠にグリルし続ける。 グリルはフロンティアが空になった時点で終了します。好奇心が尽きた時点ではありません。確定した決定を再質問しないでください。コードレビューに属する詳細を尋ねないでください。
スペック化でインタビューする。 ステージ2は統合です。そこでの新たな質問は、グリルが不完全だったことを意味します。1つの不足質問を尋ねるのであって、2回目のインタビューではありません。
ゲートA/Bの前に書き始める。 SDDコースは明確です：インタビューに回答されるまで、ディスクには何も書きません。スペック承認前のコードは手法を台無しにします。
フェーズが大きすぎる。 1回のレビューで終えられないフェーズは、スペック作成前にロードマップで分割する必要があります。
スペックの乖離。 実装途中で要求された変更は、最初にスペックに適用し、次にコードに適用します。コードと一致しなくなったスペックは、ないより悪いです。
要件にファイルパスを書く。 すぐに腐ります。代わりにモジュールとインターフェースを記述してください（パスは最大でも plan.md のサブタスクに）。
リポジトリルールが優先される。 リポジトリの AGENTS.md からのブランチ名、プッシュラッパー、ワークツリーの場所、帰属ルールは、ここでのデフォルトを上書きします。

ファイルテンプレートについては references/spec-templates.md、各部分の出典については references/sources.md を参照してください。

グリル → スペック駆動開発