Claude Code Code-Review Commands — 13 Structured Review Templates | AI Code Toolkit
Newsletter Join Waitlist →
Home› Slash Commands› Code Review
13 tested commands · OWASP · WCAG · Language-aware · Structured output

Code Review Slash Commands

Codified review checklists for every perspective: general, security, performance, accessibility, cost, and language-specific. Every command returns a structured Markdown verdict that pastes cleanly into a PR comment.

13
Commands
3
Perspectives
6+
Languages
48h
Update SLA

Why code-review commands unlock team consistency

Code review is the highest-signal, lowest-consistency activity most teams do. Two senior engineers reviewing the same PR will land on different concerns, different severity calls, and different verdicts — because they're pulling from different mental checklists. Slash commands fix that by codifying the checklist. Every review from /review-security hits the same OWASP categories in the same order and returns the same structured verdict format.

The 13 review commands on this page are specialized by perspective — general, security, performance, accessibility, and language/framework. Each is production-tested and returns structured Markdown output that reads like a senior engineer's review comment: severity, location, exploitability or impact, and a fix recommendation with code.

The lens: Review commands split by perspective (general, security, performance, a11y, cost) and by specialization (TypeScript, Python, React, Node, Go, Rust). Pick one perspective + one specialization, and you cover almost every review a PR needs.

Why output structure matters more than the prompt

A great review command's real value is the output contract. When every review returns:

  • A Markdown table with columns Severity | File:Line | Issue | Impact | Fix.
  • A "Ship / Ship with fixes / Do not ship" verdict.
  • A summary naming the top three issues in priority order.

… you get downstream benefits that free-form reviews can't: PR templates can slot the output directly into a comment, CI can parse the verdict to auto-approve or block, and dashboards can track severity trends over time. The command becomes a data source, not just a reply.

Anatomy of /review-security

markdown .claude/commands/review-security.md
--- allowed-tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*) description: Security-focused code review with OWASP-aligned findings and a structured verdict model: opus argument-hint: [path or "diff"] --- # Context - Target: $ARGUMENTS - If "diff" was passed, review: !`git diff --cached || git diff HEAD~1` # Task Perform a security-focused code review. Check systematically: 1. Authentication & session — bypass, weak comparisons, session fixation 2. Injection — SQL, NoSQL, command, LDAP, XPath 3. XSS — reflected, stored, DOM-based 4. CSRF — missing tokens, weak SameSite 5. Access control — IDOR, missing authz, path traversal 6. Secrets — hardcoded credentials, weak crypto, insecure random # Output format (strict) | Severity | File:Line | Issue | Exploitability | Fix | Then a summary section: "Ship / Ship-with-fixes / Do-not-ship" verdict with the top 3 issues named.

Force model: opus for security review — the multi-step reasoning about attack paths pays for the extra tokens, and a false negative here is much more expensive than the cost delta.

Review commands vs Reviewer subagents

Both work. Rule of thumb:

  • Slash command when the review is one shot in your main conversation and fits comfortably in the current context. Fast, cheap, direct.
  • Subagent when the review touches many files, needs to explore the codebase, or should run in isolation without polluting your main chat. See code-review subagents.

A common mature pattern: run /review-security as a slash command during interactive work, then delegate a full-repo audit to a security-reviewer subagent on a schedule (via SessionStart hook) or in CI.

Complete Listing

All 13 code-review commands, grouped by scope

Every command is production-tested with a structured output contract — severity table, verdict, and top-3 summary.

General & multi-perspective
/review popular
General code review: bugs, style, readability, error handling, obvious improvements. Sonnet by default.
/pr-summary popular
One-paragraph PR summary from git diff. Great for PR descriptions and standup updates.
Specialized perspectives
/review-security popular
OWASP-aligned security review with severity table and verdict. Force model: opus. Highest ROI review command.
/review-performance
Performance review: hot paths, N+1 queries, render blocking, memory allocation. Ranked by impact.
/review-a11y
WCAG 2.2 AA review: semantic markup, ARIA, keyboard, focus order, color contrast. UI code only.
/review-cost
Cost review of LLM-adjacent code: token usage, caching opportunities, model routing, batch API usage.
/review-database
Query and schema review: N+1s, missing indexes, transaction boundaries, migration safety.
Language & framework-specific
/review-typescript
TypeScript-focused review: type strictness, generics, discriminated unions, escapes to any.
/review-python
Python review: type hints, async, resource management, common Django/FastAPI/Flask pitfalls.
/review-react
React review: hooks rules, unnecessary renders, effect dependencies, Server Component boundaries.
/review-node
Node.js review: async correctness, event loop hazards, streams, worker threads, memory leaks.
/review-go
Go review: goroutine leaks, context propagation, error handling idioms, interface use, channel patterns.
/review-rust
Rust review: ownership, lifetimes, unsafe blocks, panics, async correctness with tokio patterns.
Decision Framework

