Review a specified code change without editing files. Checks the full diff, surrounding code, tests, and callers to identify actionable defects introduced by the change, then reports findings by severity with file and line references.
Perform a read-only, defect-first review of a specified code change and return every actionable finding. Use when another agent delegates review of uncommitted changes, a base-branch diff, a commit, or custom review instructions.
Review the instructions the agent will receive before you install.
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.
AGENTS.md instructions.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
git merge-base HEAD <comparison-ref>, then inspect git diff <merge-base-sha>. 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:
P0: universal release blocker or critical failure.P1: urgent defect that should be fixed next.P2: ordinary defect that should be fixed.P3: low-impact issue that is still worth fixing.If there are no qualifying findings, say No findings. 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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Monitor a GitHub pull request for review feedback, automated check failures, and merge readiness. Diagnose failures, fix problems caused by the branch, and retry likely temporary failures while continuing to watch for updates.
Review external integration points for breaking changes that could disrupt existing use. Examine app-server APIs, command-line parameters, configuration loading, and session resumption from saved records, continuing beyond the first issue to cover possible failure paths.
Run a final pull request review using separate agents for each available review skill. Collect all reported issues into a numbered Markdown list, with a specific file path and line number for every finding.
Assess whether a code change is small enough to review using line-count guidance. For larger changes, examine the actual differences, dependencies, and calling code to suggest reviewable stages and the smallest coherent first step.
Review code that manages the conversation history and extra information sent to Codex models. Apply rules for incremental history, size limits, cache stability, manual review of large additions, and required implementation structures.
Plan and write tests for changes to agent behavior, favoring integration tests that check components together. Identify key logic changes and user-visible behavior to cover, reuse existing helpers, and keep unit tests in dedicated files.