Review and ship with Claude Code
PLShipping a Claude Code change safely means stacking gates between the diff and production: /code-review in the session, a headless claude -p check before push, an automated review on the pull request, a named owner at merge, and a rehearsed rollback at deploy. No single review decides; the combined evidence does.
This hub is for developers and tech leads whose Claude Code sessions open more pull requests than anyone can read. The mistakes sit where you stopped looking: a missing authorization check, a test weakened to pass, a migration without a backfill. Checked against Claude Code v2.1.283.
Which Claude Code ship page answers your question?
Section titled “Which Claude Code ship page answers your question?”| Your question | Page |
|---|---|
| How do I make Claude review every diff the same way? | Automated code reviews |
| How do I run Claude Code in CI without exposing secrets? | Running Claude Code in CI/CD |
| How do I get Claude to write or harden the pipeline itself? | Pipeline configuration with Claude Code |
| How do I containerize the service and prove the manifests work? | Docker and Kubernetes setup with Claude Code |
| How do I deploy, gate the release and roll it back? | Deployment automation with Claude Code |
If the tests behind these gates are thin, start with testing and debugging with Claude Code: a gate is only as strong as its oracle.
In what order should a Claude Code change go out?
Section titled “In what order should a Claude Code change go out?”Cheap, private checks run first, so the public review stays worth reading.
-
Before commit. Run
/code-reviewon the working diff and fix every blocking finding;/code-review --fixapplies the fixes. Add/security-reviewwhen the diff touches authentication, input handling or secrets. -
Before push. Save this as
.git/hooks/pre-pushand make it executable (chmod +x). It runs a read-only review and blocks the push unless the last line is a pass:#!/bin/shout=$(mktemp)claude -p "Review the diff between origin/main and HEAD for correctness and security defects only. \Ignore style. End with exactly one line: VERDICT: PASS or VERDICT: FAIL." \--permission-mode dontAsk \--allowedTools "Read" "Grep" "Glob" "Bash(git diff *)" "Bash(git log *)" \--output-format json --max-budget-usd 1.00 > "$out" || exit 1jq -r '.result' "$out" | tail -n 1 | grep -qx 'VERDICT: PASS'dontAskdenies every tool call that would prompt, so the check cannot edit files unless you allow it, and--max-budget-usdcaps the spend. The hook needsjqon PATH. -
On the pull request. Add a review job that uses
anthropics/claude-code-action@v1(see automated code reviews), or turn on managed Code Review (Team and Enterprise, research preview; “averages $15-25” per review). For a high-risk branch,claude ultrareview 123runs a cloud multi-agent review of pull request 123 (/code-review ultrain a session). Pro and Max get three free runs, then “typically $5 to $25” each (Anthropic docs, checked 2026-09-26). -
In CI. Tests, types and lint run outside Claude’s control, so the agent cannot mark its own work green.
-
At merge. A named human signs off on the paths
CODEOWNERSescalates: migrations, auth, money, public APIs, tests, CI config. -
At deploy. Ship behind a flag or a canary, with a rollback you have run at least once.
How do you know a Claude Code change is safe without reading every line?
Section titled “How do you know a Claude Code change is safe without reading every line?”Read the evidence each gate produces, and open the diff only where it points.
| Evidence | What it proves | Owner |
|---|---|---|
| Seeded-bug catch rate of your review prompt or workflow | The review finds the defect classes you care about | Tech lead |
VERDICT: PASS from the pre-push hook | No blocking defect by your written rules | Author |
| CI green on the pushed branch: tests, types, lint | Existing behaviour still holds | CI |
Approval on CODEOWNERS escalation paths | A person accepted the risk where a miss is expensive | Named code owner |
| Canary metrics and a rehearsed rollback | Production confirms the change, or you can undo it quickly | On-call engineer |
The evidence bundle defines what an agent’s pull request carries, agent PR review is the triage that reads it, and evidence, not diffs explains why.
What breaks between an approved diff and a running deployment?
Section titled “What breaks between an approved diff and a running deployment?”| Symptom | Cause | Recovery |
|---|---|---|
| The team ignores Claude’s review comments | Too many style and low-severity findings | Report correctness and security only; list “do not flag” categories in CLAUDE.md |
| The pre-push hook passes a branch it should fail | The prompt found nothing it was told to look for | Seed a known bug on a scratch branch; tighten the prompt until the hook fails |
| A pull request weakens its own review | The PR job reads that branch’s CLAUDE.md and .claude/ settings | Put CLAUDE.md, .claude/ and .github/ under CODEOWNERS; in other CI add --bare --setting-sources "" --strict-mcp-config (--bare authenticates only with ANTHROPIC_API_KEY or an apiKeyHelper) |
| A secret leaks from a PR-triggered job | Untrusted code ran with secrets in the environment | Work through agent identity and secrets before enabling the trigger |
| Ultrareview or managed Code Review is unavailable | Neither runs under Zero Data Retention; Ultrareview is not offered on Bedrock, Google Cloud or Foundry (Anthropic docs, checked 2026-09-26) | Use /code-review locally and a review job built on the GitHub Action |
| Rollback fails in production | A migration dropped data the old code needs | Split it with expand and contract; never ship a destructive migration with its code |
Where to go next with shipping Claude Code changes
Section titled “Where to go next with shipping Claude Code changes”Next, operate Claude Code in production. The tool-neutral version is shipping workflows for every agent; siblings: review and ship with Codex and review and ship with Cursor.