Code Review

Perform a strict, evidence-based review. Prioritize defects, regressions, security risks, data risks, and missing tests. Do not edit product code unless the user explicitly asks for fixes.

Privacy Rules

• Treat the repository as private. Do not expose secrets, credentials, tokens, private keys, cookies, internal URLs, production hosts, real phone numbers, personal identifiers, customer names, or absolute local paths in final user-facing text.
• Redact sensitive values as , , , , , or .
• Prefer relative file paths and line numbers for evidence. If a path or symbol itself reveals sensitive business information, use a stable alias and explain that names were redacted.
• Never copy large config values, SQL data dumps, certificates, private endpoints, or sample personal data into the report.
• Before publishing or sharing the skill itself, scan the skill package for project names, company names, absolute paths, emails, URLs, phone numbers, tokens, and credentials.

Workflow

1. Ask whether the user has a PRD, issue link, acceptance criteria, or short business goal. If none is provided, continue and mark the review as limited by missing requirements.
2. Inspect repository state:

git status --short --branch
git branch --show-current
git log --oneline --decorate -10

1. Choose the comparison base:

git diff --name-status origin/master...HEAD
git diff --name-status master...HEAD

Use origin/master...HEAD when available, otherwise use master...HEAD. Record the selected base in the report.

1. Build the coverage list:

git diff --name-status <base>...HEAD
git diff --stat <base>...HEAD
git diff --unified=80 <base>...HEAD

If the full diff is too large or truncated, review per file:

git diff --unified=80 <base>...HEAD -- <file>

1. If the user asks to include uncommitted work, or if committed branch diff is empty but the workspace has changes, review the workspace diff too:

git diff --name-status
git diff --stat
git diff --unified=80

1. Read surrounding code when needed. Use rg to find definitions, call sites, configuration keys, mapper SQL, tests, and related behavior.
2. Verify lightweight checks when feasible:

git diff --check <base>...HEAD

Run focused build or tests only when the project makes the relevant command clear and the command is safe in the local environment.

Review Focus

Check every changed file and hunk for:

• Business correctness and requirement fit.
• Boundary conditions, null handling, type conversion, precision, time zone, encoding, and idempotency.
• Transaction consistency, partial success handling, retries, and concurrency.
• Authentication, authorization, injection, path traversal, unsafe deserialization, sensitive logging, and unsafe defaults.
• Data integrity, duplicate data, dirty data, migration compatibility, and rollback risks.
• Performance risks such as N+1 queries, unbounded loops, large object loading, memory growth, and blocking calls.
• API compatibility, serialization changes, backward compatibility, and configuration compatibility.
• Test coverage for happy paths, error paths, edge cases, and regressions.

Pay extra attention to catch blocks that only log and continue, finally blocks with irreversible side effects, batch jobs with partial failures, payment/order/accounting/refund flows, scheduled or retry jobs, and file upload/download/encryption/decompression code.

Report

Create a Markdown report named code-review-report-YYYYMMDD-HHmm.md in the repository root unless the user asks for inline-only output.

Use this structure:

# Code Review Report

**Branch:** {branch}
**Base:** {base}
**Range:** {base}...HEAD
**Reviewed at:** {timestamp}
**Changed files:** {count}
**Conclusion:** {Pass / Conditional pass / Do not merge}

## 1. Requirement Context
- Source: {provided / not provided}
- Goal: {summary or "not provided"}
- Limitation: {state uncertainty when requirements are missing}

## 2. Overall Assessment
- Overall: {score}/10
- Correctness: {score}/10
- Security: {score}/10
- Reliability: {score}/10
- Maintainability: {score}/10
- Tests: {score}/10

## 3. Scope
| Status | File |
| --- | --- |
| M | path/to/file.ext |

## 4. Findings
### {Severity}-{number}: {title}
- Severity: Critical / Major / Minor / Suggestion
- Location: `path/to/file.ext:Lx`
- Problem: ...
- Impact: ...
- Trigger: ...
- Recommendation: ...

## 5. Test Recommendations
- ...

## 6. Verification
| Command | Result | Notes |
| --- | --- | --- |
| `git diff --check ...` | pass/fail/not run | ... |

## 7. Uncommitted Changes
- State whether uncommitted and untracked files were reviewed, ignored, or only listed.

## 8. Coverage Log
### path/to/file.ext
- Hunks reviewed: {count}
- Changed lines covered: yes/no
- Notes: ...

Severity definitions:

• Critical: production outage, data loss/corruption, security vulnerability, or core flow unavailable.
• Major: clear business bug, broken error path, compatibility break, or reliability problem.
• Minor: maintainability, localized performance, logging, or test gap.
• Suggestion: improvement that should not block merge.

Final response to the user must summarize the report path, highest-risk findings, verification status, and whether merge is recommended. If no blocking issues are found, say that explicitly and mention residual risk.