Code Reviewer Skill

Review Workflow

Follow this sequence for every review:

1. Determine scope — identify which files and changes to review
2. Gather context — understand the codebase, architecture, and purpose of the changes
3. Review the code — apply review criteria
4. Check SonarQube — if the SonarQube MCP server is available, run analysis and incorporate findings
5. Produce the review — output a structured review with categorized findings

Step 1: Determine Scope

Identify what to review based on the user's request:

• If a file or directory is specified: Review that file or all source files in the directory.
• If "my changes" or similar: Run git diff (unstaged), git diff --cached (staged), or git diff main...HEAD (branch changes) to identify modified files.
• If a PR number is given: Use gh pr diff <number> to get the changes.
• If a branch is specified: Use git diff main...<branch> to get the diff.
• If no argument: Run git diff and git diff --cached to review all uncommitted changes.

Always read the full file content for each changed file to understand context around the diff, not just the changed lines.

Step 2: Gather Context

Read the full file for each changed file, not just the diff. Check for existing tests and follow established codebase conventions.

Verify Library and Framework Usage

The model's training data has a knowledge cutoff. When reviewing code that uses libraries or frameworks, actively verify that APIs, patterns, and configurations are current:

1. Identify versions — Check pom.xml, build.gradle.kts, package.json, or other dependency files to determine the exact versions of libraries and frameworks in use.
2. Look up current documentation — Use Context7 (mcp__claude_ai_Context7__resolve-library-id then mcp__claude_ai_Context7__query-docs) to retrieve up-to-date documentation for any library or framework where:
   • The version is newer than what the model may have been trained on
   • You are unsure whether an API, configuration property, or pattern is still valid or has been deprecated/replaced
   • The code uses advanced or less common features of a library
3. Search the web — Use WebSearch and WebFetch to check for:
   • Breaking changes or migration guides for the specific version in use
   • Known security vulnerabilities (CVEs) in the dependency versions
   • Deprecated APIs that have been replaced in newer versions
4. Check GitHub — Use gh CLI to check release notes, changelogs, or issues for dependencies when needed (e.g., gh api repos/{owner}/{repo}/releases/latest)

Do not assume that an API or pattern is correct based solely on model knowledge. When in doubt, look it up.

Step 3: Review the Code

Enforce these testing requirements:

• Is the code on track for >= 80% code coverage? Flag any changed or new code that lacks sufficient test coverage.
• Integration tests should use Testcontainers to spin up real dependencies (databases, message brokers, caches) rather than mocking infrastructure. Flag integration tests that mock infrastructure components that could use Testcontainers instead.
• Always use Docker images with a specific version tag in Testcontainers, never latest.

Step 4: Check SonarQube

If SonarQube MCP tools are available, use them to augment the review:

1. List available tools — check for mcp__sonarqube__* tools
2. Search for issues — query SonarQube for issues on the project or specific files being reviewed
3. Categorize findings — incorporate SonarQube issues (bugs, vulnerabilities, code smells, security hotspots) into the review under the appropriate category
4. Prioritize — highlight any critical or blocker severity issues from SonarQube prominently

If SonarQube MCP tools are not available, skip this step silently — do not mention SonarQube is unavailable.

Step 5: Produce the Review

Output a structured review using this format:

## Code Review: [brief description of what was reviewed]

### Summary
[1-3 sentence overview of the changes and overall quality assessment]

### Critical Issues
[Issues that must be fixed — bugs, security vulnerabilities, data loss risks]
Each issue:
- **File:line** — Description of the issue
  - Suggested fix or approach

### Warnings
[Issues that should likely be fixed — performance problems, design concerns, potential bugs]
Each issue:
- **File:line** — Description of the issue
  - Suggested fix or approach

### Suggestions
[Optional improvements — readability, minor refactors, testing gaps]
Each issue:
- **File:line** — Description of the issue
  - Suggested fix or approach

### What Looks Good
[2-3 positive observations about the code — good patterns, thorough testing, clean design]

Review Output Rules

• Suggest fixes. Provide concrete code suggestions for non-trivial issues.
• Be proportional. A 5-line change doesn't need 50 findings. Focus on what matters.
• Skip the obvious. Don't flag style/formatting issues that a linter should catch, unless they indicate a real problem.
• Omit empty sections. If there are no critical issues, don't include that section.