要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。
要件が確定した後、コードを書く前に設計を対話で固める。 人間パートナーとの対話を通じて設計の選択肢を検討し、合意した設計を design.md にまとめる。
入力: REQ パス（例: requirements/REQ-001/）+ 承認済みの requirements.md 全文
出力: docs/design/{slug}.md（設計の SSOT）+ docs/decisions/NNNN-*.md（ADR）
原則: 要件が「何を作るか」を決めるなら、設計は「どう作るか」を決める。設計なしの実装は、地図なしで家を建てるようなものだ。
設計承認なしにコードを書くな
「要件があるから設計は不要」→ 要件は振る舞いを定義する。設計は構造を定義する。別の話だ。
| スキル |
|---|
| 問い |
|---|
| 対話の性質 |
|---|
| requirements | What + Why（何を作るか） | スコープ・受入条件を詰める |
| design | How（どう作るか） | 設計の背景・経験・懸念を深掘りし、一緒に設計を決める |
| planning | When/Order（いつ・どの順で） | タスク分解（対話少。分解の承認のみ） |
常に:
例外（人間パートナーに確認すること）:
| 担当 | 責務 | できること |
|---|---|---|
| メインセッション（あなた） | 対話・評価・意思決定 | AskUserQuestion、判断、design.md 作成 |
| Explore エージェント | コードベース/ドキュメント調査 | Read, Grep, Glob（調査のみ） |
| design-reviewer（サブエージェント） | 設計の検証 | 要件カバレッジチェック（Read only） |
鉄則: 対話はサブエージェントに委譲するな。対話はメインセッションの責務だ。
digraph design {
rankdir=TB;
input [label="要件確定\nrequirements.md", shape=ellipse];
explore [label="調査\nExplore エージェント\n(コード/設計パターン調査)", shape=box, style=filled, fillcolor="#cce5ff"];
dialog [label="設計の深掘り対話\n背景・経験・懸念を聞く\nAskUserQuestion", shape=box, style=filled, fillcolor="#ccffcc"];
create [label="設計ドキュメント作成\ndocs/design/{slug}.md\ndocs/decisions/NNNN-*.md", shape=box, style=filled, fillcolor="#ccccff"];
review [label="設計レビュー\ndesign-reviewer\n(要件カバレッジ検証)", shape=box, style=filled, fillcolor="#ffffcc"];
must_check [label="MUST指摘\nあり？", shape=diamond];
approve [label="人間パートナーの\n承認", shape=diamond];
done [label="設計確定\n→ 次のステップへ", shape=ellipse];
input -> explore;
explore -> dialog;
dialog -> create;
create -> review;
review -> must_check;
must_check -> create [label="あり\n設計を修正"];
must_check -> approve [label="なし"];
approve -> done [label="承認"];
approve -> dialog [label="修正\n要求"];
}
Explore エージェントにコードベース・ドキュメントの調査を委譲する。
調査対象:
調査結果から「既に決まっていること」「まだ決まっていないこと」「設計の選択肢」を整理する。
AskUserQuestion でユーザーと対話しながら設計を詰める。
対話の進め方:
やってはいけないこと:
設計の論点（参考）:
| 論点 | 質問例 |
|---|---|
| アーキテクチャ | どのような責務の分割を考えている？テストしやすさとシンプルさのどちらを優先する？ |
| データモデル | このデータはどこに持つべきか？変更頻度は？ |
| 依存関係 | 既存のどのモジュールと連携する？外部サービスへの依存はどう扱う？ |
| エラーハンドリング | エラーをどの層で捕捉し、どう伝播させる？ |
| テスト戦略 | どの層に重点的にテストを置く？外部依存のモックはどこまで許容する？ |
合意した設計を docs/design/{slug}.md に作成する。
設計判断を docs/decisions/NNNN-*.md に ADR として記録する。
ADR 作成のルール:
design-reviewer サブエージェントに設計の要件カバレッジを検証させる。
検証の観点:
結果の対応:
人間パートナーに design.md を提示し、承認を得る。 承認後、status を Approved に更新する。 次のステップ（planning or tdd）に進む。
docs/design/{slug}.md # 設計の SSOT
docs/decisions/NNNN-*.md # ADR（設計判断ごとに1ファイル）
ADR が不要なケース: 設計上の選択肢が1つしかなく、判断の記録が不要な場合。
---