name: google-code-review
description: Load this skill when the user asks to review code, a PR, a diff, a changelist (CL), or requests a code review. Trigger words include: review, PR review, pull request review, diff review, code review, CL review, LGTM, look at this code.
Google Engineering Code Review Skill
This skill implements the Google Engineering Code Review standard as documented
at https://google.github.io/eng-practices/review/reviewer/. It provides a
structured framework for evaluating code changes across seven distinct angles.
Angle Files
Each angle file contains concrete, actionable rules derived from the Google
Engineering practices. The seven angles are:
| Angle | File | Covers |
|---|
| Design | angles/design.md | Architecture, system integration, placement of code |
| Functionality | angles/functionality.md | Correctness, edge cases, concurrency, user impact |
| Complexity | angles/complexity.md | Readability, over-engineering, function/class size |
| Tests | angles/tests.md | Test presence, correctness, quality, and simplicity |
| Naming, Comments & Style | angles/naming-comments-style.md | Identifiers, inline comments, style guide adherence |
| Documentation | angles/documentation.md | READMEs, guides, deprecation notices |
| Context & Health | angles/context-health.md | Whole-file context, code health trajectory |
How to Use This Skill
When this skill is invoked by a subagent, the subagent's prompt will specify
WHICH angle file to focus on. Load and apply ONLY that angle's rules — do not
apply rules from other angle files. This keeps each reviewer's output focused
and non-overlapping.
Output Format
Every finding must include all three of these fields:
- Severity: One of
Blocking, Nit, or Positive
Blocking — must be resolved before approval
Nit — optional polish, author may ignore
Positive — acknowledge something done well
- Location: File name and line number(s) if known; otherwise describe the
area of the change
- Explanation: The why behind the finding — not just what is wrong, but
why it matters for code health, maintainability, or correctness
End every angle review with a brief ## Angle Assessment paragraph (2–4
sentences) summarizing what you found and whether this angle raises any
blockers.