Review Claude Code Changes Before You Merge

Review Claude Code Changes Before You Merge

A patch can look tidy and still solve the wrong problem. My review rule is simple: treat Claude Code output as a contribution, not a verdict. Read the behavior change, reproduce the failure, and verify the exact patch you intend to merge. This walkthrough assumes Bash, an existing Git repository, and a Node.js project with a committed package-lock.json.

1. Establish the Patch Boundary Before Reading Code

Start at the repository root. Run each command separately: — git status --short

git diff --stat HEAD — git diff --no-ext-diff HEAD

The HEAD comparison includes staged and unstaged tracked changes. Untracked files appear in status but not that diff, so open those separately. If the agent already committed its work, compare against the agreed base instead; otherwise, you may review nothing. ([git-scm.com](https://git-scm.com/docs/git-diff?utm_source=openai))

• Every changed file must support the requested behavior change.
• Unrelated refactors belong in a separate patch with separate justification.
• Generated files must match their source changes and generation process.

Write down one acceptance sentence before proceeding: an expired session returns an authentication error without exposing account data. That sentence is the review target, not the agent's summary.

2. Inspect Execution Hooks Before Running Project Commands

Read the scripts and dependency changes before executing them: — cat package.json

git diff HEAD -- package.json package-lock.json .github/workflows

Look for new install hooks, changed registry URLs, broader CI permissions, and scripts that download executables. My gate here is manual approval: no test command runs until I understand what it launches.

Then, in a disposable development environment without production credentials, run:

npm ci --ignore-scripts

This installs from the lockfile without running package scripts. It is not a sandbox, and skipped setup scripts can leave dependencies unusable. If setup is required, inspect and approve it explicitly rather than quietly removing the flag. ([docs.npmjs.com](https://docs.npmjs.com/cli/commands/npm-ci/?utm_source=openai))

3. Read Error Paths Before Trusting the Happy Path

Follow the changed function into its callers. For an authentication patch, inspect the unauthenticated request, expired credential, wrong tenant, and upstream timeout. For a retry patch, check whether repeating the operation can duplicate a charge or write.

• Authorization checks must happen before protected reads or writes occur.
• Error responses must avoid exposing credentials, prompts, or internal identifiers.
• Retries must have explicit limits and respect operation idempotency.
• Tests must assert observable outcomes rather than mirror implementation details.

Check mechanical issues separately with: — git diff --check HEAD

This catches introduced whitespace errors and conflict markers; it does not validate application behavior. ([git-scm.com](https://git-scm.com/docs/git-diff?utm_source=openai))

4. Run the Repository's Real Verification Commands

For this example, assume package.json defines lint, typecheck, test, and build. After inspecting those scripts, run:

npm run lint && npm run typecheck && npm test && npm run build

Use the actual script names in your repository. Explicit npm test and npm run commands still execute their intended scripts even when ignore-scripts is configured, so inspection remains essential. ([docs.npmjs.com](https://docs.npmjs.com/cli/commands/npm-ci/?utm_source=openai))

Add a regression test for the acceptance sentence. In a disposable worktree, verify that it fails against the pre-fix implementation and passes with the patch. Record any untested database migrations or external integrations instead of treating a green unit suite as complete coverage.

5. Ask Claude Code for Findings, Not Reassurance

Request a separate review pass: — claude --permission-mode plan -p 'Review the current patch against HEAD. Do not edit files. Report correctness, authorization, retry, and missing-test findings with file paths and line numbers. Separate confirmed defects from hypotheses.'

The CLI supports print mode and selecting a permission mode. Still review local tool configuration before launching it, and keep credentials out of its environment. ([code.claude.com](https://code.claude.com/docs/en/cli-reference))

With Fluxo, one key and the base URL https://api.fluxorelay.com serve Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. You could compare a Claude Sonnet 5.5 implementation with GPT-6.1 Sol review findings, but agreement is not proof.

Fluxo bills actual tokens, including cache reads and writes, without a monthly fee; users also earn a referral share when invitees pay. If this fits your terminal workflow, consider creating a Fluxo account.

6. Approve Only the Final Reviewed Patch

Stage explicit paths rather than everything. Then run: — git diff --cached --check

git diff --cached --no-ext-diff — The cached diff shows the staged patch. Recheck it after any agent fix, rerun affected tests, and leave approval blocked until every material finding is resolved or explicitly accepted. ([git-scm.com](https://git-scm.com/docs/git-diff?utm_source=openai))