---
name: Implement Review
slug: implement-review
category: Quality
description: Implement Review runs a staged-change review loop that detects content type, routes changes to a reviewer, categorizes feedback, revises, and iterates. It is used for code, papers, proposals, and other text outputs, including plan-first reviews for larger tasks.
github: "https://github.com/yzhao062/anywhere-agents/tree/main/skills/implement-review"
language: Python
stars: 241
forks: 26
install: "npx degit https://github.com/yzhao062/anywhere-agents/tree/main/skills/implement-review ~/.claude/skills/implement-review"
installs_to: ~/.claude/skills/implement-review
source_path: skills/implement-review/SKILL.md
collection_size: 5
category_size: 1418
collection_url: "https://dirskills.com/collections/yzhao062/anywhere-agents"
added: 2026-09-02T05:22:02.303Z
last_synced: 2026-09-02T05:22:02.303Z
canonical_url: "https://dirskills.com/skills/implement-review"
---

# Implement Review

Implement Review runs a staged-change review loop that detects content type, routes changes to a reviewer, categorizes feedback, revises, and iterates. It is used for code, papers, proposals, and other text outputs, including plan-first reviews for larger tasks.

**Install:**

```bash
npx degit https://github.com/yzhao062/anywhere-agents/tree/main/skills/implement-review ~/.claude/skills/implement-review
```

## README

# Implement-Review

## Overview

A review loop for staged changes. Claude Code detects the content type, sends the changes to one or more reviewers, categorizes the feedback, revises, and iterates. Codex is the primary reviewer via three channels: terminal relay (manual copy-paste, default on every platform), Auto-terminal (opt-in `codex exec` subprocess dispatch), or IDE plugin. Other reviewers (Copilot, Gemini, Claude Code, etc.) are driven ad-hoc by the user through their own UI and only need to honor the `Review-<AgentName>.md` save contract defined in Phase 1c. **Cross-vendor exception**: when Claude Code is unavailable and Codex (or the user) is the primary implementer, the Auto-terminal channel can dispatch GitHub Copilot CLI as the reviewer through a parallel `dispatch-copilot` backend (opt-in; see Codex Channels > Auto-terminal Copilot backend). Bare `/implement-review auto` is unchanged and still selects Codex.

## When to plan-review first

**Any complex task benefits from a plan review BEFORE execution**, not only writing or code. Plan-first catches architectural holes while they are still cheap to fix. The scope includes: system design, refactors, paper outlines, proposal structure, data-pipeline redesigns, multi-stage debugging strategies, teaching / curriculum planning, release-process changes, migration plans, and anything else where the shape of the work precedes and constrains the execution.

**Plan-review is a Phase 0 before the staged-change loop below.** If the user asks for a plan review, or if the task clearly meets the signals below, do not apply the staged-change prerequisite in Phase 1 yet. Tell the reviewer to read the plan file directly (or paste the plan contents via the terminal path when the reviewer cannot access the file) and critique the design, not `git diff --cached`. After the plan has no High findings and no new design blockers, execute the work and resume the normal staged-output review flow at Prerequisites / Phase 1.

### When to plan-first

Signals that the round-trip pays off:

- **Blast radius is large** -- multiple files, cross-cutting concerns, shared state, multiple stakeholders, or the organizing structure of a deliverable.
- **Irreversible once executed** -- publishes, submissions, deployments, immutable packages, paper submissions, external commitments.
- **History shows a pattern** -- "got the structure wrong, redo next cycle" has happened on this track before.
- **Uncertainty in the approach** -- the user is weighing alternatives and wants the design validated, not the execution reviewed.
- **Context is unfamiliar** -- new codebase, domain, audience, agency, collaborator workflow, or external constraint set, where a wrong assumption can shape the rest of the work.

### When to skip plan-first

- Change is small, local, reversible.
- The design is already worked out and only execution feedback is wanted.
- Plan and execution would be the same artifact (three-line bug fix, one-sentence footnote).

### Process

1. Write the plan to a scratch file `PLAN-<identifier>.md` in the most natural location for the task (repo root for code, paper-repo root for Overleaf-style docs, a local scratch directory beside the deliverable for tasks that do not live in git). If the plan lands inside a git worktree, add it to `.git/info/exclude` so `git add -A` does not accidentally stage it; outside git, keep it as a clearly named scratch file outside the final deliverable and delete it after review.
2. Content varies by task but at minimum include: purpose, non-goals, structure, regression or failure analysis, validation plan, open questions. Keep it terse -- 1 to 3 pages.
3. Send the plan through a plan-review prompt (not the staged-change template). Make clear this is a pre-execution design review and that the plan file path or pasted contents are what the reviewer should read; instruct the reviewer to critique the design rather than to run `git diff --cached`. Use the normal "Save your complete review to Review-<AgentName>.md" save-contract from Phase 1c.
4. **Reviewer must answer the scope-challenge questions** (see "Adversarial scope challenge" below) before any in-scope correctness review.
5. Iterate until the review has no High findings and no new design blockers.
6. Then execute (code, draft, revise, deploy).
7. Run the normal review cycle on the staged output. It is typically smaller because the architecture was already validated.
8. After the work ships or is submitted, delete the PLAN file.

