/code-reviewer

name: memstack-development-code-reviewer
description: "Use this skill when the user says 'review code', 'code review', 'check my code', 'audit this', 'review PR', 'review changes', 'what's wrong with this', or is requesting a structured review of code quality, security, performance, or maintainability. Do NOT use for refactoring plans or test generation."
version: 1.0.0
license: "Proprietary, MemStack™ Pro by CW Affiliate Investments LLC. See LICENSE.txt"

🔍 Code Reviewer: Reviewing code for issues and improvements...

*Systematic code review across security, performance, maintainability, error handling, testing, and accessibility, with severity-ranked findings and specific fixes.*

Activation

When this skill activates, output:

`🔍 Code Reviewer: Scanning for issues...`

Then execute the protocol below.

| Context | Status | |---------|--------| | User says "review code" or "code review" or "check my code" | ACTIVE | | User says "audit this" or "review PR" or "review changes" | ACTIVE | | User asks "what's wrong with this" about code | ACTIVE | | Reviewing a specific file or set of changes | ACTIVE | | User is writing code and hasn't asked for review | DORMANT | | Discussing code architecture at a high level | DORMANT |

Anti-patterns

| Trap | Reality Check | |------|---------------| | "This looks fine to me" | Check every category systematically. Skimming misses auth gaps and N+1 queries. | | "Style issues are important" | Linters handle style. Focus on logic, security, and correctness. | | "I'll flag everything I see" | Noise kills reviews. Only report issues with real impact. Severity matters. | | "The code works so it's fine" | Working does not mean correct. Race conditions, edge cases, and security holes all "work" until they don't. | | "I'll suggest a complete rewrite" | Review what's there. Propose targeted fixes, not architectural overhauls. |

Severity Levels

| Level | Label | Meaning | Action | |-------|-------|---------|--------| | 🔴 | **Critical** | Security vulnerability, data loss risk, crash in production | Fix before merge | | 🟠 | **High** | Bug, incorrect behavior, significant performance issue | Fix this sprint | | 🟡 | **Medium** | Code smell, minor performance issue, missing edge case | Fix when touching the file | | 🔵 | **Low** | Style preference, minor improvement, documentation gap | Consider for future |

Protocol

Step 1: Security Review

Scan for security vulnerabilities: this category takes priority.

**Authentication gaps:**

Search for route handlers and verify each has auth checks:

grep -rn "export async function\|export function" --include="*.ts" app/api/ | head -20

Flag these patterns:

• Route handler without auth check (e.g., `getAuthContext`) at the top
• Org-scoped route without `verifyOrgAccess`
• Admin action without role verification
• Webhook endpoint without signature verification

**Exposed secrets:**

Search for hardcoded credentials:

grep -rn "sk_live\|sk_test\|password\s*=\s*['\"]" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" . | grep -v node_modules | grep -v .env.example

Flag these patterns:

• API keys or tokens hardcoded in source
• `.env` files committed to git
• Secrets in client-side code (`NEXT_PUBLIC_` prefix on secret values)
• Database connection strings in source files

**Injection vulnerabilities:**

Search for unsafe input handling:

grep -rn "\.raw(\|\.unsafeRaw\|innerHTML\s*=" --include="*.ts" --include="*.tsx" --include="*.js" . | grep -v node_modules

Flag these patterns:

• String concatenation in SQL queries (use parameterized queries)
• Unsafe HTML rendering with user-supplied content
• Unsanitized URL parameters used in redirects (open redirect)
• User input reflected in HTML without escaping (XSS)

Step 2: Performance Review

Identify patterns that degrade under load.

**N+1 queries:**

# Find loops that might contain database calls
grep -rn "\.forEach\|\.map\|for.*of\|for.*in" --include="*.ts" --include="*.tsx" . | grep -v node_modules | head -20

Flag these patterns:

• Database query inside a loop (fetch all in one query, then map)
• `await` inside `.map()` without `Promise.all()` (sequential when it could be parallel)
• Sequential `await` calls that could be `Promise.all([...])` (parallelizable)

**Missing indexes:**

• Foreign key columns without an index (causes slow JOINs)
• Columns used in `WHERE` or `ORDER BY` without indexes
• Composite queries that need composite indexes

**Frontend performance:**

# Check for large imports that should be tree-shaken
grep -rn "import .* from ['\"]lodash['\"]" --include="*.ts" --include="*.tsx" . | grep -v node_modules

Flag these patterns:

• Full library imports instead of tree-shakeable imports (`import _ from 'lodash'`)
• Large dependencies in client bundles (check with `next build --analyze`)
• Missing `React.memo`, `useMemo`, or `useCallback` on expensive renders
• Images without width/height or `next/image` optimization
• Unthrottled event handlers (scroll, resize, input without debounce)

**Data fetching:**

• Fetching more data than needed (SELECT * instead of specific columns)
• Missing pagination on list endpoints
• No caching on expensive, infrequently-changing queries
• Client-side fetching for data that could be server-rendered

Step 3: Maintainability Review

Evaluate code clarity and organization.

**Dead code:**

grep -rn "export " --include="*.ts" --include="*.tsx" . | grep -v node_modules | head -30

Flag these patterns:

• Functions/components that are never imported
• Commented-out code blocks (delete it: git has history)
• Unused variables, imports, or parameters
• Feature flags for features that shipped months ago

**Duplicated logic:**

• Same validation logic in multiple route handlers (extract to shared schema)
• Repeated auth patterns (extract to middleware or helper)
• Copy-pasted components with minor differences (ext