code-review

Code Review

Run a structured review of branch changes covering security, language strictness, performance, and conventions.

Workflow

Step 1: Detect changes

# Default base branch is main. User can override: /code-review --base staging
BASE=${1:-main}
git fetch origin "$BASE" --quiet 2>/dev/null || true
MERGE_BASE=$(git merge-base "origin/$BASE" HEAD)
BRANCH=$(git rev-parse --abbrev-ref HEAD)

# Changed files and stats
git diff --name-status "$MERGE_BASE"..HEAD
git diff --stat "$MERGE_BASE"..HEAD
git log --oneline "$MERGE_BASE"..HEAD

Use $MERGE_BASE..HEAD for ALL diffs. Never use origin/main..HEAD directly -- it includes changes from other merged branches.

Step 2: Auto-detect languages

Map file extensions to rule sets:

Extension	Rule set	Skill
.ts, .tsx	TypeScript	typescript-strict
.rs	Rust	rust-strict
.swift	Swift	swift-strict
.go	Go	go-strict
.js, .mjs, .cjs	JavaScript	javascript-strict

Only apply rules for languages present in the diff.

Step 3: Run checks

Run in this order. For each finding, record file, line number, description, and rule ID.

3a. Security scan (security-audit-standard)

Scan the diff output (not the full repo) for:

• Secrets: API keys, tokens, passwords, connection strings (sk-, ghp_, AKIA, -----BEGIN PRIVATE KEY)
• Input validation: unvalidated user input reaching SQL, HTML, shell commands, file paths
• Injection risks: string concatenation in queries, eval(), innerHTML, unsanitized template literals
• Auth issues: missing auth checks on endpoints, weak JWT config, secrets in client-side code
• File patterns: .env, *.pem, credentials.json committed

3b. Language strictness checks

Apply the top rules for each detected language (see Quick Reference Tables below). Read the changed lines and flag violations.

3c. Performance scan (performance-audit-standard)

Look for these anti-patterns in the diff: