task-breakdown

name	task-breakdown
description	This skill should be used when the user asks to "task-breakdown", "タスク分割", "タスク分解", "タスクを分割", "タスクを分解", "WBSを作成", "作業分解", "break down task", "decompose task", "create WBS". 依頼をゴール/制約/前提に正規化し、トップダウンで構造分解（1階層1軸）、粒度の停止条件を適用し、MECE・依存関係・DoD を検証して、ツリー＋表のタスク分割結果を生成する。分野を問わない汎用スキルで、単独利用と他スキル/コマンドからの呼び出しの両方に対応。
argument-hint	"<分割したい依頼>" | <要件ファイルパス>

Task Breakdown（タスク分割）

依頼を過不足なく実行可能なタスクへ分解するための汎用スキル。分野（開発・企画・運用など）を問わず使える。「ゴール正規化 → 構造分解 → 粒度停止 → 分割検証」の4フェーズで進める。

実行モード

呼び出され方でモードが決まる。引数や文脈からモードが自明な場合は確認不要。

モード	起動条件	出力
standalone	ユーザーが直接このスキルを呼ぶ	分割結果を提示し、AskUserQuestion で保存先を確認してファイル保存
embedded	他スキル/コマンドの中から分解目的で呼ばれる	ファイル保存せず、分割結果を呼び出し元に返却する

embedded モードでは Phase の対話（AskUserQuestion）を最小化し、呼び出し元から渡された文脈で不明点を補う。渡された情報で埋まらない重大な不明点だけを呼び出し元にエスカレーションする。

ワークフロー

Phase 1: ゴールへの正規化

依頼を「なにがどうなったら終わりか」で確定させる。

1. 完了状態を先に確定する。5W1H（誰が・なにを・いつ・どこで・なぜ・どうやって）と受け入れ条件で、ゴール（終了状態）を言語化する。
2. 細かい依頼は制約として分離する。「〇〇形式で」「△△を使って」等の指定は目的そのものではないので、目的（ゴール）と混ぜず制約に回す。細かい依頼ほど、背景・目的を明示的に補って本来のゴールを推定する。
3. ゴール / 制約 / 前提 の3段に仕分ける。
   • ゴール: 達成したい終了状態（受け入れ条件付き）
   • 制約: 守るべき条件（期限・技術・形式・運用ルールなど）
   • 前提: 成り立っていると仮定する外部条件・既存資産
4. 不明点はユーザーに確認する。ゴール・受け入れ条件・スコープ境界に関わる不明点は、AskUserQuestion で解消してから次へ進む（embedded モードでは呼び出し元の文脈を優先し、埋まらない点のみ確認）。確信度 🔴 の項目は必ず確認対象にする。

出力は references/output-template.md の「1. ゴール定義」に従う。

Phase 2: トップダウンで構造分解

ゴールを起点に、親→子へと分解する。

1. 1階層＝1軸で分割する。同じ階層で複数の軸を混在させない。
2. その階層に合った分割軸を選ぶ。代表的な軸:
   • 成果物ベース: 最終的に作られる物・ドキュメント・機能単位で割る
   • フェーズ・時系列: 調査→設計→実装→検証 のような時間順で割る
   • 機能・コンポーネント: サブシステム・担当領域で割る
   • その他、ゴールの構造に最も素直に沿う軸を選ぶ
3. 子タスクの総和 = 親タスクになるようにする。子を全部足すと親が過不足なく満たされる状態（この時点で MECE を意識する）。
4. ゴールの構造に沿って、必要な深さまで階層を掘り下げる。停止判断は Phase 3 で行う。

出力は references/output-template.md の「2. 分割ツリー」に従い、各階層の軸を明示する。

Phase 3: 粒度の停止条件

各枝について、以下を すべて 満たしたら「十分細かい」とみなし、それ以上分割しない（＝葉タスク）。

• 見積もり可能: 所要工数・規模が見積もれる
• 単独で実施可能: 他タスクの完了を待たずに（依存を解消すれば）着手・完了できる
• 検証可能: 完了したかを客観的に判定できる（DoD が書ける）
• サイズが揃っている: 兄弟タスク・他の葉タスクと粒度が大きくずれていない

1つでも満たさない枝は、Phase 2 に戻ってさらに分割する。逆に、細かすぎて他と粒度がずれる場合は統合する。

Phase 4: 分割結果そのものの検証

出来上がった分割を、成果物として検証する。

1. MECE チェック: 漏れ（親を満たすのに足りない子がない）と重複（同じ作業が複数の葉に跨っていない）を確認する。
2. 依存関係チェック: 葉タスク間の依存を洗い出し、循環がないこと・実行順序（トポロジカル順）が成立することを確認する。
3. DoD / 受け入れ条件チェック: すべての葉タスクに、検証可能な DoD があることを確認する。「正しく動く」等の曖昧表現は具体化する。
4. 粒度チェック: 葉タスクのサイズが揃っているかを再確認する。

問題があれば適切に対処する（不足の追加・重複の統合・依存の並べ替え・DoD の具体化）。対処後は再度チェックする。検証結果は references/output-template.md の「4. 検証結果」に記録する。

Phase 5: 出力

references/output-template.md の構造（1.ゴール定義 → 2.分割ツリー → 3.葉タスク詳細（表）→ 4.検証結果）で成果物を組み立てる。

• standalone モード: 結果を提示したうえで、AskUserQuestion で保存先を確認し、Markdown ファイルとして保存する（例の選択肢: docs/tasks/<name>/breakdown.md / カレントに保存 / 保存しない）。
• embedded モード: ファイルには保存せず、上記本文を呼び出し元に返す。呼び出し元が構造化データを求める場合は template の JSON 形状で返す。

呼び出し規約（他スキル/コマンドから利用する場合）

将来の連携を想定した最小規約。他スキルは以下を渡してこのスキルを起動できる:

• 入力: 分解対象の依頼（自然言語）＋ 既知のゴール/制約/前提（あれば）＋ 期待する葉タスクの粒度（あれば）。
• モード指定: embedded として起動されたことを明示する（ファイル保存を抑止し、結果を返却させるため）。
• 出力: references/output-template.md の本文（Markdown）、または同 template の JSON 形状。
• エスカレーション: ゴール・スコープに関わる 🔴 未確定事項が残る場合のみ、呼び出し元に確認事項として返す。

信号機システム

分割の各判断に確信度を付与する:

• 🔵 明示指示: ユーザーの依頼・渡された文脈に明示された内容に基づく
• 🟡 妥当な推測: 一般的なベストプラクティスに基づくが、明示的な根拠はない
• 🔴 要確認: ゴール・スコープ・受け入れ条件に関わる判断で、ユーザー確認が必要

葉タスクの表と未確定事項に確信度を記録する。🔴 がある場合は standalone では AskUserQuestion で確認し、embedded では呼び出し元にエスカレーションする。

ルール・制約

• ゴールが未確定のまま構造分解に進まない（Phase 1 を飛ばさない）。
• 1階層に複数の分割軸を混在させない。
• すべての葉タスクに検証可能な DoD を付ける。
• MECE・依存関係・DoD・粒度の4検証を通してから出力する。
• embedded モードではファイルを保存しない。standalone でも保存先は必ず AskUserQuestion で確認する（勝手に固定パスへ書かない）。
• 対話は必要最小限にし、確認は AskUserQuestion に集約する。

追加リソース

• references/output-template.md — ゴール定義・分割ツリー・葉タスク詳細（表）・検証結果の出力テンプレートと、embedded モードの返却形式（Markdown / JSON）。