design-gate
Skill3 starsChanged 13 days agoMITView on GitHub
Design Gate を実施し、設計書(Design Artifact)を生成・評価する。Use when: high-risk 以上のタスクで実装前に設計を整理したい時。「設計書を作りたい」「Design Gate を通したい」「実装前に設計レビューをしたい」。
2 other projects use a version of this.
Adopted by
Most recently taken up by
- gaia-research/gaia-skill-treetheir own version, first seen Nov 7, 2026
- hamidettefagh/two-gatestheir own version, first seen Oct 28, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- gaia-research/gaia-skill-tree★ 22same name
- hamidettefagh/two-gates★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository75 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/plangate.mdcCursor rule
- acceptance-criteria-buildSkill
- acceptance-reviewSkill
- ai-dev-brainstormSkill
- ai-dev-execSkill
- ai-dev-planSkill
- ai-dev-verifySkill
- ai-loop-cycleSkill
- architecture-sketchSkill
- brainstormingSkill
- breakdown-gateSkill
- codex-multi-agentSkill
- codex-mvp-splitSkill
- context-loadSkill
- context-packagerSkill
- diff-auditSkill
- edgecase-enumerationSkill
- evidence-ledgerSkill
- feature-implementSkill
- ho-apply-scriptSkill
- instruction-debt-auditSkill
- intent-classifierSkill
- known-issues-logSkill
- local-exec-handoffSkill
- manual-cloud-taskSkill
- nonfunctional-checkSkill
- plangate-setupSkill
- plan-normalizationSkill
- plan-review-gateSkill
- pr-decisionSkill
- ref-integrity-scanSkill
- requirement-gap-scanSkill
- review-gateSkill
- risk-assessmentSkill
- skill-creatorSkill
- skill-policy-routerSkill
- subagent-delegation-briefSkill
- subagent-dispatchSkill
- subagent-driven-developmentSkill
- subagent-team-designSkill
- systematic-debuggingSkill
- working-contextSkill
- acceptance-criteria-buildSkill
- acceptance-reviewSkill
- ai-loop-cycleSkill
- architecture-sketchSkill
- brainstormingSkill
- breakdown-gateSkill
- codex-multi-agentSkill
- context-loadSkill
- diff-auditSkill
- edgecase-enumerationSkill
- feature-implementSkill
- ho-apply-scriptSkill
- hypothesis-loggerSkill
- instruction-debt-auditSkill
- intent-classifierSkill
- known-issues-logSkill
- The first 60 shown.
The file
Files
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 項目を書き出す(コマンド不要。
brainstormingSkill を使ってもよい)- 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/**に持ち込まない)。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

