| name | release-readiness |
| description | Use when a change may affect rollout, deployment, migrations, or operational stability and needs a higher-confidence validation pass. |
Release Readiness
Review whether a change is safe to merge, deploy, and roll back. Focus on concrete release risk, missing safeguards, and validation gaps rather than general code quality.
Review Focus
Check the change for:
- rollout coupling: feature flags, config switches, sequencing, and phased enablement
- deployment impact: build, env vars, infra assumptions, runtime compatibility, and startup behavior
- migration safety: backward compatibility, data shape transitions, dual-read or dual-write needs, and ordering constraints
- rollback readiness: whether old and new versions can coexist and whether rollback leaves data or traffic in a broken state
- operational stability: alerts, logging, dashboards, runbooks, rate limits, timeouts, retries, and failure containment
- validation quality: whether tests, manual checks, staging verification, or release procedures cover the risky paths
Workflow
-
Identify the release surface.
Determine what is changing in runtime behavior, data shape, deployment sequencing, operator workflow, or external integrations.
-
Look for ordering assumptions.
Check whether deploy, migrate, backfill, flag flip, cache warmup, or client rollout must happen in a specific order.
-
Test backward and forward compatibility.
Ask whether the previous version can run against the new system state and whether the new version can tolerate partially migrated state.
-
Evaluate rollback realistically.
Do not stop at "can revert the code." Check whether data, config, or one-way side effects make rollback unsafe or incomplete.
-
Inspect observability and blast radius.
Verify that failure would be detectable quickly and contained to a narrow scope when possible.
-
Check validation depth.
Prefer targeted release checks over generic confidence language. Name the missing test, rehearsal, or verification step.
Output Style
Prioritize findings that could block or complicate release. For each issue, state:
- what could go wrong
- under which deployment or rollout condition it appears
- why existing validation is insufficient
- what concrete mitigation would reduce the risk
Keep summaries brief. Lead with the highest-severity release risks first.
Common Triggers
Apply extra scrutiny when changes involve:
- schema migrations, backfills, or data rewrites
- new env vars, secrets, or config-dependent paths
- queue, cron, webhook, or worker behavior changes
- auth, billing, cache, or external service integration changes
- feature flag rollout logic or multistep deploy procedures
- changes that require coordination across services, clients, or teams
Non-Goals
Do not turn this into a general architecture review or style review unless those issues create release risk. Stay focused on deployment safety, compatibility, rollback, and operational confidence.