Which review command should I use?

A quick decision framework for common PR review situations.

→For a general PR review
Use /review. Sonnet is fine for most cases. Follow up with /pr-summary to generate the PR description if you don't have one yet.
→For code touching auth, input, or DB
Use /review-security. Force model: opus. Highest-cost review command, but the ROI on a caught vulnerability dwarfs the token bill.
→For a UI change or new component
Chain /review-a11y and /review-react (or your framework). Different lenses catch different things — running both is under a minute.
→For a slow endpoint or page
Use /review-performance. Pair with /review-database if the code touches queries — N+1s are the most common finding by a wide margin.
→For a whole-repo audit
Don't use a slash command — the context won't fit. Delegate to a subagent or run in CI. Slash commands are for interactive review.
→For LLM-integration code
Use /review-cost. Catches missing prompt caching, wrong model routing, and non-batched calls — the three most common LLM cost leaks.
Related in Slash Commands

Related sub-categories in Slash Commands

Review pairs naturally with testing, security, and debugging — the four commands most teams install together.

🧪 Testing15
Test authoring, coverage analysis, flaky-test fixes, and mock generation.
🔒 Security13
Security audits, dependency checks, secrets scans, CSRF/XSS/injection defenses.
🐛 Debugging11
Root-cause analysis, repro scripts, log strategies, and memory-leak hunts.
♻️ Refactoring15
Extract functions, rename safely, convert JS to TS, and modernize legacy patterns.

🐛 Hit an error while using these?

Our sister site AI Error Hub covers Claude Code errors, MCP connection failures, and stack traces — cross-referenced with everything on this site.

Visit AI Error Hub →
FAQ

Frequently asked questions

The questions developers ask most about code review.

/review is the go-to. It runs on Sonnet by default (fast, cheap), covers bugs, style, error handling, and obvious improvements, and returns a structured Markdown output that copies cleanly into a PR comment.

If the code is security-sensitive or touches auth, follow up with /review-security using Opus.

Opus. Security review benefits disproportionately from multi-step reasoning about attack paths, and the token cost delta is small relative to the cost of a missed vulnerability.

Force model: opus in the frontmatter. This is the one command where cost-optimization thinking should lose to correctness thinking.

By explicitly specifying the output format in the command body. Great review commands don't just say "do a review"; they say:

"Return a Markdown table with columns Severity | File:Line | Issue | Impact | Fix, followed by a Ship / Ship-with-fixes / Do-not-ship verdict."

The output contract is what makes the command useful downstream — PRs can paste it directly, CI can parse the verdict, dashboards can track trends.

Sometimes yes. Common chains:

  • New UI component → /review-a11y then /review-react.
  • Full-stack change → /review + /review-security + /review-performance.
  • API endpoint → /review-security + /review-database.

Chaining works because each command's output is independent and structured.

Scope and depth.

  • /review — broad pass covering bugs, style, and general correctness. Sonnet. Fast. Everyday use.
  • /review-security — narrow and deep, targeting OWASP-aligned categories with Opus's deeper reasoning.

They're complementary, not overlapping — run both on security-sensitive changes.

Commit .claude/commands/ to git. That's the whole play.

The moment /review-security lives at .claude/commands/review-security.md in your repo, every teammate on their next pull uses the same command with the same OWASP checklist, same output format, and same severity thresholds.

This is exactly why project-scoped commands beat personal ones for team work.

Slash command — one-shot review in your main conversation. Fast, cheap, direct.

Subagent — the review needs to explore the codebase, touch many files, or run in isolation.

Mature pattern: /review-security in interactive work, plus a security-reviewer subagent triggered on a SessionStart hook or in CI for whole-repo audits.

Not directly — slash commands are a Claude Code interactive feature. But you can:

Full CI integration is on the roadmap for the Toolkit CLI.

Read-only. The allowed-tools list for a review command should be:

  • Read, Grep, Glob — file inspection.
  • Bash(git diff:*), Bash(git log:*) — narrow git subset.

Review commands should not have Write, Edit, or general Bash access — a reviewer that can modify code is a bug factory. This is the primary security guarantee for team-shared review commands.

Four commands cover 80% of what most teams do:

  1. /review — general PRs.
  2. /review-security — anything touching auth or input.
  3. /pr-summary — PR descriptions.
  4. One language-specific review matching your main stack (/review-typescript, /review-python, etc.).

Add /review-a11y if you ship UI, /review-database if you ship data.

Share with

Twitter/XPinterestRedditMastodonThreadsEmailPrintFlipboardFlipboardHacker NewsLineWeChatSnapchatMixMixPocketGoogle MessagesSMSTumblrTumblrXingXINGVKVKontakteBufferBufferYummlyNextdoorGrocyGabFacebookWhatsAppLinkedInTelegramMessengerBluesky