sligter/codex-autoloop

Codex AutoLoop

長期的な開発タスクを再開可能・監査可能・安全レール付き・必要に応じて停止するワークフローに変換します。

いつ使うか

以下のようなリクエストがあった場合に有効にします：

• 「継続開発 / 自動ループ / バックグラウンド実行」
• 「止めずに完了したら報告」
• 「私は寝るので、あなたは続けて」
• 「CSVタスクリストに従って進める」
• 「plan.mdに従って進める」
• 「Codex / Claude Codeに長時間自律的に反復させる」
• 「牛馬モード」

ごく小さくて数分で完了するタスクの場合は、AutoLoopを無理に使わず、通常通り直接行う方が適切です。

核となる原則

メインループはシンプルです：

1. まず現在のコンテキストを読み込む
2. 境界が明確な小さなタスクまたは単一の仮説を1つ選ぶ
3. 解釈可能なアトミックな変更を1回行う
4. 機械的検証で結果を判断する
5. 成功なら保持、失敗ならロールバック
6. 状態と結果を書き込む
7. 停止条件がトリガーされるまで続ける

gitとステートファイルを記憶として使い、verifyを安全レールとして使います。verifyを「真実そのもの」と見なさないでください。

2つの動作モード

モードA：単一目標ループ

目標が明確で指標も明確なタスクに適しています。例：

• 特定ディレクトリ内の any を減らす
• 特定のテスト群を全てグリーンにする
• 特定のベンチマークを継続的に最適化する
• 特定機能のカバレッジを向上させる

モードB：CSV / plan駆動型デリバリー

一連のバックログタスクがあり、以下が既に定義されている場合に適しています：

• 優先順位
• 依存関係
• 受け入れ基準
• verifyコマンド
• 変更範囲

必要に応じて参照：

• references/csv-template.md：タスク表の書き方
• references/plan-template.md：planを機械実行可能な契約として書く方法

起動前チェック

以下の条件を満たしていない場合、長いループを開始しないでください：

• リポジトリが既にgit管理下にある
• baseline verifyコマンドが手動で一度実行・成功している
• 変更を許可するパスが明確である
• 絶対に変更してはいけないパスが明確である
• state / resultsファイルが誤ってコミットされない
• ユーザーが「自律的に進める / バックグラウンド実行 / 長時間実行」を明確に希望している

停止条件

デフォルトでは継続しますが、以下の状況では停止して報告する必要があります：

1. ゲート失敗：フルゲート / レビューゲートが失敗した
2. 要件の曖昧さ：複数の妥当なプロダクト選択肢が存在するが、plan/タスクに判断ルールが書かれていない
3. 危険な操作：データベース削除、マイグレーション、認証情報処理、オンライン副作用、外部書き込み操作
4. 検証の揺らぎ：verifyがもはや「タスク完了」を適切に表現できていない
5. 連続失敗：複数回の破棄/クラッシュ後も新しい仮説が出てこない
6. 範囲外の変更：変更内容がスコープを超えている
7. 手動チェックポイント：ユーザーが先に確認したいと明示した

「決して邪魔しない」を盲信してはいけません。正しい原則は：

デフォルトでは自律的に進めるが、リスク、曖昧さ、範囲外の場合はすぐにエスカレーションする。

1ラウンドの実行プロトコル

各ラウンドで以下を実行します：

1. 関連するスコープ内のファイル、最新の結果、最近のgit履歴を再読み込みする
2. 1つのタスクまたは1つのアトミックな仮説のみを選択する
3. 最小限の検証可能な変更を行う
4. そのタスクに対応するverifyコマンドを実行する
5. 成功：変更を保持し結果を記録する
6. 失敗：クリーンにロールバックし失敗理由を記録する
7. 停止条件がトリガーされたか確認する
8. 次のラウンドに進む

実験や試行錯誤を重視するタスクは、一時的なブランチや独立したワークスペースで行い、メインブランチを実験のゴミ溜めにしないでください。

verifyの設計要件

良いverifyコマンドは以下を満たす必要があります：

• 機械的：可能な限り主観的判断に依存しない
• 十分に速い：繰り返し実行に適している
• 不正が困難：「指標の水増し」で騙されにくい
• 受け入れに近い：実際の完了基準にできるだけ近い
• 無人運用可能：unattendedで実行しても安全

verifyを設計または修正する際は以下を参照：

• references/verify-scripts.md

git / ロールバックの原則

gitは記憶であり、万能の保険ではありません。

以下の方法を優先し、強引な歴史書き換えは避けてください：

• スクラッチブランチ
• worktree
• リバース可能なコミット列
• スコープ指定のrevert

2つのタスクが glob で重複していないように見えても、簡単に並列化しないでください。共有型、設定、ビルドプロセス、テストスナップショットがある場合、互いに干渉します。

OpenClaw / Codex 実戦アドバイス

セッション/サブエージェント/ACPハーネスをサポートする環境では：

• 小さなタスク：現在のセッションで直接行う
• 長いタスク：分離されたセッションで継続実行する
• Codex / Claude Code / Geminiスタイルの実行を明示的に要求する：対応するハーネス/永続スレッドを使う
• 高頻度でポーリングしない。チェックポイントと完了時のコールバックに頼る
• stateから復元を優先し、中断のたびに再計画しない

必要に応じて参照：

• references/openclaw-execution.md：OpenClaw / managed sessionの推奨設定
• references/python-launcher.md：ローカルDIYランチャーのリファレンス

推奨読書順序

とにかくまず動かしたい場合

1. 本ファイル
2. references/openclaw-execution.md
3. references/verify-scripts.md

タスクリストでバッチ処理したい場合

1. 本ファイル
2. references/csv-template.md
3. references/plan-template.md
4. references/openclaw-execution.md

ランチャーを自分で改造したい場合

1. 本ファイル
2. references/python-launcher.md
3. references/verify-scripts.md

最後に覚えておくこと

目標は「永遠に実行し続けること」ではありません。

目標は：

• できるだけ babysit（監視）の手間を減らす
• プロセスが追跡可能であること
• 問題が発生したら復元可能であること
• 止めるべき時に止めること
• 最終結果が本当にデリバリー可能であること

Autonomous by default. Interruptible by design.