Rollback Readiness Check
A release safety loop for agents planning or verifying production changes that may require rollback.
Use loop copies the kickoff prompt. Copy Markdown and Download loop include the complete Markdown page with context, source attribution, anchors, and guardrails. Cursor / Claude Code buttons prepare the shorter kickoff prompt only.
Supported agents
Goal
Know how to safely revert the release before shipping it.
Feedback gate
git diff --name-only main...HEADStop condition
Rollback path is documented and destructive/irreversible changes are explicitly acknowledged.
Give the agent these inputs before it starts the loop. This keeps discovery bounded and prevents vague retries.
The loop assumes these commands or integrations are available. Missing tools should be reported as blockers, not ignored.
Two separate pieces: the kickoff prompt starts the loop, while the downloaded Markdown carries the complete reference page.
1. Copy or download
Use the kickoff for a fast agent run. Download the full Markdown when you need source, context, and attribution in one file.
2. Paste into the agent
Start a fresh agent session in the target repo and provide the requested project context if the loop asks for it.
3. Let it self-pace
The agent should act, check evidence, retry only when the gate fails, and stop at the stated exit condition.
The diagram shows the order. This checklist keeps only the action, command, and failure handling needed during a real pass.
1. Identify risky changes
Scan release diff for schema, auth, payments, and deployment config.
git diff --name-only main...HEAD2. Review migrations
Check whether migrations are additive, reversible, or destructive.
3. Find rollback commands
Document how to redeploy previous version and handle DB state.
4. Report go/no-go
State whether rollback readiness is acceptable.
This is the text copied by Use loop. It is intentionally shorter than the Markdown export.
Audit release rollback readiness: risky files, migrations, previous deployment path, data safety, and feature flags. Do not execute destructive commands.
Goal: Know how to safely revert the release before shipping it.
Check command: git diff --name-only main...HEAD
Exit condition: Rollback path is documented and destructive/irreversible changes are explicitly acknowledged.
Max iterations: 3
Guardrails:
- Do not weaken, skip, delete, or rewrite the validation command to force success.
- Do not claim completion until the stated exit condition is actually satisfied.
- If blocked, report the blocker, evidence, and next safest action instead of gaming the metric.
- Do not run destructive migrations or rollback commands without explicit user confirmation.Quality
84/100
Safety
92/100
Expected output
Rollback plan with verified commands, irreversible risks, and owner decisions.
Related loops
Browse allDatabase Migration Review
Review schema and migration changes for destructive operations, D1 compatibility, indexes, and rollback risk.
Kickoff preview
Review database schema and migration changes for D1 compatibility, destructive operations, indexes, and rollback risk. Generate but do not apply production migrations without approval. Goal: Ensure database changes are safe for development and production migration paths. Check command: pnpm db:generate Exit condition: Migration SQL is reviewed and no unexpected destructive operations remain. Max iterations: 4 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not apply production migrations without human review. Do not run destructive SQL automatically.
Deploy Verification Loop
After deployment, check production URL, health routes, metadata, and key user paths before declaring release success.
Kickoff preview
Verify the deployed URL, critical pages, sitemap, robots, and metadata. Fix or report exact failures before declaring the release successful. Goal: Confirm the deployed site responds correctly and key pages are usable. Check command: curl -I $DEPLOY_URL Exit condition: Critical deployed pages return expected status and visible content/metadata. Max iterations: 4 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not claim deployment success based only on build success. Verify the deployed URL.
Cloudflare Worker Smoke Test
Verify a Cloudflare Workers deployment, D1 binding, static assets, and route behavior with targeted smoke checks.
Kickoff preview
Run the Cloudflare build, verify the deployed Worker URL, D1-dependent pages, sitemap, robots, and static assets. Report exact failures. Goal: Prove the Cloudflare Worker deployment is serving critical routes with correct bindings. Check command: pnpm cf:build Exit condition: Cloudflare build and deployed smoke checks pass. Max iterations: 4 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not expose Cloudflare tokens or account IDs in public output.
Ship PR Until Green
Implement a scoped change, open or update a pull request, inspect CI, and continue until all required PR checks pass.
Kickoff preview
Take this branch to a green pull request. Implement the requested change, run local verification, open or update the PR, run `gh pr checks`, inspect failures, fix root causes, and repeat until every required check passes or you hit the iteration cap. Goal: Open or update a pull request and stop only when all required PR checks are green. Check command: gh pr checks Exit condition: All required pull request checks are successful and the PR is ready for review or merge. Max iterations: 10 Guardrails: - Do not weaken, skip, delete, or rewrite the validation command to force success. - Do not claim completion until the stated exit condition is actually satisfied. - If blocked, report the blocker, evidence, and next safest action instead of gaming the metric. - Do not disable required checks, edit loops to skip jobs, or remove tests to make CI green. - Do not merge the PR unless the user explicitly asked for merge authority.