ln-300-task-coordinator

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリを基準とした相対パスです。

タスクコーディネーター

タイプ： L2 ドメインコーディネーター カテゴリ： 3XX 計画

ランタイムを基盤とするタスク計画コーディネーターです。準備状況のゲート、停止／再開、ワーカーの結果追跡はランタイムが担います。

必読： references/coordinator_runtime_contract.md、references/task_planning_runtime_contract.md、references/coordinator_summary_contract.md、references/task_plan_worker_runtime_contract.md を読み込みます。 必読： references/environment_state_contract.md、references/storage_mode_detection.md、references/problem_solving.md、references/creation_quality_checklist.md を読み込みます。 必読： Phase 3 の外部検証がトリガーされた場合は、references/agent_delegation_pattern.md を読み込みます。 必読： Story で H/G/run ID が参照されている場合、または実装準備状況がプロジェクトの仮説に依存する場合は、references/researchgraph_mcp_usage.md を読み込みます。 ツールポリシー：ホストの AGENTS.md にある MCP の設定に従います。ホストポリシーがない場合、または MCP の動作が不明確な場合に限り、references/mcp_tool_preferences.md と references/mcp_integration_patterns.md を読み込みます。

目的

• Story のコンテキストを一度だけ解決します
• 既存のタスクを確認する前に、理想的な実装タスク計画を作成します
• 決定論的な準備状況ゲートを実行します
• CREATE、ADD、または REPLAN を検出します
• スタンドアロンのワーカーに委任します

入力

パラメーター	必須	説明
storyId	はい	計画対象の Story
autoApprove	いいえ	false の場合、ランタイムは準備状況の承認を求めて一時停止することがあります

ランタイム

ランタイムファミリー：task-planning-runtime

識別子：

• story-{storyId}

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_DECOMPOSE
4. PHASE_3_READINESS_GATE
5. PHASE_4_MODE_DETECTION
6. PHASE_5_DELEGATE
7. PHASE_6_VERIFY
8. PHASE_7_SELF_CHECK

終了フェーズ：

• DONE
• PAUSED

コーディネーターステージのアーティファクト：

• 検証後に summary_kind=pipeline-stage を書き込みます
• ln-1000 はこのアーティファクトを Stage 0 の完了シグナルとして使用します

フェーズマップ

Phase 1：ディスカバリー

Story を解決し、タスク計画に必要な入力のみを収集します。

• Story の AC
• 技術メモ
• コンテキスト
• プロジェクトのアーキテクチャと技術スタック
• タスクプロバイダー

この段階では既存のタスクを読み込まないでください。既存のタスクは Phase 4 でのみ読み込みます。

• サポート対象言語で既存コードを変更する Story では、グラフコンテキストを一度だけ構築します。
  • index_project(path=project_root)
  • analyze_architecture(path=project_root, verbosity="minimal")
  • Story の AC または技術メモに記載されたコンポーネント名について find_symbols と inspect_symbol を使用します。ただし、可能な場合は path を絞り込んでから実行してください。シンボルの検出結果が途中で切れている場合は、その結果を基に計画する前に name + file または workspace_qualified_name で絞り込みます。
• グラフコンテキストを使用して、分解の前に実際に影響を受けるモジュールとエントリーポイントを確認します。
• 仮説、目標、または実行証拠を参照する Story では、verify_index を実行してから、参照されている H##／G## ID または候補として提案された項目のみを調査します。
• 仮説の実装状況、精緻化の不足点、提案の準備状況を確認するには hex-research を使用します。コードシンボルとモジュールの境界については、hex-graph を情報源として使用します。

チェックポイントのペイロード：

• discovery_ready

フェーズ 2: 分解

AC のみから理想的なタスク計画を構築します。既存のタスクを読んだり参照したりしないでください。

操作の順序:

1. 次の列を持つ AC 対シナリオのトレーサビリティテーブルを構築します: AC | アクター | (1) トリガー | (2) エントリーポイント | (3) ディスカバリー | (4) 使用コンテキスト | (5) 成果
2. エントリーポイント、ディスカバリー、使用コンテキストのセルをスキャンして、構築可能な成果物を探します
3. セグメント境界を使用して、構築可能な成果物をアーキテクチャ層ごとにグループ化します:
   • 基盤: 処理を実行する内部ロジック、データモデル、またはサービス (エントリーポイントが呼び出す先)
   • 呼び出し: エントリーポイント自体 — アクターが使用する名前付きメカニズム
   • 知識: 使用コンテキスト — アクターがメカニズムを正しく呼び出すために必要なもの
   • 配線: ディスカバリー + 統合 — システムがメカニズムを見つけたり読み込んだり、コンポーネントを接続する方法
4. 各層グループは少なくとも 1 つのタスクになります。単一のタスクは、ごく小さい場合を除き、複数の層にまたがってはいけません (MUST NOT)。
5. グラフコンテキストが存在する場合は、それを利用して:
   • 推測されたファイルグループではなく、実際のモジュールやシンボルの所有権によってタスクを分割する
   • 依存関係の順序を、実際の呼び出し元、フレームワークのエントリーポイント、公開 API に合わせる
   • 影響を受けるコンポーネントを、グラフ分析によって返された実際のモジュール/シンボルで充実させる
