菜单
Review code following Google's engineering practices. Use when reviewing pull requests, evaluating code quality, or when asked to review changes using Google's standards.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | google-review |
| description | Review code following Google's engineering practices. Use when reviewing pull requests, evaluating code quality, or when asked to review changes using Google's standards. |
| disable-model-invocation | false |
| allowed-tools | Read, Grep, Glob, Bash(git *), AskUserQuestion |
| argument-hint | ["branch or files"] |
Conduct thorough first-pass code reviews following Google's engineering practices and principles. This review produces a complete written assessment; any follow-up discussion happens separately.
This skill is based on Google's Engineering Practices Documentation:
Before starting, determine what to review and gather context.
# Check if we're in a git repo
git rev-parse --git-dir 2>/dev/null && echo "Git repo: yes" || echo "Git repo: no"
# Check current branch
git branch --show-current 2>/dev/null
# Check for uncommitted changes
git status --short
# Check for a default branch
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
Based on the invocation and context, identify what needs review:
$ARGUMENTS contains a branch name)# Check changes on the specified branch vs default branch
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
git diff $DEFAULT_BRANCH...$ARGUMENTS --stat
Infer what to review:
# Check for changes against the default branch
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
git diff $DEFAULT_BRANCH...HEAD --stat
Decision logic:
If $ARGUMENTS contains file paths, review those specific files.
No git context and no inline code: nothing to review, stop.
Once you know what to review, gather the necessary information:
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
# Changes since branching
git diff $DEFAULT_BRANCH...HEAD --stat
# Full diff
git diff $DEFAULT_BRANCH...HEAD
# Commit messages for context
git log $DEFAULT_BRANCH..HEAD --oneline
# Staged and unstaged changes
git diff HEAD --stat
git diff HEAD
# If files are specified, check for changes
git diff $FILE_PATH
# Or read the current file state
# Use Read tool for specific files
Begin the review output with a scope summary so the reader knows exactly what was reviewed:
## Review Scope
- **Branch**: feature/new-feature (8 commits ahead of main)
- **Files changed**: 5 files, +200/-50 lines
- **Reviewing**: branch changes against main
Include a note about any missing context (e.g., "No commit messages describe intent, reviewing code directly").
First, evaluate whether this change should happen at all:
git diff --stat to understand the scopeIf the change shouldn't happen or needs major redesign, say so clearly and why. Still complete the review of what exists.
Focus on the most significant files first:
Review all remaining files thoroughly:
Review every change against these categories (see checklist.md for details):
After completing the analysis but before writing the file, identify findings where the correct suggestion depends on intent or context you cannot determine from the code alone. For each such finding, use AskUserQuestion to ask one focused question at a time and wait for the answer before proceeding to the next.
Ask when:
Do not ask when:
Use each answer to write a concrete suggestion before moving to the next question. Do not write the file until all clarifications are complete.
Write the review to a new file named review_{context}.md in the current directory, where {context} is derived from the branch name (e.g., feature/add-auth -> review_add-auth.md) or, for uncommitted/file reviews, a short descriptor of what's being reviewed (e.g., review_auth-login.md). Never overwrite an existing file; append a numeric suffix (_2, _3) if needed.
Every finding — in any section — must use this exact format inline, no exceptions:
**[Severity]** `path/to/file.ts:42`
```language
// the problematic lines exactly as they appear in the file
```
```language
// concrete suggested replacement; omit this block only if no specific fix is possible
```
Why: one sentence explaining the problem or benefit.
Structure the file as:
## Review Scope
[branch, commits ahead, files changed; note any missing context]
## Summary
[2-3 sentences: what the change does, overall assessment]
## Blocking Issues
[Each finding in the format above. Omit section if none.]
## Design Feedback
[Each finding in the format above. Omit section if none.]
## Code Quality
[Each finding in the format above, grouped by file.]
## Suggestions
[Each finding in the format above, prefixed "Nit:".]
## Positives
[Specific callouts with file:line refs where relevant.]
When in doubt: will this matter in 6 months? If yes, blocking or should-fix. If no, nit or skip.
(See principles.md for detail.)
Match review depth to what's available:
# Review current branch changes
/google-review
# Review a specific branch
/google-review feature/auth-system
# Review specific files
/google-review src/auth/login.ts src/auth/session.ts