Code Review Skills for AI Coding Agents

Best for: Reviewing a changed branch against repository standards and its originating specification

This skill reviews a three-dot diff from a fixed point you provide, such as a branch, tag, SHA, or merge-base. It validates that the fixed point resolves and that the diff is non-empty before it starts the review.

Two independent subagents then work in parallel: Standards checks the repository's documented conventions, while Spec checks whether the change implements the originating issue or PRD. Their separate contexts keep one review from biasing the other.

• Validated three-dot diff from a fixed point
• Independent Standards and Spec subagents
• Finds the originating spec from repository context
• Fails fast on an invalid or empty review range

Best for: Making ordinary diff review concise without replacing substantive review

The output contract is deliberately narrow: every finding gets a location, a concrete problem, and a concrete fix on one actionable line. Severity labels distinguish bugs, risks, nits, and questions without paragraphs of hedging.

This is a compression layer for review feedback, not a substitute for substantive review. It removes filler praise, restated diffs, and vague suggestions while preserving the reasoning and evidence a real review needs.

• Location, problem, and fix on every finding
• Severity labels for bugs, risks, nits, and questions
• Concrete actions instead of hedged commentary
• Terse format does not replace substantive review

Best for: Applying one broad quality review to a normal code change

The review checks five axes: correctness, readability, architecture, security, and performance. The readability pass asks whether the implementation can be shorter and whether each abstraction earns its complexity.

Its approval bar is code health: approve a change when it definitely improves the overall code health, even if it is imperfect. Do not block a change merely because it differs from the reviewer's preferred style.

• Correctness, readability, architecture, security, and performance
• Code-health approval bar for final judgment
• Checks whether abstractions earn their complexity
• Separates meaningful defects from stylistic preference

Best for: Conditional CI/workflow review of a checked-out pull request

This workflow reads a checked-out pull request from local artifacts—the diff, PR description, and optional specification context—and writes structured findings to review.json for the surrounding workflow to consume.

It validates the review output and deliberately never posts to GitHub directly. Use it when CI owns publication and merge gating; it is not a general interactive reviewer for an arbitrary local diff.

• Runs against checked-out CI and PR artifacts
• Produces validated, machine-readable review.json
• Leaves GitHub posting to the surrounding workflow
• Keeps CI nits and untouched-code concerns scoped

Best for: A conventional review that can switch explicitly between local changes and a remote pull request

Google's code-reviewer starts by choosing the target: a remote PR identified by URL or number, or staged and unstaged local changes. It then gathers the PR description and comments or the local diff before applying its review pillars.

The final output separates Critical findings, improvements, and optional nitpicks before making an Approved or Request Changes recommendation. Use it when target selection and a conventional decision-oriented review are the main contract.

• Explicit local-working-tree and remote-PR target selection
• Prepares context from PR history or staged and unstaged diffs
• Checks correctness, maintainability, efficiency, and edge cases
• Ends with an approval or request-changes decision

Best for: Automated review that needs machine-readable severity, category, path, and line-range findings

open-code-review invokes Alibaba's OCR CLI against staged, unstaged, untracked, commit, or branch-comparison changes. It passes concise business context with --background and uses --audience agent to emit the final review rather than a progress UI.

OCR returns line-level comments with severity and category fields, including optional suggestion code. Its preview mode and explicit workspace, commit, and branch modes make it a tool-backed review pipeline rather than another prose checklist.

• Reviews workspace, commit, or branch-comparison changes
• Passes business context to the OCR CLI
• Returns structured line-level severity and category data
• Supports preview mode before spending model work

Best for: A deliberately demanding review of abstraction quality, codebase health, and growing structural complexity

thermo-nuclear-code-quality-review asks whether a change can be reframed to remove concepts, branches, wrappers, or indirection—not merely tidied in place. It treats giant-file growth, ad-hoc conditionals, cast-heavy boundaries, and scattered special cases as structural review concerns.

Use it only when a high bar for maintainability is useful. Its bias is toward simpler, more direct architecture and it can be intentionally more demanding than a normal approval-oriented diff review.

• Searches for structural simplification instead of cosmetic cleanup
• Flags giant-file growth and spaghetti-condition expansion
• Questions unnecessary wrappers, casts, optionality, and indirection
• Reserved for intentionally strict maintainability audits