cm-code-review-assistant（cm 代码审查助理）

Code Review Assistant

Perform thorough AI-powered code reviews on pull requests or local changes. Analyzes diffs for bugs, security vulnerabilities, performance issues, maintainability concerns, and style violations. Provides actionable, specific feedback — not generic advice.

Usage

"Review the current PR"
"Review the changes on this branch vs main"
"Review these specific files for security issues"
"Do a deep review of the authentication changes"

How It Works

1. Gather Changes

Collect the diff and context:

# PR review
gh pr diff <number> --color=never

# Branch review
git diff main...HEAD

# Staged changes
git diff --cached

Also gather:

• File history (recently changed = higher risk)
• Test coverage for changed files
• Related open issues or previous reviews

2. Multi-Pass Analysis

Each pass focuses on a different concern:

Pass 1 — Correctness:

• Logic errors (off-by-one, null handling, race conditions)
• Edge cases not covered (empty input, boundary values, overflow)
• Error handling gaps (uncaught exceptions, missing error propagation)
• State management issues (stale closures, mutation of shared state)
• Concurrency bugs (deadlocks, data races, missing synchronization)

Pass 2 — Security:

• Injection vulnerabilities (SQL, command, XSS, template)
• Authentication/authorization gaps
• Sensitive data exposure (logs, errors, responses)
• Insecure cryptography or random number generation
• Missing input validation at trust boundaries
• Hardcoded secrets or credentials

Pass 3 — Performance:

• N+1 query patterns
• Missing or incorrect caching
• Unnecessary allocations in hot paths
• Blocking operations in async contexts
• Missing pagination or unbounded queries
• Inefficient algorithms (quadratic loops on large data)

Pass 4 — Maintainability:

• Complex functions that should be split (cyclomatic complexity >10)
• Missing or misleading names
• Dead code or unreachable branches
• Duplicated logic that should be extracted
• Missing types or overly broad types (any, Object)
• Tight coupling between modules

Pass 5 — Testing:

• Changed logic without corresponding test changes
• Test quality (testing implementation vs behavior)
• Missing edge case tests
• Flaky test patterns (timing, ordering, external deps)
• Adequate error path coverage

3. Severity Classification

Each finding gets a severity:

• 🔴 Must Fix: Bug, security issue, data loss risk, crash
• 🟡 Should Fix: Performance issue, maintainability concern, missing test
• 🟢 Consider: Style improvement, minor optimization, suggestion
• 💡 Nitpick: Optional improvement, personal preference

4. Actionable Feedback

Every comment includes:

• What: The specific issue found
• Where: Exact file and line number
• Why: Why this is a problem (not just "this is bad")
• How: Concrete fix suggestion with code

5. Summary

Overall assessment with:

• Risk level (safe to merge / needs changes / needs redesign)
• Top 3 most important findings
• Positive observations (good patterns, improvements)
• Suggested follow-up items (not blocking merge)

Output

## Code Review Summary

**Risk Level:** 🟡 Needs Changes (2 must-fix, 4 should-fix)
**Files Reviewed:** 12 files, +342/-89 lines

### 🔴 Must Fix

1. **SQL Injection in user search** — `src/api/users.ts:47`
   The search query interpolates user input directly:

// Current (vulnerable) db.query(SELECT * FROM users WHERE name LIKE '%${query}%') // Fix: use parameterized query db.query('SELECT * FROM users WHERE name LIKE $1', [%${query}%])

2. **Race condition in balance update** — `src/services/wallet.ts:112-118`
   Read-then-write without transaction. Two concurrent requests
   can both read the same balance and overwrite each other.
   Fix: wrap in a database transaction with SELECT FOR UPDATE.

### 🟡 Should Fix

3. **N+1 query in order listing** — `src/api/orders.ts:23`
   Each order triggers a separate query for user details.
   Use a JOIN or batch load users by ID.

4. **Missing error handling** — `src/services/payment.ts:67`
   API call result is not checked for errors before accessing `.data`.

[...]

### 👍 Good Stuff
- Clean separation of concerns in the new service layer
- Comprehensive input validation on the registration endpoint
- Good use of TypeScript discriminated unions for payment status

### 📋 Follow-up (non-blocking)
- Consider adding request rate limiting to the search endpoint
- The `formatDate` utility is duplicated in 3 files — extract to shared utils

Configuration

The review depth adapts to PR size:

• Small (<100 lines): Full deep review, every line examined
• Medium (100-500 lines): Focused review on high-risk areas
• Large (500+ lines): Architectural review + spot-check critical paths, suggest splitting PR

Integration

Works with:

• GitHub PRs (via gh CLI)
• GitLab MRs (via glab CLI)
• Local git branches (via git diff)
• Patch files (via git apply --stat)