claudex-loop

Claudex Loop

現在の会話が要件、計画、調整を担います。もう一方のプロバイダーが計画をレビューします。どちらのプロバイダーも実装できます。実装を担当しなかったプロバイダーが、新しいセッションで最終コードを検査します。

役割を一度だけ確定する

PATH、インストール済みのスキル、モデル名の推測、リポジトリではなく、実行環境から実際のホストを特定します。両方の CLI がインストールされている場合があります。Claude Code では host=claude、Codex では host=codex を使用します。実行環境の識別情報を利用できない場合は、ユーザーがどちらのホストを使用しているか一度だけ尋ねます。

ホスト	要件と計画	計画レビュー担当	デフォルトの実装担当	最終検査担当
Claude Code	現在の Claude セッション	Codex	Claude	新しい Codex セッション
Codex	現在の Codex セッション	Claude	Codex	新しい Claude セッション

builder=claude|codex の指定に従います。検査担当は常にもう一方のプロバイダーです。もう一方のプロバイダーが実装する場合も、ホストが調整役を務めます。計画担当を切り替えるには、もう一方のホストで会話を開始します。CLI のレビュー担当者をユーザーの計画会話であるかのように扱ってはいけません。

モデルの選択はプロバイダーの役割とは独立しています。ホストで選択されているモデルを維持します。reviewer_model、builder_model、inspector_model が指定されていない限り、レビュー／実装の CLI 呼び出しでは、それぞれの独自の設定が引き継がれます。指定されている場合は、その呼び出しに対する runner の --model に対応付けます。明示的な *_effort も同様に適用します。Fable 5.1 と GPT-6 Astra は、明示的に選択するモデルとして適していますが、必須ではありません。ホスト UI でのモデル表示は、別の CLI が使用するモデルを証明するものではありません。要求されたモデル情報と確認できたモデル情報は分けて報告し、未確定の CLI デフォルトは正直に報告します。失敗した場合に、別のモデル／プロバイダーへ黙って切り替えてはいけません。

CLI を起動する前にランタイムリファレンスを読みます。runner は、レビュー対象のプロジェクトではなく、インストール済みのこの SKILL.md を基準に解決します。起動時には絶対パスを使用します。

ユーザーが codex_cli または claude_cli を指定した場合は、選択されたプロバイダーの実行ファイルのパスを --cli に対応付けます。ホストアプリに、PATH 上の CLI より新しく正常に動作するバイナリが含まれている場合があります。グローバルなインストールや設定を黙って変更せず、パスとバージョンを確認します。

調整可能な項目

引数	デフォルト	意味
PLAN_FILE / plan	PLAN.md	ビルドへの引き継ぎを含め、全体を通して使用する計画ファイルのパス
LOG_FILE / log	PLAN-REVIEW-LOG.md	追記専用の記録
rounds / MAX_ROUNDS	5	計画レビューの完了ラウンド数の上限
builder	ホスト	計画を実装するプロバイダー
research	タスクに応じた範囲	none、web、または明示的なオプトインが必要な deep
mode	full	full では調査／ヒアリングを行い、review では既存の計画から開始
inspect	on	ユーザーが明示的にオプトアウトした場合のみ off。オプトアウトしたことを記録
MAX_FIX_ROUNDS	2	報告または引き継ぎの前に試行できる、ビルド修正回数の上限
MAX_INSPECTION_ROUNDS	2	初回検査と修正後の検査を合わせた回数の上限

開始前に、役割、パス、ラウンド数の上限、要求されたモデル、検査のオプトアウトを復唱します。既存の承認範囲を維持します。計画の依頼はビルドの許可を意味しませんが、計画と実装の依頼は許可を意味します。残りの承認を求める前に、承認済みの準備を行います。

フェーズ 0 — 調査

既存のプロジェクトでは、関連するコード、依存関係、共有状態の呼び出し元と書き込み元を調査します。既存の CONTEXT.md／CONTEXT-MAP.md と関連する ADR を読みます。新規プロジェクトでは、必要に応じて先行事例、妥当な技術スタック、具体的な障害パターンを調査します。明示された調査の深度を尊重します。複数のエージェントによる詳細な調査には明示的なオプトインと利用可能なツールが必要です。そうでない場合は、対応している範囲で対象を絞った調査を行い、制約を報告します。プロプライエタリな Workflow ツールを必須としたり、調査エージェントのモデルをハードコードしたりしないでください。

ホストで利用可能なカタログと、アクセスできる場合は他のプロバイダーが文書化しているスキルの場所を通じて、関連するスキルを見つけます。提案する依存関係は関連するものだけを記録します。ホストの MCP、ブラウザー、認証情報、スキルが他の CLI に引き継がれると想定しないでください。それらに依存する前に、必要なビルド機能を確認します。

前提条件をまとめた台帳を 1 つ提示し、参照元のパスまたは調査リンクを記載します。重要な不確実性について、まとめて訂正を求めます。ユーザーが作業を許可している場合は、通常の取り消し可能な選択は自分で解決します。承認が必要な行動について、沈黙を承認と見なしてはいけません。

フェーズ 1 — 要件の確定

簡潔で見やすい意思決定マップを維持します。結果を左右する未解決の決定についてのみ質問します。重要な質問には、それぞれ推奨案、重要である理由、誤って推測した場合のコストを示します。互いに独立した質問はまとめて尋ね、依存関係のある質問は順番に尋ねます。コードで確認できる場合は、代わりに調査します。決定事項が多く、ユーザーの負担になる場合は、「残りの推奨案をすべて受け入れる」という選択肢を提示します。

