Code Review

Systematic code review skill with layered checklists. Produces consistent, actionable feedback across all review types.

When to Use

• Reviewing pull requests or merge requests
• Conducting architecture reviews
• Auditing code for security, performance, or quality
• Pre-merge quality gates

When NOT to Use

• Writing new code (use /feature-dev or /bugfix instead)
• Validating AI asset files (use asset-validation skill)
• Running automated checks before commit (use /pre-commit)

Review Process

0. Gather Context

Read AGENTS.md at the project root to identify:

• Tech stack (determines which language-specific patterns to check)
• Code conventions (naming, structure, formatting rules)
• Architecture patterns in use (helps evaluate structural decisions)

1. Understand the Change

Before reviewing code, answer:

• What is being changed? (feature, bugfix, refactor, dependency update)
• Why is it being changed? (linked issue, PRD, bug report)
• Scope: How many files, which modules, what's the blast radius?

2. Apply Checklists

Use the appropriate checklist(s) based on change type:

Change Type	Checklists to Apply
New feature	review-checklist.md + security-checklist.md
Bug fix	review-checklist.md (focus: root cause, regression test)
Refactor	review-checklist.md (focus: behavior preservation, tests)
API change	review-checklist.md + security-checklist.md
Infrastructure	security-checklist.md
Dependencies	security-checklist.md (focus: supply chain)

3. Provide Feedback

Structure review comments as:

## Review Summary

**Verdict**: APPROVE | REQUEST_CHANGES | COMMENT

### Critical (must fix before merge)
- [ ] [file:line] Description — why it matters

### Suggestions (should fix, not blocking)
- [ ] [file:line] Description — improvement rationale

### Nits (optional, style/preferences)
- [ ] [file:line] Description

Rules:

• Every critical finding must explain why it's a problem and how to fix it
• Link to relevant documentation or standards when applicable
• Acknowledge good patterns — reinforce what works well
• Never approve code with known critical issues
• Flag missing tests for new logic paths

Integration

• Follows rules: Agent(software-engineer) (architecture, code quality)
• Used by workflows: /code-review, /create-pr
• Companion checklists: review-checklist.md, security-checklist.md