Release Readiness Review
Run a go/no-go release readiness review against a structured pre-launch checklist and produce a sign-off report with a clear ship decision. First scopes the release and locks a readiness checklist (acceptance criteria met, tests and CI green, no open blockers, migrations and rollback ready, monitoring and alerts in place, docs and changelog updated, feature flags and config set, and on-call/comms prepared), then verifies each item by inspecting the actual state rather than assuming, then writes a go/no-go report listing every blocker that must clear before ship and the residual risks. Use this for a release readiness review, a go/no-go decision, a pre-launch checklist, a ship-readiness gate, a launch review, or deciding if a change is safe to deploy — it produces an evidence-backed ship decision rather than a gut-feel 'looks good'.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the readiness checklistreviewerentry
lock the release scope + a go/no-go checklist
Show working prompt
Step 1: Define the release: what is shipping (features/changes), to whom, and the rollout mechanism (full deploy / staged / flagged). Step 2: Write a readiness acceptance-criteria checklist covering: the feature's own acceptance criteria are met; the test suite and CI are green; there are no open blocking bugs or unresolved review comments; database migrations are reversible and a rollback path exists; monitoring, logging, and alerts cover the new code; user-facing docs, release notes, and changelog are updated; feature flags and config/secrets are set correctly for the target env; and on-call ownership and a comms/rollback plan are ready. Step 3: For each item, state the concrete pass condition and HOW it will be verified (where to look). Step 4: Mark which items are hard blockers vs advisory. Write the release definition + checklist to `write_task_note` AND `{{workPath}}/scope.md`. No verification yet. The deliverable `{{workPath}}/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched. - Verify readinessdeveloper
check each item against the real state
Show working prompt
Step 1: For EACH checklist item, VERIFY the actual state — do not assume. Run/inspect the tests and CI status; search for open issues/TODOs/blocking review comments; check that the migration has a down path and that a rollback is documented; confirm alerts/dashboards reference the new code paths; open the docs/changelog/release notes to confirm they are updated; check the flag and config/secret values for the target environment; confirm on-call and the rollback/comms plan exist. Step 2: For each item record PASS/FAIL/NA with the EVIDENCE (the command output, the file, the config value, the issue link) — a claim without evidence is not a pass. Step 3: Classify every FAIL as a hard blocker or an accepted risk. Step 4: Note residual risks even where items pass (e.g. 'migration is reversible but locks the table for ~30s'). Good looks like: every item backed by an observation, not 'should be fine'. Stage the verification log to `write_task_note`. Do not write the report yet. The deliverable `{{workPath}}/verify.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched. - Write the go/no-go reportreviewer
ship decision + blockers + residual risk
Show working prompt
Step 1: Open `{{workPath}}/release-readiness.md` and write the DECISION at the top: GO / NO-GO / GO-WITH-CONDITIONS, in one sentence with the deciding factor. Step 2: Add a '## Checklist' table: each item with PASS/FAIL/NA and its evidence. Step 3: Add a '## Blockers' section listing every must-clear item before ship, with the concrete action to clear it and an owner. Step 4: Add a '## Residual risks' section (accepted risks and watch-items for after deploy) and a '## Rollback' note summarizing how to back out. Step 5: If GO-WITH-CONDITIONS, list the exact conditions. The decision must follow from the evidence — no GO with an open hard blocker. On a loop-back, fix only the named gaps. `write_task_note` the report path, the decision, and the count of open blockers. The deliverable `{{workPath}}/release-readiness.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched. - Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open `{{workPath}}/release-readiness.md` with `read_artifact` first, then review it against the original scope: every claim cites a real path, the severities and priorities are defensible, and nothing important in scope was skipped. Open the underlying files for at least the top findings; do not grade from the report's own summary. If a finding cannot be verified, say so explicitly. Write your review to the artifact `{{workPath}}/review.md` with one `write_artifact` call: what you checked, what held, what did not (as a findings table with columns `| Severity | File | Line | Problem | Fix |` when anything needs fixing), ending with exactly `Verdict: PASS` or `Verdict: REVISE`. The gate enforces the verdict: a well-formed REVISE is routed back to the `report` step automatically with your findings. On PASS, `advance_task_step` to `finish`. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- release readiness review
- are we ready to ship
- go no go decision
- pre-launch checklist
- is this safe to deploy
- ship readiness review
Source
View this craftbook on GitHub · MIT license