Immutable. This exact content is served forever at /api/v1/blob/56187d4c80ec652e.
---
name: neo-code-review
description: >
Use this skill when the user asks to review or audit source code, a PR, diff, commit,
or recent changes for bugs, security, performance, tests, compatibility, or
maintainability. Also use it after an AI agent finishes modifying code to inspect the
current uncommitted working tree before handoff and report actionable findings with
file and line evidence.
compatibility: Requires Python 3.11+ and uv for the Git change helper.
---
# Code Review
Use the Reviewer workflow. Keep the review read-only and report only evidence-backed, actionable findings.
## Trigger On
- The user requests a code, PR, diff, commit, security, performance, test, or maintainability review.
- An AI Agent finishes modifying code, tests, configuration, or scripts before handoff.
## Workflow
1. **Collect the review scope**
- Use the files or code snippets supplied by the user as the primary scope.
- If no scope is supplied inside a Git repository, run:
```bash
uv run skills/neo-code-review/scripts/git-diff-reviewer.py --working-tree
```
- Use `--staged` for staged-only changes and `--commit <range>` for a commit range.
- Read surrounding code, related tests, and existing contracts. If no reviewable input exists, report it and stop.
2. **Load the rules**
- Read [review-checklist.md](references/review-checklist.md) before evaluating code.
- Identify the actual language, framework, and affected behavior from the change. Do not infer unverified rules from filenames.
3. **Analyze risk**
- Prioritize correctness, regressions, security, data consistency, resource lifetime, concurrency, and high-risk test gaps.
- `🔴 Critical Issues` contain only security vulnerabilities, data loss, incorrect behavior, authorization bypasses, or major regressions.
- `🟡 Suggestions` contain only actionable, non-blocking issues with a clear impact and remediation direction.
- Do not report preferences, unsupported speculation, or checklist items that were not triggered by evidence.
4. **Produce a concise report**
- Write in English and preserve file paths and line numbers, such as `src/user.ts:42`.
- Use this structure. Write `None` when a section has no findings; do not omit the severity sections:
```markdown
## 🔍 Review Summary
- **Status**: `🟢 Ready to deliver`, `🟡 Fix recommended`, `🔴 Delivery blocked`, or `⚪ No reviewable changes`
- **Scope**: Files or changes that were inspected.
## 🔴 Critical Issues
- **Location**: `path:line`
- **Problem**: Specific behavioral defect.
- **Impact**: Verifiable consequence.
- **Fix**: Concrete remediation direction; include code only when it clarifies the fix.
## 🟡 Suggestions
- **Location**: `path:line`
- **Recommendation**: Specific, non-blocking improvement.
## 🟢 Strengths
- List only strengths directly supported by the change.
## Validation
- List executed tests, builds, or checks that were not run.
```
5. **Apply the delivery gate**
- If an automatic review finds `🔴 Critical Issues`, cannot establish the review scope, or cannot load the skill, do not declare completion or hand off.
- After fixing findings, rerun the required checks and review the changes again.