Repo-owned successor to the Codex-bundled . That one lives under and is replaced on every Codex update, so edits to it do not survive; this one is canonical in and ships through . The rename is deliberate — two skills named would be indistinguishable at the call site.

Inspect the requested target directly and return every finding that the author would likely fix. Do not modify files, create commits, push branches, post review comments, or delegate the review to another agent.

Reading the diff IS the work. Until the semantic pass over the whole diff is finished and the findings are written down, do not run builds, test suites, linters, formatters, or static analysis. A suite result says nothing about whether this change introduced a defect — it reports what the author's tests already cover — and any failure it does surface will pull the review onto that failure instead of the diff you were asked to read. Measured 2026-08-28: a review that started a full test run 2.4 minutes in made 5 test/analyze calls, never finished the semantic pass, and reported on the wrong thing.

Verification is scoped to findings, not to the repository. Once a finding is written down you may run the narrowest command that reproduces that specific finding — one test, one file, one analyzer path. "Run the whole suite and see what breaks" is not verification; it is a substitute for the review. If the requester explicitly asks for a test run, say what the review still owes before running it, then run it.

Read with ranged reads: to for the changed hunks, and line ranges (, ) for the surrounding code. Never dump a whole source file — a review that has read eight whole files has spent its context on the 95% that did not change, and every later turn re-carries it.

For a base-branch review, compare the changes that would actually merge rather than diffing directly against the branch tip. Resolve the comparison ref to the branch's upstream when that upstream exists and is ahead of the local branch; otherwise use the local branch. Run , then inspect . If the local branch cannot be resolved, try its configured upstream explicitly before reporting that the target is unavailable.

Flag an issue only when all of these are true:

Do not flag speculative concerns, pre-existing problems, intentional behavior changes, or style nits that do not obscure the code.

Present findings first, ordered by severity. Use one entry per issue in this form:

[P1] Imperative finding title — path/to/file.rs:line

Follow the title with one short paragraph explaining the affected scenario and why the behavior is wrong. Keep the cited range as small as possible and make sure it overlaps the reviewed diff.

Use these priorities:

If there are no qualifying findings, say Do not invent a finding to fill the result. After the findings, add a brief overall assessment and mention any material test gaps or residual risks.