Skill: charlie-morrison/cm-code-review-assistant (version 1.0.0)

--- name: code-review-assistant description: AI-powered code review assistant that analyzes pull requests for bugs, security issues, performance problems, and style violations with actionable feedback. metadata: tags: ["code-review", "pull-request", "quality", "security", "development"] --- # 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: ```bash # 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: ```typescript // 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`)


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)