6. 基盤優先の順序と 1〜8 タスクの数を検証します
7. トレーサビリティテーブルと層グループを .hex-skills/task-planning/{identifier}_traceability.md に保存します

ルール:

• 実装タスクのみ
• 1〜8 タスク
• ここではテストやリファクタリングのタスクは行いません
• 基盤優先の順序を維持する
• 意味のある検証意図を割り当てる
• インフラストラクチャのみのタスクは、そのインフラストラクチャを使用することを必要とする AC を満たしません
• 呼び出し層のタスクは、アクターがそのメカニズムを使用方法を知ることを必要とする AC を満たしません — それは知識層の成果物です
• creation_quality_checklist.md の #17b、#17c、#17d を参照してください

チェックポイントのペイロード:

• ideal_plan_summary
• traceability_table_path

フェーズ 3: 準備ゲート

委任する前に計画を採点します。

ステップ 1: 自己採点

採点ポリシー:

• 6-7 -> 続行
• 4-5 -> 承認または改善のために PAUSED
• <4 -> 計画が修正されるまでブロック

自己チェック: トレーサビリティテーブルに対応するセグメント内の構築可能な成果物が含まれている場合、各層 (基盤、呼び出し、知識、配線) に少なくとも 1 つのタスクがあることを検証します。

ステップ 2: 条件付きの外部トレーサビリティ検証

次のトリガーのうち少なくとも 1 つが真である場合にのみ、このステップを実行します:

• 準備スコアが 4-5
• モードがあいまいに見える (ADD 対 REPLAN)
• AC からタスクへのカバレッジが不完全
• 自己採点後もタスク境界または層の所有権が依然として競合している

トリガーされた場合:

1. エージェントのヘルスチェックを実行: node references/agents/agent_runner.mjs --health-check --json

2. アドバイザーエージェントが利用可能な場合: a. references/agents/prompt_templates/traceability_validator.md から検証プロンプトを構築します b. プレースホルダーをフェーズ 1 のディスカバリーとフェーズ 2 の出力で埋めます c. 埋めたプロンプトを .hex-skills/task-planning/{identifier}_traceability_prompt.md に保存します d. agent_runner.mjs 経由でエージェントを起動します:

   node references/agents/agent_runner.mjs \
     --agent {advisor_agent} \
     --prompt-file .hex-skills/task-planning/{identifier}_traceability_prompt.md \
     --output-file .hex-skills/task-planning/{identifier}_traceability_result.json \
     --cwd {project_dir}
   

   e. 結果の JSON を解析してギャップを探します f. MISSING ギャップごとに: readiness_score -= 1 g. BUNDLED ギャップごとに: readiness_score -= 0.5 h. MISSING ギャップが見つかった場合: フェーズ 2 に再突入します。再分解は最大 1 回。

3. エージェントが利用できない場合: ログに記録し、信頼度を低下させてローカルスコアを維持します。

トリガーされなかった場合:

• traceability_validation = self_check_only を設定します
• 外部検証なしで進みます

チェックポイントのペイロード:

• readiness_score
• readiness_findings
• traceability_validation — 次のいずれか: agent_validated、self_check_only、redecomposed

フェーズ 4：モードの検出

以下を検出します。

• CREATE
• ADD
• REPLAN

モードが曖昧な場合は一時停止します。

チェックポイントのペイロード：

• mode_detection

フェーズ 5：委任

単一の変更処理を引き継ぎます。次のワーカーのうち、必ず 1 つだけに委任します。

• ln-301-task-creator
• ln-302-task-replanner

管理された委任の手順：

1. childRunId = {parent_run_id}--{worker}--{storyId} を計算します。
2. childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/{worker}--{storyId}.json を計算します。
3. 子マニフェストを .hex-skills/task-planning/{worker}--{storyId}_manifest.json に生成します。
4. --run-id と --summary-artifact-path の両方を指定して task-plan-worker-runtime を起動します。
5. ワーカーを呼び出す前に、child_run のメタデータをチェックポイントに記録します。
6. 両方の受け渡し入力を指定して、Skill ツール経由でワーカーを呼び出します。
7. 最終的な task-plan アーティファクトのみを読み込み、ランタイムの record-plan を通じて記録します。

ワーカーに渡すコーディネーターのコンテキスト：

• idealPlan：フェーズ 2 の理想的な計画全体
• traceabilityTablePath：生成したトレーサビリティテーブルのパス
• discoveryContext：フェーズ 1 の調査結果
• ADD モードの場合：作成するタスクを指定します

フェーズ 6：検証

ワーカーの結果と、作成されたタスクセットのみを検証します。検証によってワーカーの出力が無効だと判明しない限り、分解をやり直してはいけません。

テンプレート準拠ゲート： 設定済みのトラッカープロバイダーを使用して、作成された各 Task を取得します（references/tracker_provider_contract.md に従い、getTask 操作を使用）。planning-runtime/lib/template-compliance.mjs の validateTemplateCompliance(description, 'task') を実行します。すべてのタスクが合格する必要があります（7 つのセクションが順番どおりであること）。状態に template_compliance_passed を記録します。これがないと、ガードによって SELF_CHECK がブロックされます。

