breakdown -- 収束的、アクション最優先の分解
/fanout の収束的な補完スキルです。/fanout は問題を広げます（多くの有効な答えがある問題に使用）。 /breakdown は問題を収束させます（1つの問題 -> 1つの次のステップ）。単一のステップで完結し、サブエージェントは不要、コストは約1倍です。 メンテナーのセッションログ分析に基づいており、最も大きな摩擦は「説明するな、実行しろ」でした。そのため、このスキルはアクション最優先で、散文は最小限に設計されています。出力が親切なチュートリアルのようになっているなら、それは間違いです。削ってください。
ステップ 1 -- 問題を把握する
問題を @メンション、パス、または貼り付けられたテキストから受け取ります。本当に曖昧な場合は、一度だけ1～2文で説明を求めます。分解する前に、参照されているファイルを末尾まで読み込みます。
問題がプロジェクトの成果物（またはその名前を含む）である場合、そのプロジェクトの CHECKPOINT.md も末尾まで最初に読み込みます（受信やプレビューは「読み込み」と見なしません）。「本当の目標」と「ブロッキング判断」はプロジェクトの現状（締切、順序ゲート、既に決定されたこと）に依存しており、プロジェクトの状態を無視した分解は間違った次のアクションを指し示します。本当にプロジェクトに関係のない場合にのみ読み込みをスキップします。
ステップ 2 -- 以下の5つのブロックを、簡潔に、順番通りに出力する
前置きは不要です。「私は〜にアクセスできます」なども不要です。質問を長々と繰り返さないでください。
- 本当の目標（1文）。「完了」の本当の意味。述べられた目標と実際の目標が異なる場合は、1行でその旨を述べます。
- 最小の次のアクション（1回の作業で完了できる具体的な物理的ステップ。例：「スキーマを設計する」ではなく「Xを開いて3つのフィールド名を書く」）。その後、すぐに実行を提案します。事前に長く説明しないでください。
- 唯一のブロッキング判断 -- 最も多くのことを解放する1つの分岐、または「なし -- ただ開始するだけ」。
- 全体計画（折りたたみ） -- 1行の要約の下に完全なチェックリストを置き、明示的に重要度を下げて記載します：「ステップ2が完了するまでは無視してください」。
- 最初の落とし穴 -- 最も起こりそうな失敗モードと、その最も初期の兆候。
ルール
- クリティカルパス上は1つのスレッド。並行する作業項目をリストしてはいけません。
- 平易な言葉を使い、作り出したコードは使わない（ファイリングタグは人にわかる言葉に翻訳すること）。
- ユーザーが選択するまで作業を開始しないでください。/breakdown は計画を立てるものであり、実行するものではありません。
- デフォルトでは何も永続化しません。保存する価値がある場合は、プロジェクトのCHECKPOINTの「次のステップ」行に書き込むことを提案してください。