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 で記述する。

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