### Adversarial scope challenge (mandatory in plan-review)

Plan-review **must** be adversarial about plan purpose and shape, **not** about low-probability edge cases. The single biggest plan-review failure mode in this maintainer's history was not "the plan had a bug" — it was "the plan's scope was over-conservative, deferring user value across an extra release cycle worth of process tax." Examples:

- Conservative scope (`v0.5.7 = ref bump only; defer compact to v0.6.0`) → the user's real projects would have stayed on large `AGENTS.md` files for another release cycle. The apparent product ask was a one-line bundled manifest flip, but existing-consumer delivery also required bundled-default drift detection in aa plus real-project upgrade tests. The scope challenge should force reviewers to price both parts: user value now, and the smallest code path that actually delivers it.
- Conservative deferrals also defer the validation that proves the next-step works in real consumers, so the next release inherits the same uncertainty plus a longer review chain.

The plan-review prompt must instruct the reviewer to take an explicit position on:

1. **Why this exact scope?** What user pain (or user opportunity) does THIS scope close? Could a strictly smaller scope close most of it? Could a marginally larger scope close all of it for low marginal cost?
2. **Are deferrals justified?** Every "out of scope / deferred to vNext" carries process tax: another full plan-review + implement + execution-review + CI + publish cycle. Quantify the deferral. If the deferred axis is 1 line of code and the user pain is real, the deferral is probably wrong.
3. **Is this plan the simplest path?** Are there simpler approaches the plan didn't consider — including doing nothing if the user pain is hypothetical?

Plan-review must **not** default to "no blocker, ready to implement" on the first round when scope is multi-axis or when the plan defers a user-facing axis. The reviewer must either raise a scope challenge OR explicitly state why the scope is calibrated. Skipping the explicit position on these three questions counts as an incomplete review.

Anti-patterns the reviewer must NOT pursue:

- **Edge-case fishing**: "what if user has unusual config Y?" — only matters when realistic probability × impact > review cost.
- **Process ritual**: "should this also do Z?" without grounding in user pain or opportunity.
- **Adversarial-for-its-own-sake**: rejecting plans whose scope IS calibrated, or proposing scope expansion that adds cost without proportional user benefit.

The Phase 1c prompt template `Scope-challenge focus:` line below carries this contract into every plan-review send.

### Illustrative examples (not exhaustive; the category is less important than the pattern)

- System / code: hook or infra design, cross-cutting refactor, state-file schema, cross-platform behavior, release runbook revisions.
- Research output: paper outline with specific aims, contribution claims before methods is written, figure-placement vs argument flow, reviewer response strategy, experiment design across multiple methods, ablation plan.
- Proposal: full outline (aims alignment with merit-review criteria), budget-narrative coupling, broader-impacts framing.
- Operational: migration plan, incident-response playbook, data-pipeline redesign.
- Administrative / teaching: course syllabus structure, lab policy document, committee process design.

The point is not which category -- it is whether the shape of the work precedes and constrains the execution.

### Empirical note

In the agent-config 0.1.9 release cycle, two plan-review rounds caught a High-severity design flaw before implementation. The later execution-review rounds were limited to documentation and test polish, avoiding a likely post-ship hotfix.

## Codex Channels

Three paths to Codex are supported. Default is Terminal-relay (manual copy-paste). Auto-terminal (`codex exec` subprocess) is opt-in via the trigger rules in Path selection below. Plugin is user-initiated. The skill picks the channel based on those rules.

### Terminal path (default)

The user has a Codex interactive terminal window open alongside Claude Code. Claude Code prepares a copy-pasteable review prompt (summary, diff, lens, round number) and presents it as a fenced text block. The user copies it into the Codex terminal, then relays the feedback back to Claude Code.

### Auto-terminal path (opt-in, codex exec subprocess)

When the user opts in via the trigger rules in Path selection below, Claude Code dispatches Codex via `codex exec --sandbox danger-full-access` as a background subprocess (Bash on POSIX, a transient `<state-dir>/run-codex.cmd` helper invoked through `cmd /c` on Windows; see the Script contract invariants subsection for the rationale). The dispatch script writes the prompt to a per-dispatch temp file under `%TEMP%` / `$TMPDIR`, feeds it on stdin (`codex exec -`), and emits a state-dir path to stdout for Phase 2 to consume. Codex writes its review to `Review-Codex.md` per the save contract; the same Phase 1d auto-watch fires on file appearance.

**Trust model and the sandbox flag**: Auto-terminal aligns its trust model with Terminal-relay by passing `--sandbox danger-full-access` to `codex exec`. In Terminal-relay the user is typing into their own Codex window with full fs / network / shell access; in Auto-terminal Claude Code starts the same Codex on the user's behalf, so granting the same access keeps the two channels behaviorally equivalent. The sandbox flag is also a hard requirement for the channel to work on Windows: Codex 0.130.0's default `workspace-write` sandbox runner hits `CreateProcessAsUserW failed: 1312` when Codex spawns its own git / grep / pwsh subprocesses, which makes the review come back as "could not access files" and surfaces through Phase 2.0 Check 7 / 8 / Substance-2 as a tool-sandbox failure. Scope discipline (review-only, save findings to `Review-Codex.md`, no commits / pushes / branch operations) is enforced at the prompt level, identical to how Terminal-relay enforces it. For CI / shared / multi-tenant environments where this trust posture is too broad, set `CODEX_DISPATCH_SANDBOX` to a stricter mode (`workspace-write` / `read-only`); the dispatch script honors the env var.

The primary Auto-terminal dispatch preserves the byte-identical prompt invariant with Terminal-relay: the assembled prompt bytes are the same regardless of channel. The extra `-c developer_instructions=...` value is a Codex CLI configuration argument, separate from the review prompt on stdin, so it does not change those bytes. The dispatch script must NOT call `codex exec review`, `codex exec review --uncommitted`, or any other Codex `exec` subcommand, because those carry Codex's own built-in review prompt template which would compete with the skill's lens-aware prompts. The embedded-diff retry described below is the explicit exception: it is used only after a health-checked Auto-terminal run shows that Codex's own shell tool cannot inspect the repo, usually because `CODEX_DISPATCH_SANDBOX` has been narrowed in a CI / sandbox-strict environment, but also for the same class of failure if a future Codex version regresses under the relaxed default sandbox.

The Auto-terminal path requires `codex` on PATH. Probe before dispatch; if absent, warn and downgrade to Terminal-relay for the round. On non-zero `codex exec` exit, timeout, or stdin-pipe failure (rare on Windows with PowerShell quirks or Bitdefender input-stream interception), downgrade to Terminal-relay for that round; do NOT add a truncated positional-argument fallback, which would break the prompt invariant. Sticky downgrade applies session-wide once Auto-terminal fails: subsequent rounds default to Terminal-relay until the user re-opts-in explicitly.

**Auto-terminal has no incremental-checkpoint guarantee.** The save contract requires a complete per-round review published atomically, but it does not require intermediate checkpoints. The Codex dispatcher snapshots the prior review mtime and propagates `codex exec`'s exit code, and it does not validate that a fresh review was published. A child that exits 0 without saving therefore leaves `<state-dir>/tail` and no fresh review, which Phase 2 health checks 1 through 3 reject as missing, stale, or wrong-round. That rejection costs a full Codex run.

**Configuration boundary: the dispatched Codex does NOT inherit the user's `config.toml`**. Under the default MCP isolation, the dispatch script passes `--ignore-user-config` and re-passes `-c model_reasoning_effort=$CODEX_DISPATCH_REASONING` (default `xhigh`). Independently of that isolation choice, every dispatch passes a separate `-c developer_instructions=...` argument telling the child reviewer to skip bootstrap and shared configuration refresh commands and to use the configuration already on disk. The child still reads and follows `AGENTS.md`; all other project instructions, including the agent-style banned-word list and any NSF rules, remain in force. Everything else in `~/.codex/config.toml` is dropped for the dispatched run: `model` (so the review runs on Codex's **built-in default model**, not the user's configured one), `service_tier`, `[features].fast_mode`, and any custom provider settings. This is a deliberate consequence of the MCP-isolation fix, not an oversight, but it is easy to misread: a user who has tuned `config.toml` for maximum reasoning will find that none of it reaches their reviews, and the only user-controlled config knob that does is `CODEX_DISPATCH_REASONING`. To raise the dispatched reasoning effort, set that variable rather than editing `config.toml`. To hand the dispatched run the full user config instead, set `CODEX_DISPATCH_ISOLATE_MCP=off`, which is the documented opt-out and also restores the user's MCP servers and plugins.

**Reasoning effort is a one-way ratchet**: `xhigh` is the floor, not a target. The dispatching agent may raise a single round to `max` by passing `CODEX_DISPATCH_REASONING=max` on that dispatch when it judges the change under review hard enough to earn deeper reasoning: changes that span mirrored copies of one file, touch caching or state lifetime, or would fail silently rather than loudly. It must never pass a value below `xhigh`. Raising the tier is not free: it roughly doubles wall-clock, so raise the dispatch timeout in the same step, or the round is killed before it writes anything. The asymmetry is deliberate. An agent choosing how hard to review its own work creates a self-grading loop, and its confidence is highest exactly where a quiet error hides. Its discretion therefore runs upward only, so the worst case is a round that was not deepened rather than one that was weakened.

**Depth against another round**: when the budget would buy either one deeper round or two at the floor, prefer another round while the artifact is still changing. The later round reads the revised state and carries the prior findings with it, so its budget is spent on what the last round actually produced. Raise the tier for the closing round, or when the change is subtle enough that a first read is unlikely to reach it. The relative yield of the two has not been measured, so treat this as a default rather than a finding.

**Python interpreter resolution and the verification contract**: Before it creates dispatch state or spends a Codex round, `dispatch-codex` finds a working Python interpreter in this order: `ANYWHERE_AGENTS_PYTHON`; project `.venv` or `venv`; the activated `VIRTUAL_ENV`; active and discovered conda or Miniforge roots and environments; `py -3`; then every `python3` and `python` entry on PATH. A configured but broken `ANYWHERE_AGENTS_PYTHON` is a hard preflight failure. Every candidate must run an isolated probe, return an absolute `sys.executable`, pass the nonempty-file and non-`WindowsApps` checks, and execute successfully again through the resolved path. The dispatcher writes the absolute path to `<state-dir>/python-interpreter` and includes it in the child `developer_instructions`; the reviewer must use that exact path for Python commands. Resolving nothing at all is a degradation rather than a dispatch failure: the dispatcher warns on stderr, omits the marker file so its absence is unambiguous, tells the reviewer that no interpreter was pre-resolved, and proceeds. The probe exists to keep a reviewer from claiming verification it never ran, and check 10 enforces that independently by refusing a `PASS` or `BLOCK` verdict without a `VERIFIED` status. Reviews also run on repositories whose verification is not Python at all, so a missing interpreter must not make those repositories unreviewable.

**PowerShell `7` (`pwsh`) resolution**: The probe enumerates `PATH` only because Codex's tool router shells out to `pwsh` by name. It rejects a candidate when its path contains `WindowsApps` or when the file has zero length. This is a structural check rather than an execution probe because a Microsoft Store App Execution Alias succeeds from an interactive shell and fails only under the dispatched spawn context, where it dies with NTSTATUS `0xC0000142` (`-1073741502`) in about `30 ms` and is retried indefinitely. The dispatcher writes a resolved absolute path to `<state-dir>/pwsh-interpreter` and names it in the child `developer_instructions`. Finding nothing is a soft degradation that tells the reviewer to prefer bash, Windows PowerShell `5.1` (`powershell.exe`), or plain git, as it does for a missing Python interpreter. The Copilot and Claude reviewer backends pass no developer instructions today, so they carry neither the Python nor the `pwsh` probe; extension to those backends is deferred.

Every saved review must include one standalone `Verification status: VERIFIED` or `Verification status: UNVERIFIED` line. `VERIFIED` is permitted only after at least one relevant verification command completed, and Verification notes must list the exact commands and outcomes. A run with no completed verification uses `Verification status: UNVERIFIED` together with `Commit verdict: UNVERIFIED`; it cannot issue `PASS` or `BLOCK`. Health check 10 rejects an `UNVERIFIED` status or verdict, a `PASS` or `BLOCK` verdict without `VERIFIED`, conflicting markers, and `VERIFIED` paired with notes that explicitly report no execution. A caller can therefore distinguish an execution-backed block from an unsupported one: `PASS check-10 verdict=BLOCK verification=VERIFIED` plus concrete command outcomes is admissible; `FAIL check-10 verdict=BLOCK verification=MISSING` or `FAIL check-10 verdict=BLOCK verification=UNVERIFIED` is a hard intake failure. Review formats that give no commit verdict remain backward compatible in the health check.

**Embedded-diff retry for Codex tool-sandbox failure (sandbox-strict environments only)**: With the default `--sandbox danger-full-access` Codex can inspect the repo directly and this retry path should never fire. The retry exists as a defensive fallback for two cases: (1) `CODEX_DISPATCH_SANDBOX` has been narrowed to `workspace-write` or `read-only` in a CI / shared environment, and Codex hits `windows sandbox: runner error: CreateProcessAsUserW failed: 1312` or a similar internal sandbox error; (2) some future Codex version regresses the same class of failure under the relaxed sandbox. Symptom: dispatch exits 0 and `Review-Codex.md` is fresh, but the review body says Codex could not run `