| name | design-gate |
| description | Design Gate を実施し、設計書(Design Artifact)を生成・評価する。Use when: high-risk 以上のタスクで実装前に設計を整理したい時。「設計書を作りたい」「Design Gate を通したい」「実装前に設計レビューをしたい」。 |
Design Gate
high-risk 以上のタスクで実装前に設計書(Design Artifact)を生成・評価する。
参照解決順(.claude/rules/*.md / 導入先で必ずこの順に探す)
本 Skill は Mode 判定の正本として .claude/rules/mode-classification.md を参照する(§関連)。
このパスは上流リポジトリ基準のため、導入先では 次の順で探索する:
- 導入先リポジトリの
.claude/rules/mode-classification.md
- 無ければ plugin root 配下
<plugin_root>/rules/mode-classification.md。
<plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した
絶対パス(Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/...
という文字列をそのまま Read しない)。変数が空・未設定ならキャッシュを glob で推測せず 3 へ進む
- どちらにも無い場合は 「正本
mode-classification.md を参照できなかった」と明示し、
推測で内容を補わない
Iron Law
NO CODE WITHOUT APPROVED DESIGN FIRST
high-risk 以上のモードでは、Design Artifact の 8 項目が揃い承認されるまで実装を開始しない。
Common Rationalizations
| こう思ったら | 現実 |
|---|
| 「シンプルだから設計不要」 | シンプルなほど設計は速い。10 分の設計が数時間の手戻りを防ぐ |
| 「急いでいるから省略」 | 設計なしの実装は後で手戻りになる。急ぐほど設計が必要 |
| 「前に似たことをやった」 | コードベースは変化する。前回の前提が今回も成立するとは限らない |
| 「PoC だから後で直す」 | PoC は往々にして本番コードになる。設計の借金は複利で増える |
Design Artifact 8 項目の入力フォーム
以下の質問にすべて答えることで Design Artifact が完成する。
1. 問題定義
質問: 何が問題か?
- 現状はどうなっているか
- どのような課題・不便が発生しているか
- なぜ今対応が必要か(背景・トリガー)
2. 目的
質問: なぜ解決するか?
- このタスクで達成したいゴールは何か
- 解決後にどのような状態になっていてほしいか(期待効果)
3. 非目的
質問: 今回対応しないことは?
- スコープ外として明示的に除外するもの
- 「やらない」と決めた理由
4. 仕様
質問: 何を作るか?(具体的な機能要件)
- 実装する機能・コンポーネントを列挙する
- 入力・処理・出力を明示する
- 受入基準(Acceptance Criteria)を記述する
5. 代替案
質問: 他に検討したアプローチは?(最低 2 案)
| 案 | 概要 | メリット | デメリット |
|---|
| 案 1 | ... | ... | ... |
| 案 2 | ... | ... | ... |
6. 採用案
質問: 選んだアプローチと選択理由は?
- 採用するアプローチを明示する
- 代替案と比較した場合の優位点を述べる
- トレードオフを認識した上で選択した旨を記述する
7. リスク
質問: 実装・運用上のリスクは?(影響度・対策付き)
| リスク | 影響度 | 発生確率 | 対策 |
|---|
| リスク 1 | High / Medium / Low | High / Medium / Low | ... |
| リスク 2 | ... | ... | ... |
8. テスト方針
質問: どう検証するか?
| レイヤー | テスト種別 | カバー範囲 |
|---|
| Unit | Unit | ... |
| Integration | Integration | ... |
| E2E | E2E | ... |
手順
/pg-think は存在しない(TASK-0124 / 2645848, 2026-06-02 の plugin 初回同期適用で
plugin/plangate/commands/pg-think.md が削除され、後継コマンドは無い)。
手順 1 はコマンドに依存しない論点整理として実施する(下記)。旧コマンドを前提とした
自動化を組んでいる場合は、以下に置き換えること。
- 論点整理を行い、次の 5 項目を書き出す(コマンド不要。
brainstorming Skill を使ってもよい)
- Problem Restatement: 解くべき問題を自分の言葉で言い直す
- Assumptions: 前提として置いていること(未検証のものは「未検証」と明記)
- Options: 検討した代替案(採用しなかった案も残す)
- Recommended Approach: 採用案とその理由
- Risks: 採用案が外れたときに何が壊れるか
- 上記 5 項目の出力を元に 8 項目を補完する
- Problem Restatement → 問題定義・目的
- Assumptions → 非目的(スコープ外の前提)
- Options → 代替案
- Recommended Approach → 採用案
- Risks → リスク
- 設計書を
docs/working/TASK-XXXX/design.md に保存する(docs/working/templates/design.md を参照)
- high-risk の場合: チームへレビュー依頼(推奨)
- critical の場合: 人間の明示的承認を待つ(必須)。承認前に実装を開始しない
Mode 別の扱い
| Mode | Design Gate | 承認要件 |
|---|
ultra-light | スキップ可 | 不要 |
light | スキップ可 | 不要 |
standard | スキップ可 | 不要 |
high-risk | 必須 | 推奨(承認記録を design.md に残す) |
critical | 必須 | 必須(承認なしに実装開始不可) |
出力フォーマット
設計書は docs/working/TASK-XXXX/design.md に保存する。
テンプレート docs/working/templates/design.md の形式に従い、8 項目を Markdown で記述する。
## メタ情報
task: TASK-XXXX
related_issue: <issue URL>
author: <担当者>
updated: YYYY-MM-DD
approved_by: <承認者>(high-risk 以上で記入)
approved_at: YYYY-MM-DD(high-risk 以上で記入)
## 1. 問題定義
<記述>
## 2. 目的
<記述>
## 3. 非目的
<記述>
## 4. 仕様
<記述>
## 5. 代替案
<代替案テーブル>
## 6. 採用案
<記述>
## 7. リスク
<リスクテーブル>
## 8. テスト方針
<テストテーブル>
関連
- 適用条件・ブロック条件の正本は本 Skill 自身(§Iron Law / §Mode 別の扱い)
- Rule:
.claude/rules/mode-classification.md(ultra-light〜critical の 5 段階 Mode 判定の正本)
旧 plugin/plangate/rules/design-gate.md は削除済み(TASK-0124 / 2645848,
2026-06-02 の plugin 初回同期適用)。適用条件・ブロック条件は本 Skill が自己保持する。
同 commit で削除された plugin/plangate/commands/pg-think.md も後継コマンドは無く、
論点整理の手順は本 Skill §手順 1 が引き継いだ。/pg-think を新たに参照に加えないこと。
- Skill:
brainstorming(論点整理の初段。任意)
- Template:
docs/working/templates/design.md(design.md の保存形式)
- Skill:
plugin/plangate/skills/skill-policy-router/SKILL.md(GatePolicy との連携)
参照解決順(導入先で必ずこの順に探す): 本 Skill が参照する docs/** は上流リポジトリ基準の相対パスであり、install.sh --claude / plugin(Claude marketplace)/ Codex の 3 経路とも配布対象外(解決不可)。(1) 導入先リポジトリの同名パスを探す → (2) 見つからなければ 「正本 <path> を参照できなかった」と明示し、本 Skill 内の記述を代替正本として扱い、推測で内容を補わない。plugin root 配下の探索は docs/** には適用しない: plugin が配布するのは agents / commands / skills / rules 等の定義ディレクトリのみで docs/ を配布対象として認識せず、plugin root 配下に相当する配布物が存在しないため、plugin root 段を置いても必ず空振りする(クラス A の rules 参照が plugin root 配下で解決できるのは rules/ が実際に配布されるからであり、この非対称を docs/** に持ち込まない)。