long-task-coordinator

長時間タスクコーディネーター

長時間実行する作業を、復旧可能な状態に保ち、状態を維持し、誠実に報告します。

このスキルを使うタイミング

次のような作業には、このスキルを使ってください。

• 複数のターンやセッションにまたがる
• ワーカー、サブエージェント、バックグラウンドジョブへの引き継ぎを伴う
• 「まだ調査中です」といった更新ではなく、明示的な待機状態が必要になる
• 中断後も永続的な状態ファイルから再開できる必要がある

小規模で単一ターンで完了するタスクには、このスキルを使わないでください。シンプルな計画で十分で、復旧ロジックが主な懸念事項でない場合は、planning-with-files を使ってください。

関連スキル

• planning-with-files は、複数ステップの作業をファイルで整理します。
• workflow-orchestrator は、マイルストーン後に後続のスキルを連鎖させます。
• long-task-coordinator は、長時間実行する作業を再開可能かつ監査可能にし、安全な引き継ぎを可能にします。

基本ルール

1. 信頼できる唯一の情報源を作る

実際の長時間タスクでは、永続的な状態ファイルを1つ管理してください。チャット履歴は信頼できる状態保存先ではありません。

状態ファイルには、少なくとも次の情報を記録してください。

• 目標
• 成功基準
• 現在のステータス
• 現在のステップ
• 完了した作業
• 次のアクション
• 次のチェックポイント
• ブロッカー
• 担当中のオーナーまたはワーカー

2. 必要な場合にのみ役割を分ける

タスクに適した、最小限の役割モデルを使ってください。

• 起案者：目標と受け入れ基準を担当します
• コーディネーター：状態、順序付け、復旧を担当します
• ワーカー：範囲を限定したサブタスクを実行します
• ウォッチドッグ：稼働状況の確認と復旧のみを担当します

単純なタスクでは、これらの役割を1つのエージェントにまとめてもかまいません。長時間のタスクや委任されたタスクでは、役割分担を明確にしてください。

3. 各サイクルを必ず次の順序で実行する

調整ラウンドごとに、次の順序で実行してください。

READ -> RECOVER -> DECIDE -> PERSIST -> REPORT -> END

状態ファイルを更新する前に、結論を報告しないでください。

4. awaiting-result を有効な状態として扱う

ワーカーやバックグラウンドジョブのディスパッチが正常に完了している場合、結果がまだ戻っていないという理由だけでタスクが失敗しているわけではありません。

有効な遷移には次のものがあります。

• running -> awaiting-result
• awaiting-result -> running
• running -> paused
• running -> complete

5. 終了していないラウンドでは、実際の進捗を生み出す

調整ラウンドが有効と見なされるには、次のいずれかを少なくとも1つ実行する必要があります。

• 範囲を限定した作業をディスパッチする
• 新しい結果を取り込む
• 現在の段階または判断を更新する
• 新しい次のステップまたはチェックポイントを保存する
• 明示的な復旧を行う

何も変わっていない場合は、タスクが進んだかのように装わないでください。

6. 復旧とドメイン作業を分けて行う

復旧では、次の点を確認します。

• 実行状況が保存された状態から逸脱していないか
• 期待されるワーカーの結果がまだ保留中か
• 待機、再試行、再ディスパッチのどれが必要か

ドメイン作業では、次の点を確認します。

• 次に何を構築、分析、または提出すべきか

まず復旧を行い、その後でドメイン作業を続けてください。

運用ワークフロー

ステップ 1: タスクに調整が必要か判断する

次のいずれかに当てはまる場合は、このスキルを使ってください。

• タスクが現在のターンを超えて続く
• 別の実行単位に作業を引き継ぐ
• チェックポイント、ポーリング、または予定されたフォローアップが必要になる
• 状態が失われた場合のコストが大きくなるほど複雑である

ステップ 2: 状態ファイルを作成または読み込む

次のように、見つけやすいパスを優先してください。

• docs/<topic>-execution-plan.md
• docs/<topic>-state.md
• worklog/<topic>-state.md

永続的な状態がまだ存在しない場合は、references/workflow.md を基に作成してください。

ステップ 3: 行動する前に復旧する

新しいラウンドの開始時には、毎回次の手順を実行してください。

1. 状態ファイルを読む
2. 記録されている次のステップがまだ適切か確認する
3. 委任した作業から結果が戻っているか確認する
4. 新たな行動を起こす前に、古くなった前提を修正する

ステップ 4: 報告する前に保存する

次のアクションを決定した後、次の手順を実行してください。

1. 状態ファイルを更新する
2. 新しいステータス、担当者、ブロッカー、チェックポイントを記録する
3. その後でのみ、ユーザーまたは呼び出し元に進捗を報告する

ステップ 5: ラウンドを誠実に終了する

各ラウンドは、次のいずれかの状態で終了してください。

• running
• awaiting-result
• paused
• blocked
• complete

報告するステータスは、保存済みのステータスと正確に一致していなければなりません。

出力時の期待事項

このスキルを使用する際は、保存された状態に基づいて進捗を報告してください。

• 現在のタスクの状態
• 今回変更した内容
• 次に予定されている作業
• タスクの進行を妨げている要因、または完了に必要なもの

受け入れ基準

以下の関連項目がすべて満たされた場合にのみ、調整作業が完了したものとします。

• 予測可能なパスに永続的な状態ファイルが存在する
• 保存されたステータスが実際のタスクの状態と一致している
• 完了した作業、次のアクション、ブロッカーが明示的に記録されている
• 委任した作業がある場合、担当者の名前と結果の返却条件が記録されている
• 最終報告が一時的な推論ではなく、永続化された状態に基づいている

タスクが実際には完了していない場合、完了したかのように装わず、running、awaiting-result、paused、または blocked で終了してください。

アンチパターン

次のことは避けてください。

• 状態ファイルを参照せず、記憶から進捗を再構築する
• 結論を保存する前に報告する
• 待機中を失敗として扱う
• 新しいアクションも状態の変更もないままラウンドを終了する
• 復旧確認とドメイン上の判断を、曖昧な一つのステップに混在させる

参考資料

• references/workflow.md - 詳細なワークフロー、状態テンプレート、復旧チェックリスト