design-gate

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 を参照する（§関連）。 このパスは上流リポジトリ基準のため、導入先では 次の順で探索する:

1. 導入先リポジトリの .claude/rules/mode-classification.md
2. 無ければ plugin root 配下 <plugin_root>/rules/mode-classification.md。 <plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した 絶対パス（Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/... という文字列をそのまま Read しない）。変数が空・未設定ならキャッシュを glob で推測せず 3 へ進む
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 はコマンドに依存しない論点整理として実施する（下記）。旧コマンドを前提とした 自動化を組んでいる場合は、以下に置き換えること。

1. 論点整理を行い、次の 5 項目を書き出す（コマンド不要。brainstorming Skill を使ってもよい）
   • Problem Restatement: 解くべき問題を自分の言葉で言い直す
   • Assumptions: 前提として置いていること（未検証のものは「未検証」と明記）
   • Options: 検討した代替案（採用しなかった案も残す）
   • Recommended Approach: 採用案とその理由
   • Risks: 採用案が外れたときに何が壊れるか
2. 上記 5 項目の出力を元に 8 項目を補完する
   • Problem Restatement → 問題定義・目的
   • Assumptions → 非目的（スコープ外の前提）
   • Options → 代替案
   • Recommended Approach → 採用案
   • Risks → リスク
3. 設計書を docs/working/TASK-XXXX/design.md に保存する（docs/working/templates/design.md を参照）
4. high-risk の場合: チームへレビュー依頼（推奨）
5. 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/** に持ち込まない）。