task-runner

タスクランナー

概要

計画を読み込み、精査し、タスクをバッチ単位で実行して、各バッチの間にアーキテクトのレビューを受けるため一時停止します。

基本原則： アーキテクトの監督を受けるチェックポイントを設けて、バッチ単位で実行します。

開始時に次のように伝えます： 「タスクランナーのスキルを適用して、この実装計画を実行します。」

最優先の指示

NO PLAN EXECUTION WITHOUT CRITICAL REVIEW OF EACH TASK FIRST

例外はありません。回避策もありません。近道もありません。

計画には誤りや曖昧さ、古くなった前提が含まれています。実行を始める前に、すべてのタスクを批判的に検討する必要があります。計画に盲目的に従うことは「効率」ではなく、誤った作業に時間を投じることです。

使用するタイミング

digraph applicability {
    "Written plan exists?" [shape=diamond];
    "Tasks independent?" [shape=diamond];
    "Human reviews between batches?" [shape=diamond];
    "task-runner" [shape=box];
    "delegated-execution" [shape=box];
    "Manual execution" [shape=box];

    "Written plan exists?" -> "Tasks independent?" [label="yes"];
    "Written plan exists?" -> "Manual execution" [label="no - write plan first"];
    "Tasks independent?" -> "Human reviews between batches?" [label="yes"];
    "Tasks independent?" -> "Manual execution" [label="no - tightly coupled"];
    "Human reviews between batches?" -> "task-runner" [label="yes - architect reviews"];
    "Human reviews between batches?" -> "delegated-execution" [label="no - stay in session"];
}

task-runner を使用する場合：

• 作成済みの実装計画がある（task-planning または同等の手順で作成したもの）
• 人によるレビューを挟みながら、タスクをバッチ単位で実行する必要がある
• アーキテクトが進捗を確認し、バッチ間で修正を加えることを望んでいる
• 並行セッション（計画セッションとは別のセッション）で作業している

代わりに delegated-execution を使用する場合：

• 同じセッションを継続している（コンテキストの切り替えがない）
• 人によるレビューよりも、自動化された2段階レビュー（仕様＋品質）を希望する
• タスクが独立しており、新しいサブエージェントに割り当てられる

手動で実行する場合：

• まだ文書化された計画がない
• タスク間の結びつきが強く、人による継続的な指示が必要
• 計画を立てるには時期尚早な探索的作業

開始前の手順

計画の実行を始める前に、以下の項目がすべて満たされていることを確認してください。

1. 計画が存在し、アクセスできる — 文書化された計画ファイルへのパスがある
2. 計画を精査している — すべてのタスクを批判的に読み、懸念点を挙げている
3. 懸念点に対処している — 質問や曖昧な点を提示し、回答を得ている
4. テストがベースラインで成功する — 変更を加える前に、既存のテストが成功する
5. ブランチがクリーンである — フィーチャーブランチ（main/master ではない）で作業しており、未コミットの変更がない
6. ワークツリーが設定されている — 分離のために git worktree を使用している（godmode:workspace-isolation）
7. タスクリストが作成されている — すべてのタスクを追跡用チェックリストに読み込んでいる

ゲートのいずれかを満たしていない場合は、停止してください。 すべてのゲートを満たすまで、先に進んではいけません。

認知上の落とし穴

合理化	実際のところ
「計画に問題はなさそうだから、レビューは省こう」	計画には誤りが含まれています。レビューを行えば、誤った作業に時間を浪費する前に発見できます。
「実行しながらレビューしよう」	実行中のレビューでは、すでにその作業に着手しています。開始前にレビューしてください。
「このタスクは説明するまでもない」	説明不要に見えるタスクには、前提が隠れています。30秒のレビューで、30分のやり直しを防げます。
「バッチに分けるのは遅いから、すべて一度にやろう」	バッチは人によるレビューのためにあります。レビューを省くと、すべてのタスクにわたって誤りが積み重なります。
「テストに時間がかかるから、今回は検証を省こう」	検証していないバッチには失敗が隠れています。後からデバッグする方がコストがかかります。
「計画では X となっているが、Y の方がよさそうだ」	人間のパートナーに相談してください。計画から黙って逸脱すると、混乱を招きます。

手順

ステップ 1：計画を読み込み、精査する

1. 計画ファイルを読む
2. 批判的に確認し、各タスクに関する質問や懸念点を挙げる
3. 懸念点がある場合：開始前に人間のパートナーに伝える
4. 懸念点がない場合：タスクリストを作成して進む

ステップ 2：バッチを実行する

デフォルトのバッチサイズ：3タスク

各タスクについて：

1. ステータスを in_progress にする
2. 各手順を正確に実行する（計画には詳細な手順が記載されています）
3. 指定された検証を実行する
4. ステータスを completed にする

