Delegate to Codex with a binding independent judge

praetor is a Claude Code plugin that runs a plan → freeze acceptance bar → dispatch → independent fresh-context judge → resolve loop. Claude plans and judges, Codex executes; a FAIL from the judge cannot be overridden, with at most 2 retries before a loud takeover.

prompt
→ Claude
Plan the task and freeze the acceptance criteria in .codex/ACCEPTANCE.md before any work begins. Isolate on a throwaway branch, write a self-contained brief, then dispatch execution to Codex. When Codex finishes, spawn a fresh-context independent judge that runs every check in the frozen bar against the uncommitted working tree and returns a binding PASS or FAIL — a FAIL cannot be overridden. The judge never fixes anything and commits nothing; it touches manifest paths only. Resolve with at most 2 retries; on continued failure, hand back with a loud takeover. Commit only after the judge passes, then clean up and write the ledger. Iron laws: frozen bar before dispatch, binding judge, max 2 retries then loud takeover.
claude-code

Use this when

You want to delegate a well-scoped implementation task to Codex but refuse to trust self-reported success — the merge should only land if an independent judge confirms the frozen acceptance criteria actually pass.

How it runs

  1. Plan the task and freeze the acceptance criteria in .codex/ACCEPTANCE.md before any work begins.
  2. Isolate on a throwaway branch and write a self-contained brief for Codex.
  3. Dispatch execution to Codex.
  4. Spawn a fresh-context independent judge that runs the frozen checks against the uncommitted working tree.
  5. On PASS, commit and clean up; on FAIL, retry (max 2) then hand back with a loud takeover.

Done when

A fresh-context judge runs every check in .codex/ACCEPTANCE.md against the uncommitted working tree and returns PASS; a FAIL blocks the merge and cannot be overridden.

Why it works

Self-reported success is not success. A binding, fresh-context judge that never sees the planner's reasoning and cannot be talked out of a FAIL turns "the code looks right" into "the checks actually pass" — the gate is the product.

Implementation note

Three iron laws are product law: frozen acceptance bar before dispatch; binding judge (FAIL cannot be overridden); max 2 retries then loud takeover. Consent model is announce-then-act with a plain-language veto and a STOP file.

Source: luoxianzi/praetorgraded B · 80/100 — how grades work →

More automation loops

claude-progress.txt harness pattern (Anthropic)

Loop/ralph★ AnthropicA

Anthropic's first-party file-as-memory harness for long-running agents: every fresh-context session recovers state from a progress file and the git log, does one unit of work, updates the file, commits, and exits.

prompt
→ Claude
Long-running agent harness: each fresh-context session starts by reading `claude-progress.txt` + git log to recover state, does one unit of work, updates the progress file, commits, exits. Initializer session sets up the file; coder sessions loop. Guardrails: Stop when the goal is verifiably met, or stop after 15 iterations, whichever comes first. Verify each pass by running the relevant tests or checks — self-reported success does not count. Keep changes minimal and never touch files outside the task’s scope.

Run an autonomous dev team across GitHub repos (looper)

Loop/ralphcommunityB

Runs Claude Code/Codex as an autonomous multi-role dev team — planner → reviewer ↔ fixer → worker — across all of a user's GitHub repos, entirely driven by issue labels. Each loop runs in its own git worktree so multiple repos/issues proceed in parallel without collisions.

prompt
→ Claude
Register a repo with looper, then label an issue `looper:plan` and assign it to yourself. The planner reads the issue, explores the repo, drafts a spec, critiques and revises it, and opens a spec PR labeled `looper:spec-reviewing`. A reviewer re-reads the PR on every commit and posts inline review threads; a fixer pulls those threads, addresses them in its own worktree, and pushes, ping-ponging with the reviewer until every thread is resolved. Once labeled `looper:spec-ready`, a worker implements the spec, runs checks, and iterates on its own output until checks pass and the PR is ready for human review and merge. Every phase transition is gated on a GitHub label via `looperd`, so a human can pause or take over at any boundary.
automationmedium riskclaude-code

Auto-complete TODOs, keep tests green

Loop/loopcommunityCnew

Work through unfinished TODOs in progress.md, implement each, run tests/lint/build, and continue until the backlog is done.

prompt
→ Claude
/loop 0s --name dev --ask-never --safe --no-overlap --batch 5 --compact-every 200m --checkpoint-only --progress-file progress.md Treat progress.md as the project state. Continue with the next unfinished TODO, implement it, mark completed items, add useful follow-up TODOs, run tests/lint/build when available, and keep going while work remains
automationmedium riskclaude-code