Usage - OpenClaude Loop - openclaude-loop

Quick start

/openclaude-loop:openclaude-loop

Then say what you want:

Implement password reset for this project.

What happens:

Claude recon            reads your code, tests and conventions first
   ↓
requirements            asks only what the repo cannot answer
   ↓
PLAN.md                 objective, scope, non-goals, acceptance criteria, proof
   ↓
OpenCode review         read-only, adversarial → REVISE + concrete findings
   ↓
Claude revision         accepts or rejects each finding, with reasons
   ↺ same session       the reviewer checks its own findings were fixed
   ↓
OpenCode APPROVED       bound to the plan's SHA256
   ↓
Claude build            implements the approved plan
   ↓
proof                   Claude runs the command; exit code recorded
   ↓
fresh OpenCode session  independent inspection of the actual diff
   ↓
you approve the diff

Asking for a plan does not authorize a build, and running the loop never implies permission to commit or push.

Commands

/openclaude-loop:openclaude-loop     the full loop
/openclaude-loop:opencode-review     you already have a plan; just stress-test it
/openclaude-loop:opencode-build      hand a frozen spec to OpenCode; Claude inspects

Plain language works too: "openclaude this feature", "openclaude this plan", "review this plan with opencode", "build this with opencode and have claude review it".

Claude reads the repository before asking anything: relevant code, callers and writers of shared state, dependencies, docs, conventions, tests and CI. You get one assumptions ledger with a source per entry.

Phase 1 — Requirements

Only decisions that materially change the result, each with a recommendation, why it matters, and what breaks if the guess is wrong. Then PLAN.md: objective, scope, non-goals, architecture, affected files, sequence, edge cases, migrations, security considerations, acceptance criteria and exact proof commands.

Phase 2 — Plan review

OpenCode hunts incorrect assumptions, missing requirements, architecture problems, data-corruption and security risks, races, migration risks, incomplete error handling, missing authorization checks, compatibility breaks, wrong framework assumptions, tests that would not prove the requirement, unverifiable acceptance criteria, and steps that conflict with the codebase.

APPROVED — no unresolved high or medium findings, bound to the plan hash.
REVISE — Claude arbitrates each finding on evidence, logs accepted and rejected ones with reasons, updates the plan, and resumes the same session.
BLOCKED — required evidence could not be inspected. Never approval.

Phase 3 — Build, proof, cross-inspection

The builder implements; Claude runs the proof itself; the other agent inspects. Fixes applied after an inspection are re-inspected in another fresh session before anything is called final.

Review sessions

OpenCode session ids look like ses_… — not UUIDs. The runner records the exact id and resumes with --session. It never uses --continue, which resumes whatever ran last and could attach a reviewer to a build session.

Plan review creates one session and resumes that same id for every revision round, so the reviewer remembers its own findings.
Final inspection always starts fresh; --resume is refused. The session that argued for the plan is not an independent reader of the code.
Resuming requires a successful previous result with the same repo, plan, mode, model and variant. If OpenCode returns a different session id than requested, the result is refused.

Build sessions

A delegated build creates its own session and resumes that same id for bounded fix rounds — never a new builder context. The clean-checkout gate applies to the first round only; a resumed round must run against the same recorded baseline, and the runner refuses if the checkout changed underneath it.

Artifacts written per run: result.json, prompt.txt, command.json, opencode-config.json, stdout.txt, stderr.txt, session-export.json and response.txt.

OpenClaude Loop