ステップ 3：報告する

バッチが完了したら：

• 実装した内容を示す
• 検証結果を示す
• 「フィードバックをお待ちしています。」と伝える

ステップ 4：続行する

フィードバックに基づいて：

• 必要に応じて変更を適用する
• 次のバッチを実行する
• すべてのタスクが完了するまで繰り返す

ステップ 5：最終処理を行う

すべてのタスクが完了し、検証された後：

• 「この作業の最終処理を行うため、merge-protocol のスキルを適用します。」と伝える
• 必須のサブスキル： godmode:merge-protocol を使用する
• テストを検証し、選択肢を提示して、選択された内容を実行する手順に従う

停止して質問するタイミング

次の場合は、直ちに実行を停止してください。

• バッチの途中でブロッカーが発生した場合（依存関係の不足、テスト失敗、指示が不明確など）
• 開始を妨げる重大な欠落が計画にある場合
• 指示を理解できない場合
• 検証が繰り返し失敗する場合

推測するのではなく、説明を求めてください。

前のステップに戻るタイミング

次の場合は、精査（ステップ 1）に戻ってください。

• フィードバックを受けて、パートナーが計画を更新した場合
• 根本的なアプローチを再考する必要がある場合

ブロッカーを無理に乗り越えないでください -- 停止して質問してください。

ガードレール

決して行わないでください。

• 最初に十分に精査していないタスクを実行する
• 「時間を節約する」ために検証ステップを省略する
• 人間のパートナーに伝えず、計画から黙って逸脱する
• ユーザーの明示的な同意なしに main/master ブランチで実装を開始する

必ず行ってください。

• 各タスクをレビューしてから in_progress にする
• 各タスクの後、計画で指定された検証を実行する
• ブロックされたら停止して質問する（推測や場当たり的な対応はしない）
• 完了したバッチを報告し、続行する前にフィードバックを待つ

バッチ実行図

digraph batch_flow {
    rankdir=TB;

    gate [label="Entry Protocol\n(all checks pass?)", shape=diamond];
    gate_fail [label="STOP\nResolve before proceeding", shape=box, style=filled, fillcolor="#ffcccc"];
    load [label="Load plan\nBuild task checklist", shape=box];
    review_task [label="Scrutinize next task", shape=box];
    concerns [label="Concerns?", shape=diamond];
    raise [label="Raise with\nhuman partner", shape=box, style=filled, fillcolor="#ffffcc"];
    execute [label="Mark in_progress\nExecute task steps\nRun verifications", shape=box];
    mark_done [label="Mark completed", shape=box];
    batch_done [label="Batch complete?\n(default: 3 tasks)", shape=diamond];
    report [label="Report results\nSay: Ready for feedback", shape=box, style=filled, fillcolor="#ccffcc"];
    feedback [label="Wait for\nhuman feedback", shape=box];
    apply [label="Apply adjustments\nif needed", shape=box];
    more [label="More tasks?", shape=diamond];
    finish [label="Invoke merge-protocol\nskill", shape=box, style=filled, fillcolor="#ccccff"];

    gate -> gate_fail [label="no"];
    gate -> load [label="yes"];
    load -> review_task;
    review_task -> concerns;
    concerns -> raise [label="yes"];
    raise -> review_task [label="resolved"];
    concerns -> execute [label="no"];
    execute -> mark_done;
    mark_done -> batch_done;
    batch_done -> review_task [label="no"];
    batch_done -> report [label="yes"];
    report -> feedback;
    feedback -> apply;
    apply -> more;
    more -> review_task [label="yes - next batch"];
    more -> finish [label="no - all done"];
}

リマインダー

• 開始前に計画を批判的に精査する
• 計画のステップに正確に従う
• 検証を省略しない
• 計画で求められている場合はスキルを参照する
• バッチの間は、報告して返答を待つ
• ブロックされたら、推測せずに停止する
• ユーザーの明示的な同意なしに main/master で実装を開始しない

関連項目

必須のワークフロースキル：

• godmode:workspace-isolation - 必須：開始前に分離されたワークスペースを設定する
• godmode:task-planning - このスキルが実行する計画を作成する
• godmode:merge-protocol - すべてのタスク完了後に開発を最終化する

実行中、タスクで次のスキルが呼び出されることがあります。

• godmode:test-first - 計画のタスクで新しいコードを書く場合
• godmode:fault-diagnosis - タスクで予期しない失敗が発生した場合
• godmode:completion-gate - 報告前に各バッチを検証する

代替ワークフロー：

• godmode:delegated-execution - 人間が介在するバッチ方式ではなく、自動化された2段階レビューを使って同一セッション内で実行する場合に使用する