C9PG
Claude Code Docs

Review and Debug Commands

This tutorial picks up after Your First Feature. The commands here matter once Claude has already made progress and you need review, debugging, or visibility into the current environment.

1. Run /simplify before you trust a change

Run:

text
/simplify

What you should see: a review pass focused on code quality, duplication, and simpler alternatives.

2. Add /security-review when the change deserves it

Run:

text
/security-review

What you should see: a security-focused review of the current work. Use this for auth, secrets, permissions, payments, or production-sensitive changes.

3. Use /debug when you have a real failure

Prompt:

text
/debug
The checkout session expires too early.
Here is the error and the last failing command: ...
Investigate before proposing a fix.

What you should see: Claude investigates the failure path instead of guessing immediately.

4. Inspect permissions when prompts feel noisy or surprising

Run:

text
/permissions

What you should see: the current permission model, so you can tell whether the friction is expected or whether the repo baseline needs adjustment.

5. Inspect hooks without opening every config file manually

Run:

text
/hooks

What you should see: the active hooks or the current hook configuration surface. This is the first place to check when the session is being blocked or auto-assisted in ways you do not expect.

Advanced: Match the Starter Files

The starter project ships a reusable reviewer agent in addition to /simplify.

Starter code-reviewer.md
md
---
name: code-reviewer
description: Reviews implementation against plan and coding standards.
model: sonnet
tools: Read, Grep, Glob, Bash
---
You are a code reviewer. Given a plan and recent changes:

1. Run `git diff` to see all changes.
2. Verify each plan item was implemented correctly.
3. Check for:
   - Missed edge cases
   - Security issues (injection, auth bypass, data exposure)
   - Missing or insufficient tests
   - Performance concerns (N+1 queries, unnecessary allocations)
   - Style violations against project conventions
4. Rate each issue:
   - **CRITICAL**: Blocks merge. Must fix before proceeding.
   - **MAJOR**: Should fix. Creates real risk or tech debt.
   - **MINOR**: Nice to fix. Style, naming, or minor improvement.
5. CRITICAL issues must be resolved before proceeding.
6. Summarize: what's good, what needs work, risk assessment.

Use the two review surfaces differently:

  • /simplify is the fast built-in review pass you should use constantly.
  • code-reviewer is the reusable repo-specific reviewer the starter project keeps around when the team wants a consistent second opinion against the plan and team standards.

The starter baseline uses both because they solve different review problems.

What to repeat in real work

text
/simplify
/security-review
/debug
/permissions
/hooks

Next step

Continue with Using Skills so you can recognize when Claude already has a reusable workflow available instead of inventing one every time.