| 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/** に持ち込まない）。
