Code Review

Overview

Review code for security, correctness, and quality. Runs in isolated code-reviewer context with pre-loaded standards.

Announce at start: "I'm using the code-review skill to validate [files/feature]."

The Process

Step 1: Pre-Load Context (Main Agent)

Load standards BEFORE invoking review:

Read: .opencode/context/core/standards/code-quality.md
Read: .opencode/context/core/standards/security-patterns.md

Step 2: Invoke Review

/code-review path/to/file.ts
/code-review src/auth/*.ts
/code-review $(git diff --name-only HEAD~1)

Step 3: Analyze Report

Code-reviewer returns structured findings:

## Code Review: Auth Service

### 🔴 CRITICAL (Must Fix)
1. **SQL Injection Risk** — src/db/query.ts:42
   - Problem: Unparameterized query with user input
   - Risk: Database compromise
   - Fix:
     ```diff
     - db.query(`SELECT * FROM users WHERE id = ${userId}`)
     + db.query('SELECT * FROM users WHERE id = ?', [userId])
     ```

### 🟠 HIGH (Correctness)
2. **Missing Error Handling** — src/auth/service.ts:28
   - Problem: Async function without try/catch
   - Risk: Unhandled promise rejection
   - Fix: Wrap in try/catch with proper logging

### 🟡 MEDIUM (Style)
3. **Naming Convention** — src/auth/middleware.ts:15
   - Problem: snake_case instead of camelCase
   - Fix: Rename verify_token → verifyToken

### Summary
Total Issues: 3 (1 Critical, 1 High, 1 Medium)
Recommendation: REQUEST CHANGES

Step 4: Take Action

If CRITICAL or HIGH issues:

1. STOP—do not commit
2. Fix issues using suggested diffs
3. Re-run /code-review to verify
4. Proceed only when clean

If only MEDIUM or LOW issues:

1. Evaluate whether to fix now or later
2. Apply quality improvements
3. Safe to commit

If no issues:

1. Commit with confidence
2. Note positive patterns

Review Checks

🔴 CRITICAL (Security):

• SQL injection, XSS, command injection
• Hardcoded credentials or secrets
• Path traversal, auth bypass

🟠 HIGH (Correctness):

• Missing error handling
• Type mismatches
• Null/undefined gaps
• Logic errors, race conditions

🟡 MEDIUM (Maintainability):

• Naming violations
• Code duplication
• Poor organization

🟢 LOW (Suggestions):

• Performance optimizations
• Documentation improvements

Error Handling

Review fails:

• Ensure context files pre-loaded

Too many findings:

• Fix CRITICAL first, then re-review

Unclear findings:

• Request clarification in report

Red Flags

If you think any of these, STOP and re-read this skill:

• "The code looks fine, a review is overkill"
• "I wrote it, I know it's correct"
• "We're in a hurry, we can review later"
• "It's a small change, no security risk"

Common Rationalizations

Excuse	Reality
"I just wrote it so I know it's right"	The author is the worst reviewer. Fresh eyes catch what familiarity hides.
"It's a small change"	Security vulnerabilities are almost always in small, "obvious" changes.
"We can review after merging"	Post-merge review finds bugs in production. Pre-merge review finds them for free.
"There's no user input so no injection risk"	Internal data becomes user input when requirements change. Review now.

Remember

• Pre-load standards BEFORE invoking review
• CRITICAL and HIGH issues BLOCK commits
• Apply suggested fixes with code diffs
• Re-review after fixing blocking issues
• Review does NOT modify code—only suggests changes
• Review does NOT run tests—use test-generation for that

Related

• context-discovery
• code-execution
• test-generation

---

Task: Review the following files: $ARGUMENTS

Instructions for code-reviewer subagent:

1. Read all files in $ARGUMENTS
2. Apply pre-loaded standards (code quality, security, conventions)
3. Scan for: Security (HIGHEST PRIORITY) → Correctness → Style → Performance
4. Structure findings by severity: CRITICAL → HIGH → MEDIUM → LOW
5. For each finding: Problem + Risk + Suggested fix with diff
6. Include positive observations
7. Return recommendation: APPROVE | REQUEST CHANGES | COMMENT