breakdown-gate

name	breakdown-gate
description	PlanGate 起動前の intake 判定（mode-classification にかける前の分割要否）。実装着手前にタスク粒度を5要素で判定し、必要なら分割候補を提示する。Use when: PlanGate を起動すべきか迷う軽量タスクの判定時、PBI 化の前に分割要否を確かめたい時、「タスクを分割して」「粒度が大きすぎる」「1 PRに複数目的が入っている」。出典: growth-core task-breakdown-gate 由来（#799）。

Breakdown Gate

Provenance（出典・vendoring 規約）: growth-core task-breakdown-gate （upstream: Growth-Teams-Agent@5219642 / 2026-07-03 時点）を PlanGate 向けに 汎用化して取り込み（#799）。上流への自動追従はしない — 上流更新の反映は 意図的に diff をレビューして行う（provenance 追跡 + 意図的更新の vendoring 標準）。

実装着手前にタスクの粒度を判定し、粗すぎる場合は分割候補を提示する intake ゲート。growth-core task-breakdown-gate から蒸留。

参照解決順（導入先で必ずこの順に探す）

本スキルは規模判定の正本として .claude/rules/mode-classification.md を参照する （本文中 3 箇所）。このパスは上流リポジトリ基準のため、導入先では 次の順で探索する:

1. 導入先リポジトリの .claude/rules/mode-classification.md。 ただし 本 skill が参照する節（例: mode-classification.md の「判定基準」節）が実在することを確認する。同名でも別内容なら PlanGate の正本ではないため 2 へ進む
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 を参照できなかった」と明示する。 本スキルは mode を決めないため判定自体は続行できる — 出力フォーマットの常設行 **Mode 判定の正本**: 参照可 / 未参照（理由） に「未参照（<探した path> が どちらにも無い）」と記録し、5 段階 mode の内容を推測で補わない。 この行は分割要否に関わらず必ず出力する（「分割候補」は分割必要時のみ出る節のため、 記録先にしない）

参照	install.sh --claude 経由	plugin（Claude marketplace）経由	Codex 経由
rules/*.md	.claude/rules/ に着地（解決可）	<plugin_root>/rules/ で解決	未配置（解決不可 → 手順 3 へ）

install.sh --claude のコピー対象は agents / skills / commands / rules の 4 ディレクトリ のみ。Codex 経由（install_codex()）は install-plangate-skills.sh を呼ぶだけで skills しか 配置されないため、rules 参照は解決順 1・2 とも成立せず必ず手順 3 に落ちる。

Iron Law

ONE TASK = ONE PURPOSE, ONE PR-SIZED DIFF, ONE VERIFIABLE OUTCOME

目的・差分・検証結果のどれか 1 つでも複数に見えたら分割を検討する。

役割分界（オーガナイザー設計 / issue #799）

段階	担当	本スキルとの関係
起動前 intake	breakdown-gate（本スキル）	5 要素 + 粒度判定 → 分割候補提示
起動後の規模判定	.claude/rules/mode-classification.md（正本・不変。解決順は上記「参照解決順」）	本スキルは mode を決めない（判定基準は参照のみ）
plan 生成後の粒度検査	C-1 ToDo チェック「タスク粒度」（不変）	本スキルは plan 生成前
規模 L 以上の MVP scoping	codex-mvp-split（既存・.agents/skills/codex-mvp-split/）	本スキルは分割要否の判定まで。規模 L 以上と判明したら codex-mvp-split で最小 MVP（Phase 1）分割へ
plan 生成後の品質スコア	plan-quality-check（既存・.claude/skills/ 専用）	5 要素は同系だがタイミングが異なる（本スキル=plan 前 / plan-quality-check=plan 後）。チェックリストの正本は各自 — 変更時は相互参照

本スキルは PlanGate の Mode 判定・C-1 レビューを代替しない。あくまで「PlanGate を起動する前に、そもそも 1 タスクとして扱ってよい粒度か」を判定する前段ゲート。

Common Rationalizations

こう思ったら	現実
「まとめて実装した方が速い」	大きいタスクほど迷走する
「DB 変更と API 変更は一緒じゃないと意味がない」	migration+API+test 同梱は最多の失敗パターン
「テストは後で」	後でとは永遠のこと
「Rollback は考えなくていい」	書けないなら設計が固まっていない証拠

手順

Phase 1: タスク一覧の確認

判定対象のタスク一覧を取得する。docs/working/TASK-XXXX/todo.md が既に存在する場合はそれを読み、記載されたタスクを入力とする。存在しない場合はユーザーの依頼文から判定対象タスクを列挙する。

Phase 2: 5 要素チェック

各タスクについて以下 5 要素を判定する。いずれかが「書けない」または「複数になる」場合は分割候補へ回す。

• □ 目的（1 文・複数動詞なし）
• □ 変更対象（file / module / API / DB を限定可）
• □ 完了条件（観測可能・検証可能）
• □ 検証方法（unit / integration / manual / lint+typecheck+build）
• □ Rollback（1 手順で書ける）

Phase 3: 粒度サイズ判定

目安	判定
30 分〜2 時間	理想
半日〜1 日	許容
2 日以上	分割必須
DB + API + UI + テスト同梱	分割必須
目的が複数（「〜して、さらに〜」）	分割必須

Phase 4: 分割候補の提示

分割が必要と判定したタスクについて、各分割候補が Iron Law（1 目的・1 PR 規模・1 検証）を満たす形で列挙し、依存順を明示する。分割後の各タスクは個別に PlanGate（.claude/rules/mode-classification.md → fallback <plugin_root>/rules/mode-classification.md。上記「参照解決順」）の Mode 判定にかける導線を示す。

出力フォーマット

タスクごとに以下を出力する:

### タスク: <タスク名>

| 要素 | 判定 |
|---|---|
| 目的 | OK / NG（理由） |
| 変更対象 | OK / NG（理由） |
| 完了条件 | OK / NG（理由） |
| 検証方法 | OK / NG（理由） |
| Rollback | OK / NG（理由） |

**粒度判定**: 理想 / 許容 / 分割必須

**分割要否**: 不要 / 必要

**Mode 判定の正本**: 参照可 / 未参照（理由）

**分割候補**（分割必要の場合）:
1. <候補1>（依存: なし）
2. <候補2>（依存: 候補1完了後）
...

関連

• .claude/rules/mode-classification.md → fallback <plugin_root>/rules/mode-classification.md — 規模判定の正本。本スキルは mode を決めない。どちらでも解決できない場合（Codex 経由等）は 上記「参照解決順」手順 3 に従い、出力の常設行 **Mode 判定の正本** に正本未参照である 旨を記録する
• codex-mvp-split（.agents/skills/codex-mvp-split/） — 規模 L 以上の最小 MVP（Phase 1）選定。本スキルの分割要否判定の後段
• plan-quality-check（.claude/skills/plan-quality-check/） — plan 生成後の品質スコアリング（本スキルは plan 生成前。変更時は相互参照）
• subagent-driven-development — 分割後の各タスクをサブエージェントへ委譲する際に使用
• brainstorming — 要件そのものが曖昧な場合はこちらを先に使う（本スキルは要件確定後の粒度判定）