task-plan-v2-orchestrator

タスク計画 V2 オーケストレーター

このスキルは計画やオーケストレーションの成果物に使用し、機能の実装自体には使用しないでください。

標準モデル

• FEATURE-PREPARATION.md は実装前のゲートです。
• TASK-PLAN.md は標準となる編集可能な管理ドキュメントです。
• TASK-DASHBOARD.html は Markdown から生成されるものであり、信頼できる唯一の情報源にはなりません。

ユーザーがファイルを1つだけ求めている場合は、そのファイル内で同じ論理的な分離を維持してください。

ワークフロー

1. リクエストを分類します。
   • 新しい計画の作成
   • 既存の計画のリファクタリング
   • 計画の監査
   • ランタイム固有の投影の準備
2. references/field-layers.md を読みます。
3. ユーザーが Codex、Claude Code、Gemini、または Antigravity に言及した場合は、references/runtime-adapters.md も読みます。
4. ユーザーが HTML、ダッシュボード、グラフ、カンバン、またはオブザーバビリティのビューを求めている場合は、references/dashboard-contract.md も読みます。
5. 実装前のレイヤーから始めます。不完全な場合は、実装タスクを準備完了としてマークしないでください。
6. 自由記述の文章ではなく、明示的なフィールドを含む安定したタスクブロックに、すべてのタスクを正規化します。
7. 明示的に並列レーンを求められない限り、マルチエージェント実行はデフォルトで逐次処理としてモデル化します。
8. タスク実行の前に Execution Governance と Verification Policy を追加します。
9. 不明な事実は捏造せず、TBD、unknown、または open_question と明示します。
10. 重要な TBD フィールドは、ready、in_progress、approved、done のブロッカーとして扱います。
11. デフォルトで NO-MOCKS と NO-PLACEHOLDERS を適用します。
12. モックまたはプレースホルダーを一時的に避けられない場合は、置き換え要件を含む明示的なアラームに変換し、そのアラームを後続のすべてのプロンプトまたはランタイム投影に引き継ぎます。

マルチエージェントのルール

• タスクに複数のエージェントを割り当てることはできますが、現在の owner_role は1つだけです。
• ユーザーが明示的に並列レーンを求めない限り、agent_sequence は順序付けられた逐次処理とします。
• agent_contracts では、以下を定義する必要があります。
  • 開始条件
  • 期待される出力
  • 引き継ぎ先
  • 停止条件
• required_approvals には、曖昧な「レビュー」ではなく、役割またはゲートを指定する必要があります。
• max_review_loops は有限でなければなりません。
• escalation_rule には、レビューの繰り返しが上限に達した場合、またはブロッカーをローカルで解決できない場合の対応を記載する必要があります。

ガバナンスルール

• NO-FICTION：ファイル、コミット、チェック、承認、ブロッカー、成果物のパスを捏造してはなりません。
• NO-MOCKS：モック、偽の連携、スタブ化された結果、偽の証拠、または実在するように見せかけたバックエンドを、暗黙のデフォルトとして計画または受け入れてはなりません。
• NO-PLACEHOLDERS：明示的な未解決アラームとして扱う場合を除き、実行準備済みの作業にプレースホルダーを残してはなりません。
• INVALID_INPUT：必要な入力が不足している場合は、不足しているフィールドを返し、実行してはなりません。
• prompt-first：タスクを in_progress にする前に、そのタスク専用のプロンプトを1つ用意する必要があります。
• code-first：実装タスクをドキュメントのみの進捗で完了にしてはなりません。
• strict DONE：done にするには、依存関係、承認、実行済みの検証、証拠、ロールバック、同期が必要です。
• verification-first：テストは planner が計画し、reviewer がレビューし、tester が実行します。
• commands_planned は commands_run と同じではありません。
• プレースホルダーの証拠、プレースホルダーのテスト、プレースホルダーの成果物パスは無効です。
• 未解決のモックやプレースホルダーは、黙示的なメモではなく alarms にしなければなりません。
• 未解決の各アラームには、以下を記載する必要があります。
  • 何がモックまたはプレースホルダーなのか
  • なぜそれが存在するのか
  • 置き換えに必要な、欠けている事実、システム、認証情報、成果物、または依存関係の具体的な内容
  • 置き換え先と、提案する置き換えパス
  • ready、in_progress、approved、done のどれをブロックするのか
• 未解決の各アラームは、以下にコピーする必要があります。
  • タスクブロック
  • タスクプロンプト
  • ランタイム投影
  • 引き継ぎの概要

読むもの

• 常にreferences/field-layers.mdを読んでください。
• ランタイム固有の出力が必要な場合は、references/runtime-adapters.mdを読んでください。
• ユーザーが.htmlまたはビジュアルボードを希望する場合は、references/dashboard-contract.mdを読んでください。
• 以下からコピーしてください。
  • assets/FEATURE-PREPARATION-CHECKLIST.md
  • assets/TASK-PLAN-v2.template.md
  • Claude 形式の簡潔なタスクビューが必要な場合は、assets/CLAUDE-CODE.tasks-projection.md
  • Gemini または Antigravity にプロジェクションが必要な場合は、assets/IMPLEMENTATION-PLAN.runtime.md

出力ルール

• Markdown を信頼できる唯一の情報源として維持してください。
• 決定論的な解析ができるよう、タスクブロックを安定した形式にしてください。
• ナビゲーションやダッシュボード生成に役立つ場合に限り、上部に簡潔な一覧を置いてください。
• エージェントレベルのデータを一文にまとめず、引き継ぎを明示してください。
• 別のランタイム向けに調整する場合は、フィールドの意味を変えず、レイアウトまたは見出しのみを調整してください。
• 計画に未解決のモックやプレースホルダーが残っている場合は、説明文に埋もれさせず、トップレベルの警告およびタスクごとの警告として提示してください。
• 重大な未解決のモック／プレースホルダーに関する警告が有効な間は、タスクをready、in_progress、approved、またはdoneにしないでください。

ランタイム向けプロジェクション

• Codex：正規の Markdown を直接編集します。
• Claude Code：正規の Markdown を維持し、有用な場合に限り、簡潔なタスク用プロジェクションを出力します。
• Gemini および Antigravity：正規の Markdown を維持し、implementation_plan.md は置き換えではなくプロジェクションとしてのみ出力します。

完了基準

優れた TASK-PLAN v2 には、以下が含まれています。

1. 明示的な機能準備ゲート
2. 正規化されたタスクブロック
3. 順次実行されるエージェント契約
4. Execution Governance セクション
5. コーディング前に計画された Verification Strategy
6. テスト、レビュー、成果物、ロールバックの各フィールド
7. Wiki の読み取りおよび書き込みルール
8. ダッシュボード対応の構成
9. 一時的なモックやプレースホルダーに関する未解決警告の明示的な追跡