fusion-issue-task-planning

ユーザーストーリーのタスク計画

実験的な注意事項

このスキルは実験段階にあり、まだ安定していません。動作、構成、出力はバージョン間で変更されることがあります。

使用する場合

実装前に、ユーザーストーリーのイシューについて実行可能なタスク計画が必要な場合に、このスキルを使用してください。

一般的な使用例：

• 「#123 のタスクを計画する」
• 「このストーリーを手順に分解する」
• 「このユーザーストーリーからタスクイシューのドラフトを作成する」

使用しない場合

明示的な確認なしに、このスキルを直接のコード実装、PR レビュー、GitHub の変更に使用しないでください。

必要な入力

• 対象イシューの参照（owner/repo#number または URL）
• 希望する計画の詳細度（minimal、standard、detailed）
• 実行モード（draft-only、draft+publish-ready、publish-now）

不足している入力によって計画を進められない場合は、assets/follow-up-questions.md から、焦点を絞った質問を最大 3 つ行ってください。

デフォルト

• 計画の詳細度：standard
• 実行モード：draft-only
• 公開動作：変更を加える前に、同じターン内で明示的な確認が必要です

ツール形式

• ツール名は <mcp_server>::<tool> の形式です（例：mcp_github::sub_issue_write）。

手順

順番に実行し、前提を明示してください。

1. 利用可能なスキルを確認し、ドラフト作成モードを分類する

   • orchestrated：fusion-issue-authoring と fusion-issue-author-task の両方が利用可能。オーケストレーターが明示的な公開ゲートを処理する、全ワークフローを実行します。
   • direct-subordinate：fusion-issue-author-task のみ利用可能。テンプレートと安全策を使用して ドラフトのみ のモードで作業し、GitHub に変更を加えないでください。ドラフトと、オーケストレーターまたはユーザーが公開する方法を明確に示す手順を提示してください。
   • inline：どちらも利用できない場合は、ドラフトのみ のモードを維持し、最小限の組み込み構成（Title、Problem、Scope、Acceptance criteria mapping、Verification、Dependencies）でタスクのドラフトを生成してください。他のスキルの assets/ ファイルを直接参照しないでください。
   • fusion-issue-author-task が利用可能な場合は、常に優先してください。他のスキルのファイルを直接参照して代替しないでください。
   • 優先スキルがないことを理由に停止しないでください。適切に代替手段へ切り替えてください。

2. ユーザーストーリーを調査する

   • タイトル、本文、受け入れ条件、シナリオ、祖先の階層、既存のサブイシュー、関連リンクを収集します。
   • イシューの種類が曖昧な場合は、「ユーザーストーリー」として進めてよいか確認してください。

3. 必要な場合にのみ確認する

   • 1 回につき最大 3 つの質問を行ってください。
   • 安全なデフォルトがある場合は、前提を明示して続行してください。

4. 計画の軸を抽出する

   • 成果
   • 制約と対象外の事項
   • 検証ポイント

5. 依存関係の順にタスクを作成する

   • 各タスクには、目的、スコープの境界、成果物、検証方法、対応する受け入れ条件の参照を含めてください。
   • それぞれ独立して検証できる単位を優先してください。

6. 下書き作成前にデビルズアドボケイトレビューを実施する

   • 提案されたタスクセットを確認し、アーキテクチャの曖昧さを示す兆候を探します。
     • ストーリー、コメント、または親イシューで言及されている、未解決の設計またはアーキテクチャ上の決定事項
     • まだ合意されていない暗黙の API、データモデル、または所有権の契約を共有するバックエンドとフロントエンドのタスク
     • 明示的なブロッキング関係がないまま、具体的な実装タスクと並行して存在する、調査、リサーチ、または調整タスク
     • 曖昧または循環的な依存関係の記述（「バックエンドの完了後」「デザインの準備ができたら」など）
     • コンポーネント、API、またはデータモデルの所有権が不明確、または合意されていない
   • 該当する兆候が2つ以上ある場合：
     • orchestrated モード：fusion-issue-authoring → agents/devils-advocate.agent.md の interrogator mode に自動的に回します。ユーザーによるトリガーは不要です。
     • direct-subordinate または inline モード：上記の5つの兆候を使ってインラインの DA チェックリストを実施します。構造化された ⚠ Ambiguity checklist として確認結果を提示し、下書き生成前に各項目についてユーザーによる解決または明示的な受け入れを求めます。
   • 該当する兆候が0または1つの場合は、moderate mode で進めます。懸念事項を最大3件提示し、ユーザーの確認後に続行します。
   • 公開ゲート（全モード）：デビルズアドボケイトがタスク分割に問題がないと確認するか、ユーザーが提示されたリスクを明示的に受け入れるまで、タスクを公開しないでください。
   • 下書きのみの例外：draft-only モードでは、曖昧さが未解決でも下書き生成を進めてかまいません。ただし、プランプレビューの冒頭に、未解決の項目を列挙した ⚠ Ambiguity warning ブロックを出力します。リスクが受け入れられるまで、公開は引き続きブロックされます。

7. タスクイシューの下書きを生成する

   • orchestrated：イシュー種別を Task として fusion-issue-authoring に回します。
   • direct-subordinate：fusion-issue-author-task を draft-only モードで呼び出し、最終的な変更処理を fusion-issue-authoring に委任する明示的な公開手順を出力します。
   • inline：ステップ1の最小限の組み込み構成を使って、.tmp/TASK-<nn>-<slug>.md の下書きを作成します。
   • 明示的な公開承認があるまで、下書きはローカルに保持します。

8. プランプレビューを生成する

   • assets/task-plan-template.md から .tmp/USER-STORY-TASK-PLAN-<context>.md を作成します。
   • 概要、トレーサビリティ、順序付けしたタスク、下書きのパス、公開計画、前提条件、リスクを含めます。

9. 明示的な確認後にのみ公開する

   • 同じターン内で明示的な確認を求めます。
   • 未解決の前提条件が残っている場合は停止します。
   • 公開処理は fusion-issue-authoring に委任し、タスクイシューの作成、更新、リンクにはサブエージェントの呼び出しを優先します。
   • 必要なコンテキストを fusion-issue-authoring に渡します：owner、repo、親ストーリーの参照、順序付けしたタスクの下書き、ラベル／担当者の意図、依存関係の順序。
   • fusion-issue-authoring が MCP 優先の動作を維持し、MCP の書き込み機能が利用できない場合に限って GraphQL フォールバックを適用するよう求めます。
   • オーケストレーターのセッションキャッシュ規則は、委任するすべての呼び出しに適用されます。ラベル、担当者候補、イシュー種別はセッションごとに1回取得し、バッチ内のすべてのタスクイシューで再利用します。
   • 予算への配慮：タスクプランの公開では、N件のタスクに対して約N回のイシュー書き込みと、任意のサブイシューリンク書き込みが必要です。N > 5 の場合は、レート制限のリスクをユーザーに警告し、バッチでの公開を提案します。
   • 公開モードでは、このスキルから MCP の書き込みツールを直接呼び出さないでください。
   • 委任された実行でイシュー単位の未解決の失敗が返された場合は、公開モードを必ず失敗させます。

10. 作成済みタスクの修復モード

• タスクは作成済みでも、Issue Type または親との関連付けが欠けている場合は、fusion-issue-authoring に修復を委任し、サブエージェントの呼び出しを優先します。
• イシューごとの修復内容（type=Task に設定、不足している親リンクの追加、順序の維持）を指定し、委任先の実行結果による検証を必須とします。
• 修復モードはべき等にします。すでに正しいイシューはスキップし、不足しているメタデータのみを修正します。
• 修復後に事後検証を実行し、対処可能な失敗を返します。

よくある失敗と解決方法

• 実行環境で fusion-issue-authoring を利用できない
  • 下書きのみのモードを維持し、公開可能な成果物と明確な引き継ぎ手順を返します。
• 委任した公開処理で一部失敗が発生する
  • イシューごとに正確な理由を添えて failed ステータスを返し、ユーザーの確認を得るまで以降の変更を停止します。
• タスクのイシューは作成されたが、親ストーリーにリンクされていない
  • fusion-issue-authoring を通じて修復を委任し、事後検証の出力を必須とします。
• タスクは存在するが、Issue Type が欠けているか正しくない
  • type=Task に設定する意図を伝えて fusion-issue-authoring に修復を委任し、結果を検証します。
• 事後検証で一部失敗が報告される
  • イシューごとに正確な理由を添えて failed ステータスを返し、公開フローを停止して、未解決の項目をユーザーが明示的に判断できるようにします。

想定される出力

次の見出し順で返します。

1. 試験的な機能に関する注意
2. ストーリーの概要
3. 受け入れ基準のトレーサビリティ
4. 順序付きタスク
5. 下書きファイルのパス
6. 公開計画
7. 前提条件、リスク、未解決の質問

公開が確認され完了するまで、必ず Status: Awaiting user approval を含めます。

publish-now モードまたは repair モードでは、次の項目を含むイシューごとの事後検証レポートを含めます。

• イシューが存在するか
• イシューの種類が指定された種類と一致するか
• 親が想定されるストーリー番号と一致するか
• ステータス（ok、fixed、または failed）

アセット

• assets/follow-up-questions.md
• assets/task-plan-template.md

安全性と制約

• このスキルは変更を実行できます。指針が競合する場合は、インラインのガイダンスよりリポジトリ内のワークフロー指示を優先します。
• 明示的な確認なしに GitHub の状態を変更しないでください。
• 受け入れ基準を推測する場合は、必ずその旨を明示してください。
• タスク計画では、常に受け入れ基準のトレーサビリティを維持してください。
• 公開処理を行う前に、下書きは .tmp/ に保存してください。
• 公開／修復モードでは、事後チェックに合格するまで、Issue Type または親との関連付けの欠如を失敗として扱います。
• 変更の実行と修復は fusion-issue-authoring に委任し（サブエージェントを優先）、このスキルから MCP の書き込みツールを直接呼び出さないでください。