Review Code

You MUST follow these steps exactly. Do NOT skip, reorder, or substitute any step. Do NOT review the code yourself — the subprocess does the review.

Step 1: Resolve file paths

• •$ARGUMENTS is required. If empty, tell the user: "Provide file path(s): /review-code src/app.ts or /review-code src/a.ts src/b.ts" and stop.
• •Split $ARGUMENTS on whitespace to get one or more file paths.
• •Resolve ~ to $HOME in each path.
• •If a path is relative, resolve it against the current working directory.

Step 2: Validate files

Read the file to read each file. This is a validation gate — confirm every file exists and has content. If any file is missing or empty, tell the user which one and stop.

Step 3: Prepare the input

Single file

If there is exactly one file, you will use input redirection directly in Step 4. No preparation needed.

Multiple files

If there are multiple files, create a temporary combined file using Bash:

TMPFILE=$(mktemp /tmp/review-code-XXXXXX.txt)
for f in FILE1 FILE2 ...; do
  echo "===== FILE: $f =====" >> "$TMPFILE"
  cat "$f" >> "$TMPFILE"
  echo "" >> "$TMPFILE"
done
echo "$TMPFILE"

Replace FILE1 FILE2 etc. with the actual absolute paths. Remember the temp file path for Step 4.

Step 4: Run the subprocess review

You MUST use Bash to run claude -p as a subprocess. The entire point is to get an independent second opinion from a sandboxed subprocess.

Constructing the command

Use this exact pattern. Replace INPUT_FILE_PATH with either the single file path or the temp file from Step 3:

claude -p "$(cat <<'PROMPT'
You are a senior staff engineer conducting a mandatory code review. The code
was written by a junior developer. Your job is to find real problems — do NOT
be encouraging or gentle. Treat this as a pull request that needs your sign-off.

Review the code provided via stdin. Analyze for:

1. Bugs and logical errors — incorrect behavior, off-by-one, race conditions
2. Security vulnerabilities — injection, path traversal, data exposure, auth gaps
3. Error handling — silent failures, swallowed exceptions, missing validation
4. Performance — unnecessary allocations, blocking calls, N+1 patterns, missing timeouts
5. Type safety — unsafe casts, any types, missing null checks
6. Code quality — dead code, duplication, naming, single-responsibility violations
7. Architecture — coupling, separation of concerns, hardcoded values, missing abstractions
8. Missing tests or testability issues

Output format — use EXACTLY this structure:

## Grade: X/5
A single number from 0 to 5, followed by a one-line justification.
- 0 — Critical errors that will cause failure, data loss, or security breach
- 1 — Major bugs or vulnerabilities that need significant rework
- 2 — Several important issues that must be addressed before shipping
- 3 — Functional code with notable gaps to fix
- 4 — Good code, only minor improvements needed
- 5 — Totally safe to ship as written

## Verdict
One of: APPROVE, REQUEST CHANGES, or NEEDS DISCUSSION. One sentence justification.

## Findings
Number each finding. Tag severity as [Critical], [High], [Medium], or [Low].
For each: state WHAT is wrong, WHY it matters, and HOW to fix it.
Group by category (Security, Bugs, Error Handling, Performance, Type Safety, Code Quality, Architecture).

## Summary
3-5 bullet points: the most important things to fix before this code ships.
PROMPT
)" --output-format text --tools "" < INPUT_FILE_PATH

Non-negotiable requirements

• •--tools "" MUST be present. This sandboxes the subprocess — analysis only, no code execution.
• •--output-format text MUST be present. Clean plaintext output.
• •The prompt argument comes IMMEDIATELY after -p. Do NOT put flags between -p and the prompt string.
• •Use < file input redirection. Do NOT use cat file | piping.
• •The prompt says "code provided via stdin" — this is critical. Without it, the subprocess may ignore the stdin content.
• •Set a Bash timeout of 120000 (2 minutes).
• •Do NOT add any other flags or modify the prompt.

Step 5: Clean up and present results

1. •If you created a temp file in Step 3, delete it: rm "$TMPFILE"
2. •Show the subprocess output to the user, prefixed with the file(s) reviewed:

For single file:

Reviewed: src/app.ts

[subprocess output]

For multiple files:

Reviewed: src/a.ts, src/b.ts

[subprocess output]

Do NOT add your own commentary or re-analyze the code. The subprocess output IS the deliverable.

Step 6: Capture session ID for follow-ups

The claude -p command prints a session ID to stderr (format: Session ID: ses_...). Capture it by appending 2>&1 or by extracting from the combined output.

After presenting the review, tell the user:

Session: <session-id>
To continue this review conversation, run: /review-code --resume <session-id>

Resuming a previous session

If $ARGUMENTS starts with --resume, extract the session ID that follows and run:

claude --resume SESSION_ID

This continues the existing review conversation so the user can ask follow-up questions, request clarification on specific findings, or discuss fixes. Use --tools "" again to keep it sandboxed. Skip all other steps — go straight to this command and present the output.

Step 7: Handle errors

• •If the subprocess returns an error or empty output, show the error and suggest the user try again.
• •If the subprocess times out, tell the user the file may be too large and suggest reviewing a smaller section.