Menü
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
| name | design |
| description | 要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を 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つしかなく、判断の記録が不要な場合。
---
status: Draft | Approved
owner: [担当者]
last_updated: YYYY-MM-DD
covers: [REQ-001, REQ-002 等]
---
# <タイトル>
## 設計概要
[選択した設計アプローチの要約。1-3文]
## アーキテクチャ
[モジュール構成、レイヤー分割、依存方向]
## ディレクトリ構造
[具体的なファイル配置]
## インターフェース設計
[API、関数シグネチャ、データ構造]
## 設計判断
[各判断は docs/decisions/ の ADR を参照]
| 判断 | ADR | 選択 | 理由 |
|------|-----|------|------|
| [何を決めたか] | [ADR-NNNN] | [選んだもの] | [なぜ] |
## 影響範囲
- 変更対象
- 新規作成
- 依存する既存コード
## 未解決事項（あれば）
# NNNN: <判断のタイトル>
- **Status**: Accepted | Superseded | Deprecated
- **Date**: YYYY-MM-DD
- **Covers**: [REQ-001 等]
## 背景
[なぜこの判断が必要だったか。解決しようとした問題は何か]
## 選択肢
### 選択肢 A: [名前]
- 概要: [何をするか]
- メリット: [利点]
- デメリット: [欠点・トレードオフ]
### 選択肢 B: [名前]
- 概要: [何をするか]
- メリット: [利点]
- デメリット: [欠点・トレードオフ]
## 決定
[選択した選択肢と理由]
## 結果
[この決定によって生じる影響・制約]
| 言い訳 | 現実 |
|---|---|
| 「要件を見れば設計は自明」 | 自明に見える設計ほど実装で崩れる |
| 「実装しながら設計する」 | 設計の手戻りは実装の手戻りより高い |
| 「ドキュメントを書く時間がない」 | 設計ドキュメントを読む時間は実装の何倍も速い |
| 「この程度の機能に設計は大げさ」 | 小さい機能でも隣接するコードへの影響がある |
| 「承認なしに始める」 | 承認なしの設計で実装を始めると、方向性の不一致が後半で露出する |
| 「ADR を書いていいですか？」 | 設計判断があるなら黙って書け。ADR は承認対象ではなく記録そのもの |
| 「ADR を書いた、レビューしますか？」 | ADR は design.md の一部として Phase 4 で design-reviewer に渡される。個別承認不要 |
以下のどれかに当てはまったら、設計に戻れ。
設計確定前に確認:
| 問題 | 解決策 |
|---|---|
| 設計の選択肢が出てこない | Explore エージェントに既存パターンの調査を委譲 |
| トレードオフが判断できない | 「重視している観点（テスト容易性/シンプルさ/拡張性）」を人間に聞く |
| 設計が大きくなりすぎる | REQ を分割する。1つの design.md = 1つの REQ |
| レビューで MUST 指摘が繰り返される | 設計の根本的な方向性を見直す。Phase 2 に戻って対話する |
あなたはこのスキルの対話プロセスを自分で実行する。ただし調査とレビューは委譲する。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
Claude Code 組み込みの Explore エージェント（subagent_type: "Explore"）をディスパッチしてコードベースを調査する
調査結果を整理し、設計の論点を特定する
AskUserQuestion で対話を行い、設計を合意する
design.md と ADR を作成する（承認不要、自動的に書け）
docs/design/{slug}.md にまとめるdocs/decisions/NNNN-*.md に ADR として自動的に記録するdocs/decisions/ を確認して採番）design-reviewer エージェントをディスパッチして設計をレビューする
design-reviewer は要件カバレッジ・スコープ整合性・インターフェース整合性を検証するレビュー結果に対応する
承認後、次のステップに進む
前提スキル:
必須ルール:
出力:
docs/design/{slug}.md — 設計の SSOTdocs/decisions/NNNN-*.md — ADR（設計判断がある場合）次のステップ:
このスキルの出力を参照するエージェント: