Review All

Review All - two clean-agent code review

What this does, and why it has this shape

Two independent reviewers examine the same change, then their findings are reconciled. The value is not "two reviews"; it is the agreement signal: when both clean agents independently flag the same issue, confidence is high. When only one flags something, it deserves scrutiny.

Four properties make the signal useful, and the procedure exists to protect them:

1. Clean context per reviewer. Each reviewer must start fresh, with no memory of this orchestration or of each other, or they stop being independent. Spawn two agents with clean context; if the agent API supports a fork_context flag, set it to false. Do not paste either reviewer's output into the other reviewer. 2. Same target. Agreement only means something if both looked at the exact same diff. Resolve the target once and hand the identical base...HEAD range to both. 3. Two complementary review paths. One clean agent runs Codex's native codex review --base "$base" command. The other clean agent performs a direct review using references/review-guide.md, which is based on Google's "What to look for in a code review": https://google.github.io/eng-practices/review/reviewer/looking-for.html 4. Genuine parallelism. Spawn both agents before waiting for either result. Do not serialize the reviews.

This skill is review-only. Never pass --fix / --comment, never apply patches, and never tell the user you are about to change code.

Not a PR-finishing loop

When the user asks to update code until review comments are handled and checks pass, use the pr-finish workflow instead. This skill should be run once after a batched fix, or at most once more after a second batched fix if valid P0-P2 findings remain. Do not rerun review-all after each individual fix.

Procedure

Step 1 — Resolve the shared target (one base, one range)

The target is base...HEAD (merge-base diff of the current branch), so both reviewers see exactly the commits this branch adds.

current=$(git rev-parse --abbrev-ref HEAD)

# Base precedence: user-provided --base > origin's default branch > main > master
base="$ARG_BASE"   # whatever the user passed, may be empty
if [ -z "$base" ]; then
  base=$(git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null \
         | sed 's@^refs/remotes/origin/@@')
fi
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/main   && base=main
[ -z "$base" ] && git show-ref --verify --quiet refs/heads/master && base=master

echo "current=$current base=$base"
git diff --shortstat "$base"...HEAD
git diff --name-only "$base"...HEAD

Step 2 — Pre-flight (fail fast, don't waste a review)

Stop and tell the user plainly if any of these hold:

• Not inside a git repo.
• No base branch could be resolved → ask the user which base to diff against.
• current is the base branch → there is nothing to compare; ask for a base.
• The diff is empty (git diff --shortstat "$base"...HEAD prints nothing) →

there are no committed changes to review. Remind the user this mode reviews committed changes only; if their work is uncommitted, they should commit first.

• Codex is not ready: codex login status does not report a logged-in account.

Report it and offer to run the Google-rubric review alone.

Step 3 - Spawn BOTH clean agents in parallel

Use the agent/subagent facility available in the current environment. Start both review agents before waiting. If the API exposes fork_context, set it to false for each agent. Give each agent only the repo path, resolved base, and its task.

Agent A: Codex review-command agent

Task prompt:

You are a clean-context review-command runner. In the repo at <repo path>,

run Codex's native review command against the committed branch diff:

>

codex review --base <base>

>

This is review-only. Do not pass --fix or --comment, do not post anything

to GitHub, and do not modify files. Return the native command output and, if

possible, a normalized JSON array of findings:

{"file":"...","line":<int or null>,"priority":"P0|P1|P2|P3","category":"design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other","title":"<one line>","description":"<evidence and impact>"}.

If the command finds nothing, return [] after the raw output summary. If the

command fails, return the exact failure and stop.

Agent B: Google-rubric review agent

Read references/review-guide.md next to this SKILL.md, then give the agent this task with the full rubric pasted in:

You are an independent code reviewer with clean context. In the repo at

<repo path>, review only the committed changes in git diff <base>...HEAD.

Apply this review rubric, based on Google's "What to look for in a code

review":

>

<paste the full contents of references/review-guide.md here>

>

Constraints: This is review-only. Do not pass --comment or --fix, do

not post anything to GitHub, and do not modify any files. Use system

context as a lens to judge the changed lines, but anchor every finding to the

diff (a changed line, or something the change should have touched but didn't,

like a missing test). Skip nitpicks a linter, formatter, typechecker, or

compiler would catch.

>

Return your findings to me as a JSON array and nothing else. Each finding:

`{"file": "...", "line": <int or null>, "priority": "P0|P1|P2|P3",

"category": "design|functionality|complexity|tests|naming|comments|consistency|documentation|security|other",

"title": "<one line>", "description": "<why it's a problem, with evidence>"}`.

Assign priority per the rubric's P0–P3 scale. If you find nothing, return

[]. If the change does something notably well, you may add one finding with

priority P3 and category other titled "Good: …".

After both agents have been spawned, wait for their results.

Step 4 — Collect both results

• Await the Google-rubric review agent's JSON.
• Await the Codex review-command agent's raw output and/or normalized JSON.

Parse the native Codex output semantically; don't rely on a rigid regex. What the native reviewer's output often looks like:

• A preamble block (Codex version, workdir, model, and a dump of the diff and

the shell commands it ran) — skip all of it.

• The findings appear after a codex marker as a summary line followed by

Full review comments: and a list of entries shaped like - [P2] <title> — <path>:<start>-<end> with a description paragraph under each. Each entry is one finding.

• The findings block is often printed twice (streamed, then repeated as

the final message). Dedupe — it's the same findings, not new ones.

• Codex already tags each finding [P0]–[P3]; keep those labels as-is —

it's the same scale the Google-rubric reviewer uses, so no remapping is needed.

• Harmless git: warning: confstr() / xcrun_db lines come from the

read-only sandbox; ignore them.

If one side fails (Codex errored, an agent returned nothing usable), continue with whatever you have and say so explicitly in the report — a half review clearly labeled beats a silent gap.

Step 5 — Merge, dedupe, rank

Normalize both sides into the same finding shape, then reconcile:

• Dedupe by same file + overlapping/adjacent lines + same underlying issue

(semantic match, not string match — the two agents will word things differently).

• Tag the source of every finding: both, google, or codex.
• Resolve priority for each merged finding: if both reviewers flagged it but

assigned different priorities, take the higher (more severe) one and note the split.

• Rank primarily by priority (P0 → P3). Within a priority tier, list

findings both agents agree on first — independent agreement is the strongest confidence signal this skill produces.

• Surface disagreement rather than hiding it: if the two agents conflict

on whether something is a bug, show both positions briefly. That tension is often the most useful part of the report.

Step 6 — Present one unified report

Lead with a verdict, then a priority overview table, then findings grouped by priority tier. Tag every finding with its priority, its source (both / google / codex), and its rubric dimension.

## Review-all: <current> vs <base>  (<N> files, +<adds>/-<dels>)

**Verdict:** APPROVE / REQUEST CHANGES / COMMENT
**Overall correctness:** patch is correct / patch is incorrect
Codex review and Google-rubric review examined the same diff independently; <X>
findings agreed.

### Findings overview
| Priority | Count | Where | Summary |
| -------- | ----- | ----- | ------- |
| P0 | <n> | <file:line or —> | <short or "none"> |
| P1 | <n> | … | … |
| P2 | <n> | … | … |
| P3 | <n> | … | … |

### P0      ← show only tiers that have findings
1. [P0] **<title>** — `file:line` · _both_ · functionality
   <merged description>

### P1
...

### P2
...

### P3
...

Derive the verdict from the priorities (same logic the kelos reviewer uses):

• Overall correctness is "patch is incorrect" if there's any P0 or P1

finding; otherwise "patch is correct". Ignore P2/P3 nits for this call.

• REQUEST CHANGES when there's a P0/P1; APPROVE when only P2/P3 (or

nothing); COMMENT when you genuinely need the author's input before deciding.

Keep it tight: no emojis, cite file:line, mark agreed (both) findings clearly since that's the highest-confidence signal, and don't pad single-model findings to look like consensus. If both agents found nothing, say so and stop. A notable strength may be a one-line "Good:" note under the lowest tier — matter-of-fact, not flattery.

Notes & edge cases

• Committed changes only. codex review --base and base...HEAD both ignore

uncommitted/untracked files. If the user wants those reviewed, they must commit first (a future --working-tree mode could cover that case).

• Large diffs. Codex may take a while; that's exactly why it runs in its own

clean agent. Don't kill it early.

• Arguments. Accept an optional base override (e.g. review-all --base develop

or review-all develop). If none is given, auto-resolve per Step 1.

• Don't double-review. Both reviewers must get the identical range; never let

one drift to working-tree and the other to branch scope.

Google review rubric

Apply these dimensions when reviewing the change. Adapted from Google's engineering practices, "What to look for in a code review" (https://google.github.io/eng-practices/review/reviewer/looking-for.html).

The Google-rubric reviewer receives this text. The Codex review-command agent runs Codex's native codex review --base command independently.

How to use context (read this first)

Judge the change against the system as a whole, not the diff in isolation — a change can be locally fine yet degrade overall code health. But context is a lens, not a license: use surrounding and system context to decide whether the changed lines are correct, well-designed, and well-placed. Anchor every finding to a changed line or to something the change should have touched but didn't (e.g. a missing test or doc for new behavior). Do not report pre-existing issues in untouched code that this change neither caused nor was responsible for.

The bar: does this change improve the overall code health of the system, even if it isn't perfect? If yes, it's generally approvable; findings should be things that block that, or that meaningfully raise health if fixed.

Dimensions

• Design — Does the change belong here? Do the interactions between pieces

make sense, and does it integrate well with the rest of the system? Is this the right place for this logic? Flag over-abstraction and premature generality as well as missing structure.

• Functionality — Does the code do what it intends, and is that what's

wanted? Think about edge cases, concurrency, error paths, and the human at the other end (users and future developers reading this). Flag behavior that is correct-looking but wrong.

• Complexity — Could this be simpler? Flag complexity that isn't pulling its

weight: code that can't be understood quickly, or solving for needs that don't yet exist (speculative generality).

• Tests — Are there appropriate automated tests for new/changed behavior?

Are the tests correct, useful, and likely to actually fail when the code breaks? Flag missing coverage for new logic and tests that can't fail.

• Naming — Do names clearly communicate what a thing is or does, without

being needlessly long?

• Comments — Do comments explain why (intent, tradeoffs, non-obvious

constraints) rather than restating what the code does? Flag stale or redundant comments. Note: clarifying-what comments can signal code that should be simplified instead.

• Consistency & style — Does the change follow the project's established

conventions and the surrounding code? Honor the repository's own `CLAUDE.md` / `AGENTS.md` and any stated conventions — a documented convention that the change violates is a real finding. Absent a documented rule, match the surrounding code. Do not invent personal style rules.

• Documentation — If the change alters how the code is built, tested, or

used, were the relevant docs/READMEs updated? Flag user-facing changes that leave docs stale.

Priority labels (P0–P3)

Tag every finding with a priority. Use the same scale the rest of the toolchain uses, so Codex's and the Google-rubric reviewer's labels line up:

• P0 — Drop everything to fix. Blocks release, operations, or major usage.

Reserve for universal issues that don't depend on assumptions about inputs.

• P1 — Urgent. Should be addressed in the next cycle (e.g. a correctness or

security bug that triggers under realistic inputs).

• P2 — Normal. A real issue to fix eventually.
• P3 — Low. Nice to have.

Which issues to flag (noise control)

Flag an issue only if all of these hold:

• It meaningfully impacts correctness, performance, security, or maintainability.
• It is discrete and actionable — not vague or compound.
• It was introduced by this change — do not flag pre-existing issues in

untouched code.

• The author would likely fix it once aware; it doesn't rely on unstated

assumptions about their intent, and any downstream impact is identified, not speculative.

Beyond that: prioritize correctness and design over style; skip what a linter, formatter, typechecker, or compiler would catch (assume CI runs those); skip pedantic nitpicks. If nothing qualifies, report nothing — do not manufacture findings to fill the review. A few well-justified findings beat a long list of maybes.

Good things

If the change does something notably well — a clean solution, a tricky case handled, good tests, a real cleanup — say so briefly. It's signal, not flattery, and it tells the author what to keep doing.