既存の用語集の定義を尊重し、曖昧なドメイン用語を解決します。CONTEXT-FORMAT.md を使用して、用語集のみのコンテキストを必要に応じて維持します。元に戻すコストが高く、かつ自明でないトレードオフについてのみ、ADR-FORMAT.md を使用して ADR を記録します。

以下を含む、確定済みの PLAN_FILE を作成します。

• 目標と、客観的に確認できる受け入れ基準。
• 具体的なアプローチ、重要な決定、トレードオフ、対象外事項。
• 参照元を明記した確定済みの前提条件と、残るリスク。
• 必要に応じた、プロバイダーごとの関連ツールチェーン要件。
• 検証方法：正確な証明コマンドと期待される結果、および必要な場合は手動／目視での確認。入力を生成するプログラムの実際の出力を使って変更を検証し、手書きのサンプルだけで済ませないでください。コードを置き換える場合は、同じ入力に対して旧コードと新コードを実行し、比較します。

可能な場合は、リポジトリを基に証明コマンドを導き出します。成功の条件が不明確な場合にのみ質問します。追記専用の LOG_FILE は、役割、モデルへのリクエスト、スコープ、承認、ラウンドの上限を記載して開始します。実行時の診断情報はチェックアウトの外部に保持します。

mode=review の場合は、提供された計画を読み込み、必要に応じて重要な不足点のみをユーザーと補完し、直接レビューに進みます。要件のヒアリングを最初からやり直してはいけません。

フェーズ 2 — 独立した計画レビュー

実際の --host、解決済みの --plan、任意のモデル／effort を指定して、共有ランナーを review モードで使用します。最初のラウンドでセッションが作成されます。以降のラウンドでは、同じプロバイダー／モデル／effort を指定し、判断内容を記載したホスト作成の --feedback ファイルとともに、--resume <previous-successful-result.json> を使用します。推測したセッション ID、--last、またはビルドセッションをレビュアーとして使用してはいけません。

成功した各レスポンスには、判定、根拠に裏付けられた指摘事項、実際の確認範囲、制限事項が含まれます。レスポンス全体とランナーの結果パスを LOG_FILE に保存します。

• APPROVED： 未解決の重大な欠陥はありません。承認は、指定されたプランのパスと SHA256 に対して有効です。残る優先度の低い助言や制限事項を提示します。指摘事項がゼロでも問題ありませんが、それは網羅的な正しさの証明ではありません。
• REVISE： 各指摘事項はホストが判断します。妥当なプラン変更を実施し、裏付けのない提案は理由を添えて却下します。変更によって動作を置き換える場合は、プラン全体を検索し、置き換えられた条件が残る箇所をすべて変更または明示します。受け入れ基準も対象です。判断内容を記録し、改訂したプランを同じレビュアーに送ります。新たな根拠がない限り、解決済みの点を蒸し返さないでください。
• BLOCKED／プロセス失敗／不正な結果： 承認として扱ってはいけません。実際に不足している根拠または運用上の失敗を説明します。闇雲な再試行で残りのラウンドを浪費したり、黙ってプロバイダーを切り替えたりしてはいけません。レビュープロバイダーのクォータを超過している場合、別モデルへのフォールバックはありません。クォータのリセットを待つか、以下に記録された未レビューの進め方をユーザーに選んでもらいます。

MAX_ROUNDS に達したら終了します。収束したことにしてはいけません。未解決の指摘事項とホストの見解を提示します。プランを変更した場合は、再度レビューが必要です。ビルドの前に、最終プランに対して承認チェックを実行します。独立した承認なしで進めることをユーザーが明示的に選んだ場合は、その例外を記録し、スタンドアロンの未レビュー仕様の手順を使用します。承認済みと表示してはいけません。

フェーズ 3 — ビルドと確認

レビュー済みのプラン、改善点、残る制限事項を提示します。実装がまだ承認されていない場合は、最終判断を求めます。選択されたビルダーを使用し、既定ではホストを選びます。ビルドのリファレンスを読みます。

ホストは通常のツールを使って直接実装できます。別のビルダーを使う場合は、共有ランナーの build モードを使用します。どちらの方法でも、ビルド前のコミットを記録し、無関係なユーザーの作業を保持し、同じ解決済みプランと検証契約を引き継ぐ必要があります。

合意した検証を実行し、変更されたすべてのファイルを確認したうえで、別のプロバイダーによる新規の inspect セッションで結果をレビューします。ビルド前のコミットとビルダーの識別情報を渡します。受け入れた修正後の再検査にも、新規セッションを使用します。指摘事項と判断内容を記録し、修正後は影響を受ける検証を再実行します。

コーディネーターがコーディングを引き継いだ場合、コーディネーターはビルダーになったことになります。その変更は、別のプロバイダーによる新規の検査を必須とします。先の検査が後の編集も対象にしたと説明してはいけません。両方のプロバイダーがコードに貢献した場合は、誰が何を書いたかを記録し、互いの変更をそれぞれ検査させます。モデル自身が作成したコードを独立してレビューしたと主張してはいけません。検査の上限に達した場合は、残る指摘事項と未レビューの編集を明示し、ユーザーに判断を委ねます。

最終差分、検証結果、検査範囲、未解決の指摘事項、逸脱、使用したラウンド数を提示します。既存のコミット／プッシュの承認を尊重します。それ以外の場合は、最終承認に向けて具体的な差分を整えた状態で残します。このループを実行しただけで、外部への公開が暗黙に承認されたことにはなりません。