/claudex-loop

name: claudex-loop
description: "Harden a plan with independent Claude/Codex review, then optionally build and cross-inspect it. Start in either Claude Code or Codex: the host plans and the other provider reviews. Use for claudex this plan, claudex-loop, or the legacy crucible trigger; not for trivial edits."

Claudex Loop

The current conversation owns requirements, planning and coordination. The other provider reviews the plan. Either provider can build; the provider that did not build inspects the final code in a fresh session.

Resolve roles once

Identify the actual host from your runtime, not PATH, installed skills, model-name guesses, or the repository. Both CLIs may be installed. Use `host=claude` in Claude Code and `host=codex` in Codex. If the runtime identity is unavailable, ask which host the user is using once.

| Host | Requirements and plan | Plan reviewer | Default builder | Final inspector | |---|---|---|---|---| | Claude Code | Current Claude session | Codex | Claude | Fresh Codex session | | Codex | Current Codex session | Claude | Codex | Fresh Claude session |

Honor `builder=claude|codex`. The inspector is always the other provider. The host remains coordinator even when the other provider builds. To swap the planner, start the conversation in the other host; do not pretend a CLI reviewer is the user's planning conversation.

Model selection is independent of provider roles. Preserve the host's selected model. Review/build CLI calls inherit their own configuration unless `reviewer_model`, `builder_model`, or `inspector_model` is supplied; map these to the runner's `--model` for that invocation. Apply an explicit `*_effort` similarly. Fable 5.1 and GPT-6 Astra are suitable explicit choices, not mandatory pins. A model in the host UI does not prove which model a separate CLI will use. Report requested and observed model information separately; report an unresolved CLI default honestly. Never silently fall back to another model/provider on a failure.

Read [the runtime reference](references/runtime.md) before launching a CLI. Resolve its runner relative to this installed SKILL.md, never relative to the project being reviewed. Use absolute paths when launching it.

If the user supplies `codex_cli` or `claude_cli`, map the selected provider's executable path to `--cli`. A host app can have a newer working binary than the CLI on PATH; verify the path and version without silently changing global installation or configuration.

Tunables

| Argument | Default | Meaning | |---|---|---| | `PLAN_FILE` / `plan` | `PLAN.md` | Plan path used throughout, including the build handoff | | `LOG_FILE` / `log` | `PLAN-REVIEW-LOG.md` | Append-only transcript | | `rounds` / `MAX_ROUNDS` | `5` | Maximum completed plan-review rounds | | `builder` | host | Provider implementing the plan | | `research` | proportionate to task | `none`, `web`, or explicit opt-in `deep` | | `mode` | `full` | `full` includes recon/interview; `review` starts from an existing plan | | `inspect` | `on` | `off` only when the user explicitly opts out; record it | | `MAX_FIX_ROUNDS` | `2` | Bounded build-fix attempts before reporting or taking over | | `MAX_INSPECTION_ROUNDS` | `2` | Initial inspection plus one after fixes |

Echo roles, paths, round limits, requested models and inspection opt-out before starting. Preserve existing authorization: a request to plan does not authorize building; a request to plan and implement does. Do authorized preparation before seeking any remaining sign-off.

Phase 0 — Recon

For existing projects, inspect relevant code, dependencies, callers and writers of shared state. Read existing `CONTEXT.md` / `CONTEXT-MAP.md` and relevant ADRs. For greenfield work, research prior art, a reasonable stack and concrete failure modes when useful. Respect an explicit research depth. Deep multi-agent research requires explicit opt-in and an available tool; otherwise use supported targeted research, and report the limitation. Do not require a proprietary Workflow tool or hard-code a research-agent model.

Discover relevant skills through the host's available catalog and the other provider's documented skill locations when accessible. Record only relevant proposed dependencies. Do not assume host MCP, browser, credentials or skills transfer to the other CLI. Verify required build capabilities before relying on them.

Present one assumptions ledger with source paths or research links. Ask for corrections to material uncertainties as a batch. Resolve routine reversible choices yourself when the user has authorized the work; silence is not approval of an action requiring approval.

Phase 1 — Settle requirements

Maintain a short visible decision map. Ask only about unresolved decisions that change the outcome. For each consequential question, give the recommendation, why it matters, and the cost of guessing wrong. Batch independent questions; ask dependent ones sequentially. If the code can answer, inspect it instead. Offer “accept all remaining recommendations” when a long decision list would slow the user down.

Respect existing glossary definitions; resolve ambiguous domain language. Maintain glossary-only context lazily using [CONTEXT-FORMAT.md](CONTEXT-FORMAT.md). Record an ADR only for expensive-to-reverse, non-obvious trade-offs using [ADR-FORMAT.md](ADR-FORMAT.md).

Write the resolved `PLAN_FILE` with:

• Goal and observable acceptance criteria.
• Concrete approach, key decisions, trade-offs and non-goals.
• Confirmed assumptions with sources and remaining risks.
• Relevant toolchain requirements per provider, if any.
• Verification: exact proof command(s), expected results, and manual/visual checks when needed. Prove the change on the real output of the program that produces its input, not only on hand-written samples. When code is replaced, run the old and new code on the same inputs and compare.

Derive proof commands from the repository when possible. Ask only when what c