chaseai-yt/claudex-loop

Claudex Loop

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

ロールを1度解決する

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

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

builder=claude|codex を尊重します。検査担当は常にもう一方のプロバイダーです。もう一方のプロバイダーが構築する場合でも、ホストは調整役のままです。プランナーを変更するには、もう一方のホストで会話を開始してください。CLIレビュー担当がユーザーの計画会話であるかのように偽装しないでください。

モデル選択はプロバイダーのロールとは独立しています。ホストの選択されたモデルを保持します。レビュー/ビルドのCLI呼び出しは、reviewer_model、builder_model、または inspector_model が指定されない限り、自身の構成を継承します。これらをその呼び出しのランナーの --model にマッピングします。明示的な *_effort も同様に適用します。Fable 5.1 と GPT-6 Astra は適切な明示的な選択肢であり、必須の固定ではありません。ホストUIのモデルは、別のCLIが使用するモデルを証明しません。要求されたモデル情報と観測されたモデル情報は別々に報告し、未解決のCLIデフォルトは正直に報告してください。失敗時に暗黙的に別のモデル/プロバイダーにフォールバックしないでください。

CLIを起動する前にランタイムリファレンスを読んでください。そのランナーを、レビュー対象のプロジェクトではなく、このインストールされた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	host	計画を実装するプロバイダー
research	タスクに比例	none、web、または明示的なオプトイン deep
mode	full	full は偵察/インタビューを含みます。review は既存の計画から開始します
inspect	on	off はユーザーが明示的にオプトアウトした場合のみ。記録します
MAX_FIX_ROUNDS	2	報告または引き継ぎまでの、ビルド修正試行の上限
MAX_INSPECTION_ROUNDS	2	初回検査と修正後の1回を含む

開始前に、ロール、パス、ラウンド制限、要求されたモデル、検査のオプトアウトをエコーします。既存の承認を維持します。計画の要求は構築を許可しません。計画と実装の要求は許可します。残りの承認を求める前に、許可された準備を行います。

フェーズ0 — 偵察

既存のプロジェクトについては、関連するコード、依存関係、共有状態の呼び出し元と書き込み元を検査します。既存の CONTEXT.md / CONTEXT-MAP.md および関連するADRを読みます。グリーンフィールドの作業では、先行技術、妥当なスタック、および有用な場合の具体的な障害モードを調査します。明示的な調査深度を尊重します。深いマルチエージェント調査には明示的なオプトインと利用可能なツールが必要です。それ以外の場合は、サポートされているターゲット調査を使用し、制限を報告します。独自のワークフローツールを必要としたり、調査エージェントのモデルをハードコーディングしたりしないでください。

ホストの利用可能なカタログと、アクセス可能な場合のもう一方のプロバイダーの文書化されたスキルロケーションを通じて、関連するスキルを発見します。提案された関連する依存関係のみを記録します。ホストのMCP、ブラウザ、認証情報、またはスキルがもう一方のCLIに転送されることを前提としないでください。依存する前に、必要なビルド機能を確認してください。

ソースパスまたは調査リンクを含む1つの仮定台帳を提示します。重要な不確実性の修正を一括して求めます。ユーザーが作業を承認している場合は、ルーチンの可逆的な選択は自分で解決します。承認を必要とするアクションに対する承認としての黙認はありません。

フェーズ1 — 要件の確定

短くて見える決定マップを維持します。結果を変える未解決の決定についてのみ質問します。それぞれの重要な質問に対して、推奨事項、それが重要な理由、および間違った推測のコストを提供します。独立した質問はまとめてください。依存関係のある質問は順番に行います。コードが答えられる場合は、代わりにコードを検査します。長い決定リストがユーザーの速度を低下させる場合は、「残りの推奨事項をすべて受け入れる」を提供します。

既存の用語集の定義を尊重します。曖昧なドメイン言語を解決します。用語集のみのコンテキストは、CONTEXT-FORMAT.md を使用して遅延的に維持します。変更が高コストで元に戻せない、明白でないトレードオフについてのみ、ADR-FORMAT.md を使用してADRを記録します。

解決された PLAN_FILE を以下の内容で記述します。

