Code Review Process
The Code Reviewer agent performs systematic reviews of code changes, catching bugs, security issues, and quality problems before they reach production.
Review workflow
Step 1: Understand the change
The agent starts by running git diff or git diff --staged to see the full set of changes. It reads the entire diff before making any comments, ensuring findings are considered in context.
Step 2: Read surrounding context
For each changed file, the agent uses Read to examine the surrounding code -- the containing function, class, and module. Changes cannot be properly evaluated in isolation.
Step 3: Check related code
The agent uses Grep and Glob to find:
- Callers -- Functions that call the changed code. A signature change could break them.
- Tests -- Existing test files that cover the changed functionality.
- Similar patterns -- Other places in the codebase that follow the same pattern, to check for consistency.
Step 4: Apply the checklist
The agent works through a structured checklist covering seven areas:
- Correctness -- Does the code work? Edge cases, off-by-one errors, null handling.
- Naming and clarity -- Are names descriptive? Is the code self-documenting?
- Duplication -- Does this repeat existing functionality?
- Error handling -- Are exceptions caught at the right level? Is cleanup guaranteed?
- Security -- Input validation, SQL injection, secrets exposure, path traversal.
- Tests -- Do tests exist? Do they cover happy path and error cases?
- Performance -- N+1 queries, unnecessary allocations, blocking in async paths.
Step 5: Write the review
Findings are organized into three priority levels:
| Level |
Meaning |
Example |
| Critical |
Must fix before merge |
Bugs, security vulnerabilities, data loss |
| Warning |
Should fix, not blocking |
Missing error handling, no tests, performance |
| Suggestion |
Optional improvement |
Better naming, refactoring opportunity, style |
Each finding includes the file, line number, a description of the problem, an explanation of why it matters, and a suggested fix with code when possible.
Principles
- Focus on the diff -- Review what changed, not the entire codebase. Pre-existing issues are only mentioned if directly related to the change.
- Be specific -- Always reference exact file and line. Show the problematic snippet.
- Suggest fixes -- Do not just identify problems. Show what the correct code looks like.
- Explain the impact -- "This will cause X when Y happens" is more useful than "This is wrong."
- One complete pass -- Deliver all findings at once rather than dripping comments.
- Respect existing style -- Follow the project's conventions rather than imposing personal preferences.
- Acknowledge good work -- Call out clean, well-structured, or particularly elegant implementations.
1---2name: review-process3description: How the Code Reviewer agent conducts systematic code reviews with prioritized findings4license: Apache-2.05---67# Code Review Process89The Code Reviewer agent performs systematic reviews of code changes, catching bugs, security issues, and quality problems before they reach production.1011## Review workflow1213### Step 1: Understand the change1415The agent starts by running `git diff` or `git diff --staged` to see the full set of changes. It reads the entire diff before making any comments, ensuring findings are considered in context.1617### Step 2: Read surrounding context1819For each changed file, the agent uses Read to examine the surrounding code -- the containing function, class, and module. Changes cannot be properly evaluated in isolation.2021### Step 3: Check related code2223The agent uses Grep and Glob to find:2425- **Callers** -- Functions that call the changed code. A signature change could break them.26- **Tests** -- Existing test files that cover the changed functionality.27- **Similar patterns** -- Other places in the codebase that follow the same pattern, to check for consistency.2829### Step 4: Apply the checklist3031The agent works through a structured checklist covering seven areas:32331. **Correctness** -- Does the code work? Edge cases, off-by-one errors, null handling.342. **Naming and clarity** -- Are names descriptive? Is the code self-documenting?353. **Duplication** -- Does this repeat existing functionality?364. **Error handling** -- Are exceptions caught at the right level? Is cleanup guaranteed?375. **Security** -- Input validation, SQL injection, secrets exposure, path traversal.386. **Tests** -- Do tests exist? Do they cover happy path and error cases?397. **Performance** -- N+1 queries, unnecessary allocations, blocking in async paths.4041### Step 5: Write the review4243Findings are organized into three priority levels:4445| Level | Meaning | Example |46|-------|---------|---------|47| **Critical** | Must fix before merge | Bugs, security vulnerabilities, data loss |48| **Warning** | Should fix, not blocking | Missing error handling, no tests, performance |49| **Suggestion** | Optional improvement | Better naming, refactoring opportunity, style |5051Each finding includes the file, line number, a description of the problem, an explanation of why it matters, and a suggested fix with code when possible.5253## Principles5455- **Focus on the diff** -- Review what changed, not the entire codebase. Pre-existing issues are only mentioned if directly related to the change.56- **Be specific** -- Always reference exact file and line. Show the problematic snippet.57- **Suggest fixes** -- Do not just identify problems. Show what the correct code looks like.58- **Explain the impact** -- "This will cause X when Y happens" is more useful than "This is wrong."59- **One complete pass** -- Deliver all findings at once rather than dripping comments.60- **Respect existing style** -- Follow the project's conventions rather than imposing personal preferences.61- **Acknowledge good work** -- Call out clean, well-structured, or particularly elegant implementations.
ag2ai