Operations Production Readiness Code Review

Production Readiness Review Prompt

SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.

Overview

The strongest combination on the tool: Production Readiness focus under Production Gate style. Every finding answers one standing question — would this survive production traffic, failures, and attackers? — across twelve checks: timeouts and bounded retries, 3-a.m. debuggability, metrics for new behavior, environment-safe config, graceful degradation, feature-flag rollback, migration compatibility, resource limits, idempotency under retry, alarms for new failure modes, secret storage, and behavior at 10× traffic. The verdict is a deployment decision: SHIP or DO NOT SHIP, with the minimal change list that flips it.

How to use this resource

  1. Run it as the last gate

    After correctness review, after tests — this pass asks the questions that only matter in production.

  2. Respect the DO NOT SHIP list

    The verdict comes with the minimal set of changes that would flip it — that list IS the pre-deploy task list.

  3. Re-run at 10× growth

    The traffic question ages: what survived launch traffic may not survive this quarter's.

Why This Works

  • A deployment decision forces the review to commit — no "mostly fine" verdicts
  • Failure-mode checks review the code's worst day, not its demo
  • The minimal-fix list turns a blocked deploy into a finite plan

Best for

  • Changes shipping to systems with real users and real SLAs
  • Teams without a formal production-readiness review process
  • The PR that "works locally" and is about to find out

Not for

  • Library or tooling code that never serves traffic — use Correctness or Maintainability focus
  • Incident diagnosis after the deploy — that's the Debugging Prompt Generator

Use cases

  • Gating the weekly deploy with a structured readiness pass
  • Reviewing failure handling before code meets real dependencies
  • Making "is this observable enough?" a checklist item instead of a hope

FAQ

Does a DO NOT SHIP verdict from this prompt mean my change is actually unsafe to deploy?

Treat it as a structured recommendation, not a clearance. The code-review-prompt-generator outputs a prompt whose FINAL VERDICT ends in SHIP or DO NOT SHIP with a minimal-change list, but you run that prompt in your own assistant and the verdict reflects only the pasted PR and the model's findings. A human still owns the deploy decision.

How does this differ from a normal correctness code review before merge?

It reviews the code's worst day rather than its logic. The REVIEW CHECKLIST asks production-only questions no correctness pass covers: bounded retries and timeouts, 3 a.m. debuggability without a debugger, feature-flag rollback, idempotency under retry, and what breaks first at 10x traffic. Run correctness review first; this is meant to be the last gate before deploy.

What do I paste into this readiness review prompt?

Paste a full pull request at the CODE TO REVIEW marker, since REVIEW SCOPE judges the change as it will land across files at deploy time. It expects the deploy-time diff, not a single function, so checks like migration compatibility, partial-deploy ordering, and 10x-traffic behavior have the cross-file context they need.

Why does every finding get a CRITICAL, MAJOR, MINOR, or NIT tag?

So the DO NOT SHIP verdict rests on ranked evidence, not vibes. The SEVERITY RULES force exactly one tag per finding by impact, not effort — CRITICAL means fix before merge, NIT is optional style. The prompt also treats missing failure handling and missing observability as findings, not nice-to-haves, so they can't quietly slip under the bar.

More resources from Code Review Prompt Generator

Resources that pair well

Related tools

Projects that use this resource

Workflows that use this resource

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.