self-improve

自己改善オーケストレーター

進化的なコード改善のための自律ループコントローラーです。セットアップ、調査、計画、実行、トーナメント選択、履歴の記録、停止条件の評価まで、ライフサイクル全体を管理します。

使用する場面

• 測定可能なベンチマーク目標に向けて、コードベースを段階的に改善したい場合
• パフォーマンス、バンドルサイズ、テストカバレッジ、精度などの最適化タスク
• 測定可能な指標を用いたコード品質の改善

使用しない場面

• 測定可能なベンチマークがない場合
• 1回限りの修正や機能リクエストの場合 → /omg-autopilot を使用してください
• 手動で対話しながらコーディングする場合 → /ralph を使用してください

自律実行ポリシー

改善ループ中に、ユーザーに確認を求めて停止または一時停止してはいけません。 ゲートチェックに合格してループが始まったら、停止条件を満たすまで完全に自律実行します。

• イテレーション間で確認を求めないでください
• エージェントが失敗した場合：1回だけ再試行し、その後はスキップして続行します
• すべての計画が却下された場合：記録して、次のイテレーションに進みます
• ループを停止するのは、ステップ11の停止条件のみです

状態管理

すべての状態は .omc/self-improve/ 以下に保存されます。

.omc/self-improve/
├── config/
│   ├── settings.json          # agents, benchmark, thresholds, sealed_files
│   ├── goal.md                # Improvement objective + target metric
│   ├── harness.md             # Guardrail rules (H001/H002/H003)
│   └── idea.md                # User experiment ideas
├── state/
│   ├── agent-settings.json    # iterations, best_score, status, counters
│   ├── iteration_state.json   # Within-iteration progress (resumability)
│   ├── research_briefs/       # Research output per round
│   ├── iteration_history/     # Full history per round
│   ├── merge_reports/         # Tournament results
│   └── plan_archive/          # Archived plans (permanent)
├── plans/                     # Active plans (current round)
└── tracking/
    ├── raw_data.json          # All candidate scores
    ├── baseline.json          # Initial benchmark score
    └── events.json            # Config changes

エージェントの割り当て

ステップ	役割	エージェント	目的
調査	コードベース分析	@explore + @architect	仮説の生成
計画	仮説 → 計画	@planner	エージェントごとに構造化された計画を作成
アーキテクチャレビュー	6項目レビュー	@architect	助言的なレビュー
批評レビュー	ハーネスルールの適用	@critic	計画の承認／却下
実行	実装 + ベンチマーク	@executor	計画に忠実に実装
Git 操作	マージ／タグ付け／PR	@git-master	アトミックなマージ操作

セットアップフェーズ

1. 対象リポジトリのパスが存在するか確認します。未設定の場合はユーザーに尋ねます。
2. .omc/self-improve/ ディレクトリ構造を作成します。
3. agent-settings.json を読み込みます。セットアップフラグを確認します。
4. 信頼の確認（必須）：
   • 対象リポジトリのパスを表示し、ベンチマーク実行の確認をユーザーに求めます。
   • 拒否された場合：中止します。
   • 同意を記録します：trust_confirmed: true
5. 目標が設定されていない場合 → ソクラテス式インタビュー（目的、指標、目標値、範囲）を実施します。goal.md に書き込みます。
6. ベンチマークが設定されていない場合 → リポジトリを調査し、ベンチマークを作成またはラップして、3回検証し、ベースラインを記録します。
7. ハーネスが設定されていない場合 → デフォルトのハーネスルール（H001/H002/H003）を確認します。
8. ゲート：すべての設定と信頼確認が完了している必要があります。
9. 対象ブランチから改善用ブランチ improve/{goal_slug} を作成します。
10. omg_write_state を使って初期状態を書き込みます。

改善ループ

ゲート：すべての設定が完了している必要があります。停止せずに継続して実行します。

ステップ0 — 古いワークツリーのクリーンアップ

以前のイテレーションで残されたワークツリーを削除します。

ステップ1 — 状態の更新

TTL をリセットするため、状態を更新します。

ステップ2 — 停止リクエストの確認

状態がクリアされているか、ステータスが user_stopped の場合は、正常に終了します。

ステップ3 — ユーザーのアイデアの確認

idea.md を読み込みます。空でない場合は、プランナーに渡します。

ステップ4 — 調査

@explore と @architect を起動し、目標、履歴、以前の概要に基づいてコードベースを分析し、仮説を生成します。

ステップ5 — 計画

N 個の @planner エージェントを並列で起動します（N = number_of_agents）。各エージェントは、検証可能な仮説を1つ、approach_family タグ、history_reference を含む計画を作成します。

ステップ6 — レビュー

各計画について：

• 6a. アーキテクチャレビュー：@architect が6項目のチェックリスト（テスト可能性、新規性、範囲、対象ファイル、実装の明確さ、期待される結果）を用いてレビューします。助言のみです。
• 6b. 批評レビュー：@critic がハーネスルール（H001：仮説を1つにする、H002：approach_family の連続が3回以上にならない、H003：ラウンド内の多様性）を確認します。critic_approved: true/false を設定します。

ステップ7 — 実行

承認された各計画について、@executor を並列で起動します。各エグゼキューターは Git ワークツリー内で作業し、計画を実装して、検証とベンチマークを実行します。

ステップ 8 — トーナメント選択

1. 結果を収集し、status: "success" のものに絞り込みます
2. benchmark_score の順に順位付けします（方向を考慮）
3. 各候補について、最良のものから順に以下を行います。
   • best_score と比較して性能低下がないか確認します
   • @git-master を使って --no-ff でマージします
   • マージ後の状態で再ベンチマークを実行します
   • 確認できた場合：勝者として採用し、終了します
   • 性能低下があった場合：マージを取り消し、次の候補を試します
   • コンフリクトが発生した場合：マージを中止し、次の候補を試します
4. 勝者以外のブランチをアーカイブします

ステップ 9 — 記録と可視化

イテレーション履歴を記録し、agent-settings（スコア、停滞回数、サーキットブレーカー）を更新して、追跡データを追記します。

ステップ 10 — クリーンアップ

ワークツリーを削除し、イテレーション状態を completed に更新します。

ステップ 11 — 停止条件の確認

条件	確認方法
ユーザーによる停止	status == "user_stopped"
目標達成	best_score が target_value 以上
停滞	plateau_consecutive_count >= plateau_window
最大イテレーション数	iterations >= max_iterations
サーキットブレーカー	circuit_breaker_count >= circuit_breaker_threshold

停止条件に該当しない場合は、直ちにステップ 1 に戻ります。

再開可能性

呼び出し時：

1. 必ずステップ 0（古いワークツリーのクリーンアップ）を実行します
2. agent-settings.json を確認します。
   • user_stopped：再開するか確認します
   • running：クラッシュした状態です。自動的に再開します
   • idle：新規に開始します
3. iteration_state.json を確認します。進行中の場合は、最後のステップから再開します

完了

1. 最終ステータスを更新します
2. 概要（ステータス、イテレーション数、最高スコア、ベースライン、改善率）を出力します
3. 状態をクリーンアップするために /cancel を実行します

アプローチファミリーの分類

各計画には、次のいずれか1つだけをタグ付けする必要があります。

タグ	説明
architecture	モデル／コンポーネント構造の変更
training_config	オプティマイザー、LR、スケジューラー、バッチサイズ
data	データの読み込み、拡張、前処理
infrastructure	混合精度、分散学習
optimization	アルゴリズム／数値計算の最適化
testing	評価方法の変更
documentation	ドキュメントのみの変更
other	上記に該当しないもの