チェックポイントのペイロード：

• verification_summary
• final_result
• template_compliance_passed

検証が成功したら、次の内容でステージ 0 のコーディネーターアーティファクトを作成します。

• stage=0
• story_id
• status=completed
• final_result
• story_status
• readiness_score
• warnings

フェーズ 7：セルフチェック

以下を確認します。

• フェーズが網羅されている
• 準備状況ゲートが遵守されている
• ワーカーの結果が記録されている
• 検証が完了している
• ステージ 0 のコーディネーターアーティファクトが記録されている

チェックポイントのペイロード：

• pass
• final_result

保留中の決定事項

以下の場合は、ランタイムの PAUSED + pending_decision を使用します。

• ADD と REPLAN のどちらかが曖昧な場合
• スコアが 4-5 の場合の準備承認
• 重要な Story コンテキストが不足している場合

ワーカーの契約

ワーカーは以下のとおりです。

• コーディネーターの存在を知らない
• ランタイムの状態を読み込まない
• スタンドアロンで動作する
• 管理された実行では runId と summaryArtifactPath の両方が必要
• 共有の task-plan サマリーエンベロープを返し、終了結果を返す前にアーティファクトを書き込む

想定されるサマリーの種類：

• task-plan

ワーカーの呼び出し（必須）

ホストスキルの呼び出し： Skill(skill: "...", args: "...") による委任が必須です。

• Claude：表示どおりに Skill ツールを呼び出します。
• Codex：Skill ツールがない場合は、利用可能なスキルから名前で該当スキルを探し、その SKILL.md を読み込み、args を $ARGUMENTS として扱い、そのスキルのワークフローを実行してから、結果／アーティファクトとともにここに戻ります。
• ワーカーのロジックをインラインで実行したり、対象スキルを実行せずにワーカーを完了扱いにしたりしてはいけません。

フェーズ	ワーカー	コンテキスト
5	ln-301-task-creator	CREATE または ADD の経路
5	ln-302-task-replanner	REPLAN の経路

node references/scripts/task-plan-worker-runtime/cli.mjs start --skill {worker} --story {storyId} --manifest-file .hex-skills/task-planning/{worker}--{storyId}_manifest.json --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}
node references/scripts/task-planning-runtime/cli.mjs checkpoint --story {storyId} --phase PHASE_5_DELEGATE --payload '{"child_run":{"worker":"{worker}","run_id":"{childRunId}","summary_artifact_path":"{childSummaryArtifactPath}"}}'
Skill(skill: "{worker}", args: "{storyId} --ideal-plan {idealPlanJSON} --traceability {tablePath} --discovery {discoveryJSON} --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}")
Read {childSummaryArtifactPath}
node references/scripts/task-planning-runtime/cli.mjs record-plan --story {storyId} --payload '{...task-plan summary...}'

TodoWrite の形式（必須）

- Phase 1: Discover Story context (pending)
- Phase 2: Build ideal task plan (pending)
- Phase 3: Run readiness gate (local score first, external validation only if triggered) (pending)
- Phase 4: Detect mode (pending)
- Phase 5: Start child runtime, checkpoint child metadata, and perform the single worker handoff (pending)
- Phase 6: Verify worker result (pending)
- Phase 7: Self-check (pending)

重要なルール

• 既存のタスクを確認する前に、理想的な計画を作成します。
• 委任の準備状況を判断する情報源は、準備状況ゲートのみです。
• このスキルでは、テストタスクやリファクタリングタスクを作成してはいけません。
• 承認状態をチャット内だけに保持してはいけません。
• ワーカーの自由記述ではなく、ワーカーのサマリーを使用します。
• Story が既存コードに影響し、hex-graph が利用可能な場合は、分解の前にグラフ調査を 1 回実施します。
• 計画の曖昧さを減らすためにグラフの出力を使用します。シンボルまたはモジュールの根拠が得られる場合、影響を受けるコンポーネントを推測してはいけません。

完了の定義

• Story スコープの識別子でランタイムを起動
• ディスカバリーをチェックポイントに記録
• 理想的な計画をチェックポイントに記録
• 準備状況のゲートをチェックポイントに記録
• モード検出をチェックポイントに記録
• 決定論的な runId で子タスク計画ランタイムを起動
• 委任前に子実行のメタデータをチェックポイントに記録
• タスク計画ワーカーの概要を記録
• 検証をチェックポイントに記録
• 作成したすべての Task でテンプレート準拠を確認
• 最終結果を記録
• セルフチェックに合格

メタ分析

任意の参考資料：ユーザーが実行後のメタ分析またはプロトコル形式での実行の振り返りを求めた場合に限り、references/meta_analysis_protocol.md を読み込んでください。

スキルの種類：planning-coordinator。求められた場合は、すべてのフェーズの完了後に実行してください。プロトコル形式を使用してチャットに出力してください。

---

バージョン： 4.0.0 最終更新日： 2026-02-03