• 目標と観測可能な合格基準。
• 具体的なアプローチ、主要な決定、トレードオフ、および非目標。
• ソースと残りのリスクを含む確認済みの仮定。
• プロバイダーごとの関連するツールチェーン要件（ある場合）。
• 検証：正確な証明コマンド、期待される結果、および必要に応じて手動/視覚的なチェック。

可能な場合はリポジトリから証明コマンドを導出します。何が成功とみなされるかが不明確な場合にのみ質問します。追記専用の LOG_FILE を、ロール、モデル要求、スコープ、承認、およびラウンド制限から開始します。実行診断はチェックアウト外に保持します。

mode=review の場合、提供された計画をロードし、必要な場合にのみユーザーと共に重要なギャップを埋め、直接レビューに進みます。要件インタビューを再開しないでください。

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

共有ランナーを review モードで、実際の --host、解決された --plan、およびオプションのモデル/努力量と共に使用します。最初のラウンドでセッションを作成します。以降のラウンドでは、同じプロバイダー/モデル/努力量と、ホストが作成した処分を含む --feedback ファイルを使用して --resume <previous-successful-result.json> を使用します。推測されたセッションID、--last、またはビルドセッションをレビュー担当者として使用しないでください。

各成功した応答には、評決、証拠に裏付けられた所見、実際のカバレッジ、および制限が含まれます。応答全体とランナーの結果パスを LOG_FILE に保持します。

• APPROVED： 未解決の重要な欠陥はありません。承認は正確な計画パスとSHA256にバインドされています。残りの優先度の低いアドバイスと制限を提示します。所見がゼロであることは有効であり、完全な正確性の証明ではありません。
• REVISE： ホストは各所見を仲裁します。正当な計画変更を実装します。サポートされていない提案は理由とともに却下します。処分を記録し、修正された計画を同じレビュー担当者に送信します。新しい証拠なしに解決済みのポイントを再議論することは避けてください。
• BLOCKED / 失敗したプロセス / 不正な結果： これを承認としてカウントしないでください。実際の不足している証拠または操作上の失敗を説明してください。盲目的な再試行やプロバイダーのサイレント切り替えで残りのラウンドを無駄にしないでください。

MAX_ROUNDS で停止します。未解決の所見とホストの立場を、収束を偽装する代わりに提示します。変更された計画には別のレビューが必要です。構築する前に、最終計画の承認チェックを実行します。ユーザーが独立した承認なしで進めることを明示的に選択した場合、そのオーバーライドを記録し、レビューされていない仕様のスタンドアロンパスを使用します。承認済みとしてラベル付けしないでください。

フェーズ3 — 構築と検査

レビューされた計画、改善点、および残りの制限を提示します。実装がまだ承認されていない場合は、その最終決定を求めます。選択されたビルダーを使用し、デフォルトはホストです。ビルドリファレンスを読んでください。

ホストは通常のツールで直接実装できます。別のビルダーの場合は、共有ランナーの build モードを使用します。どちらのパスでも、ビルド前のコミットをキャプチャし、無関係なユーザーの作業を保持し、同じ解決された計画と検証契約を伝達する必要があります。

合意された証明チェックを実行し、すべての変更されたファイルを検査し、新しい inspect セッションでもう一方のプロバイダーを通じて結果をレビューします。ビルド前のコミットとビルダーのIDを提供します。受け入れられた修正後の再検査も新しいセッションを使用します。所見と処分を記録します。修正後に関連する証明チェックを再実行します。

コーディネーターがコーディングを引き継いだ場合、それはビルダーになりました。その変更の新しい他プロバイダーによる検査を要求します。以前の検査が後の編集をカバーしているとは決して説明しないでください。両方のプロバイダーがコードを提供した場合は、著作者を記録し、それぞれが他方の変更を検査するようにします。どのモデルも、自分が作成したコードを独立してレビューしたと主張しないでください。検査予算を使い果たした場合は、残りの所見とレビューされていない編集をユーザーの決定のために明示的に報告します。

最終的な差分、証明結果、検査カバレッジ、未解決の所見、逸脱、および使用されたラウンドを提示します。既存のコミット/プッシュ承認を尊重します。それ以外の場合は、具体的な差分を承認のために準備しておきます。ループを実行したという理由だけで外部公開が暗示されることは決してありません。