How to Create a Release Readiness Checklist With AI
Turn "are we good for Thursday?" into a checklist that can answer it — every item carrying the evidence behind it, a name, and an honest status, so the ship decision rests on what somebody checked rather than what nobody objected to.
Get the Go/No-Go Checklist PromptSix people on the call, and everybody says yes
Engineering says the tests are green. QA says they're happy with it. Ops says nothing's changed on their side. Support says nobody's told them anything but they'll cope. The release manager asks whether anyone has concerns, waits the customary two seconds, and books Thursday.
Every one of those answers is true. Not one of them is evidence. "We're happy with it" is a feeling somebody had about a thing nobody else in the room can see, and by next week it will be indistinguishable in everyone's memory from a fact that was checked. And the answers that mattered weren't given at all: the two seconds of silence covered four people who assumed somebody else had it, and one who wasn't sure but wasn't going to be the person who moved the date.
A readiness checklist is a coordination artifact, not a quality one
This is what separates it from every other checklist you have. A QA checklist inspects a thing: somebody looks at the artifact and forms a judgment about it. A readiness checklist collects claims from people who each know one part, attaches the evidence behind each claim, and puts a name on it — so that "we're good" becomes "Sam says the rates match the published table, here's the diff, and Sam is the person who'd know."
That difference decides the shape. The items aren't graded, they're owned. They don't carry a score, they carry a link and a person. And the output isn't a verdict about quality — it's a record of who claimed what, on what basis, on which version, on what date. Which is the part that survives: three months later, when somebody asks how this shipped with the dunning emails wrong, the checklist is the only document that can answer, and it answers with a name and a date rather than a shrug.
AI is useful for the shaping. Give it the scope, the evidence you have, the owners, and what you already know is risky, and it will lay the items out, push on the ones you left vague, and ask for the evidence line you skipped. It will also produce a plausible checklist for a release it knows nothing about, which is the failure to watch: a stock item like "security review complete" that nobody requested and nobody owns is worse than absent, because it will be ticked. NewPrompt's part is smaller than that: what it assembles is a prompt, and the browser is where that ends. It has no reach into your CI, your test runner, your issue tracker or your deployment platform; it doesn't read a build status or a test result, doesn't check that any evidence exists or says what you claim it says, doesn't approve a release, doesn't deploy anything, and doesn't complete a single item on the list. A status is a person's claim. "Ready" in a draft means the model wrote the word. You run the prompt in your own AI tool, the owners confirm their own rows against the real systems, and the release owner makes the call and carries it.
Step 1: Turn every "we're good" into a claim with a name on it
Start from the release, not from a template: what's changing, who it reaches, and — the line people skip — what's explicitly outside it. Out-of-scope is where the surprises live. The invoice renderer isn't touched, fine; the dunning email that quotes the invoice total is, and nobody listed it because it's a different team's file.
Then every item gets a person. Not a team — teams don't answer questions, they get asked them. The test is simple: if this row is still ambiguous on Wednesday night, whose phone rings? Write that name. An item without one is a hope with a checkbox next to it.
And each item needs one line saying why it's on the list — what happens if it's wrong. This does more work than it looks like. It's what tells you later whether a row is blocking, it's what makes the difference between "rates match the table" and "a wrong rate is an invoice we cannot re-issue," and it's what kills the boilerplate: an item nobody can write a consequence for isn't a readiness item, it's a ritual.
Step 2: Ask what would have to be true, and where you'd see it
Every item that blocks anything names its evidence: the specific artifact somebody could open. The staging rehearsal log from the ninth. The table diff. The signed-off fixture set. "All tests passed" is not evidence, it's a summary of evidence — which suite, run against what, on which commit, and does it cover the case this row is actually about?
That question is the whole value of the exercise, and it's usually where the checklist earns its afternoon. The rehearsal ran, and it ran against forty accounts, and production has three thousand. The tax advisor's note is real, and it covers rounding, and it's silent on reverse charge. Partial evidence isn't evidence for the part it doesn't cover, and the row that was green until somebody actually opened the link is the most common finding this process produces.
Where the evidence doesn't exist yet, that's a real state and it goes in as itself. The item that reads "nobody has looked at this" is doing more for you than the same item ticked on a guess — and the model can't help you here, because a draft can suggest that a row needs evidence but has no way to know whether yours exists.
Step 3: Use four statuses, not two
Ready. Not ready. Not applicable. Unknown. A two-state checkbox collapses the last two into the first, and they are the two that carry the information.
Unknown means nobody has looked. It's not a soft no — it's a question with a cost attached, and the useful next field is what would settle it and how long that takes. "Unknown, two hours of fixtures" is a completely different conversation from "unknown, needs a week with the tax advisor," and both are different from "not ready." Not applicable means this genuinely doesn't apply to this release, and it's worth writing rather than deleting: a deleted row invites the same person to raise the same question next month, whereas "N/A — different code path, untouched" answers it permanently.
One rule about who sets them, because it decides whether any of this is true: a status is set by the row's owner, never by whoever is drafting the checklist. The drafter's job is to ask; the owner's job is to answer and to be the person who was wrong if it was wrong. A checklist filled in by one person on everybody else's behalf is a document about that person's confidence.
Step 4: Mark the few things that can't be traded
Most blocking items are blocking-until-fixed: they're a Tuesday of work and a re-check. A few are different in kind, and they're the ones a checklist exists to surface. No rollback path for a change that has already reached a customer. A migration rehearsal that has never run at production shape. A rule the team isn't qualified to decide and hasn't had decided for them.
What makes those different isn't severity, it's recoverability. If it goes wrong you can't put it back — you can only apologise, credit-note, and explain. That's not a bigger version of the other rows and it can't be offset by anything on the rest of the list, because nothing on the rest of the list acts on it.
Notice what they have in common in practice: almost all of them are about somebody else's committed state. Money claimed. A number already in a customer's accounting. Data sent to a partner. An email in an inbox. Inside your own system almost everything is recoverable, which is why the unrecoverable ones cluster at exactly the boundary this document exists to coordinate across — and why they tend to be owned by whoever is least present in the engineering conversation.
Step 5: Make an exception cost something
Some things ship known-broken, and that's fine — pretending otherwise just moves the decision somewhere it isn't written down. What isn't fine is a row quietly changing from "not ready" to "ready" between Tuesday and Thursday because somebody decided it wasn't that important.
So an exception is its own object with four parts, and it's the closest thing in this document to a real mechanism:
The expiry is the part that does the work, and it's the part that gets left off. A waiver without one is a decision to never fix it, written in a font that implies otherwise — and everybody involved knows it, which is why the row stops being mentioned. A date, or a trigger, converts "we'll get to it" into something that comes back on its own. Note also who can grant one: not the person who wants it. The engineer who'd rather not fix the dunning email is exactly the wrong person to decide it doesn't matter.
- Who asked for it, and who granted it. Two different people, and the granter is the one who carries it.
- Why — the actual argument, in a sentence somebody could disagree with. "Affects eleven accounts a month and support has been briefed" is an argument. "Low impact" is not.
- When it expires. A date, or a trigger, or both.
- What happens then. Usually: it becomes blocking, and the release isn't clean until it's fixed.
Step 6: Write the decision down against a version
Ship or don't, and then write the sentence: what was decided, on which commit, by whom, when, and — the one that matters — because of what. "NO-SHIP, because R-4 has no correction path for an invoice already issued" is a decision. "NO-SHIP, 70% ready" is a number wearing a decision's clothes, and nobody can act on it.
The version pin is not bureaucracy. Every status on that list is a claim about one specific build; the moment the code moves, the evidence rows move with it, and a checklist that doesn't say which commit it's about is a document with a false expiry date. A green checklist for last Thursday's build is not information about this one.
Then the recheck trigger: what has to change before this gets decided again, and who's watching for it. Because the honest state of most no-ship decisions isn't "no," it's "not until these three things," and if those three things aren't written down as conditions with names, the next conversation starts from the beginning — the same six people, the same two seconds of silence.
Common mistakes
Every one of these produces a checklist that looks complete. That's the problem with the genre: the failed version and the working version are the same shape.
- The stock item nobody asked for. "Security review complete" appears because it appears on every checklist, so it gets ticked by whoever is closest to it, meaning nothing. Items come from this release's risks or they don't come.
- The summary standing in for the artifact. "All tests passed" is a claim about evidence, not evidence. Which suite, which commit, and does it touch the thing this row is about? The rehearsal that passed at forty accounts is the same failure with better manners.
- The team-shaped owner. "Platform" is not an owner. Nobody named Platform will answer at 9pm on Wednesday, and the row will resolve itself by nobody mentioning it.
- The waiver with no expiry. It reads as a temporary accommodation and functions as a permanent decision, made by whoever wanted the release to leave on time.
- The checklist re-used from the last release. Same rows, same owners, different code — and the rows that mattered last time are now the rows people scroll past, because they were green last time.
- Reading it as a clearance. It's a record of what people claimed and what somebody decided — NewPrompt doesn't read your test results, open a single one of those links, or approve anything, and "ready" in a draft is a word the model typed.
A go/no-go for a VAT calculation change
A billing team replaces the VAT rate lookup and rounding on EU invoices. Ten rows, four statuses, one waiver — and a no-ship that has nothing to do with how many of the rows are green. Everything below is fictional.
Ten rows carrying evidence and a name: one unknown that surfaced because somebody had to fill the row in, one row that was green until a link got opened, a waiver with a date and a named granter, and a no-ship decided by one unrecoverable item while six of the ten sat ready or not-applicableRELEASE READINESS — VAT engine v2 checklist v3, 14:20 Tue
SCOPE Replaces the VAT rate lookup and rounding on EU invoices.
Affects: invoice totals for 3,100 EU accounts, monthly billing run.
OUT OF SCOPE US sales tax (untouched). The invoice PDF renderer (untouched).
The dunning emails that quote the total (NOT untouched — see R-7).
──────────────────────────────────────────────────────────────
R-1 Rates match the published table for all 27 member states
Why A wrong rate is a wrong invoice. We do not get to re-issue it; we
credit-note it, and the customer sees both.
Evidence Table diff, v1 vs v2, against the source table. [link]
Owner Sam (billing) Status READY Blocking yes
R-2 Rounding matches the finance spec at the line and the invoice level
Why Rounding per-line and rounding per-invoice differ by cents, and
cents times 3,100 accounts is an audit finding.
Evidence 47 fixture invoices, expected totals signed off by Finance. [link]
Owner Sam Status READY Blocking yes
R-3 Reverse-charge handling for B2B customers with a valid VAT number
Why Charging VAT to a reverse-charge customer is charging them money
they do not owe.
Evidence —
Owner Sam Status UNKNOWN Blocking yes
Note Not 'no'. Nobody has looked. The fixtures in R-2 are all B2C, so
R-2 passing says nothing about this. Sam found this while filling
the row in, which is the row doing its job.
Resolve by: run the B2B fixture set. ~2 hours.
R-4 Rollback path for an invoice already issued with a v2 total
Why The point of no return. Once an invoice is issued the money is
claimed and the number is in the customer's accounting.
Evidence Rollback plan covers the code path. It does not cover issued
invoices, because nothing can. [link]
Owner Ana (platform) Status NOT READY Blocking HARD
^ this is the one. Reverting the deploy un-breaks the next invoice and
does nothing about the ones already sent. There is no amount of
readiness elsewhere that compensates, because the failure is not
recoverable — it is only apologisable. See the DECISION.
R-5 Monthly billing run rehearsed against a production-shaped dataset
Why It has never run at 3,100 accounts. It has run at 40.
Evidence Staging rehearsal, Jul 09: 3,100 accounts, 4m12s, totals matched
the R-2 fixtures. [link]
Owner Ana Status READY Blocking yes
R-6 Tax advisor has reviewed the reverse-charge and rounding rules
Why We are not qualified to decide what the rule is. We are only
qualified to implement the one we are given.
Evidence Written note from the advisor, Jun 28, covering rounding. Silent
on reverse-charge. [link]
Owner Dana (finance) Status NOT READY Blocking yes
Note Partial evidence is not evidence for the part it does not cover.
This row was READY until someone read the note.
R-7 Dunning emails quote a total computed the old way
Why Invoice says one number, the chasing email says another. Support
gets the call, not billing.
Evidence Confirmed by reading the template. [link]
Owner Priya (growth) Status NOT READY Blocking yes -> waived
Waiver Requested by Priya, granted by Dana.
Reason Affects only accounts that go 14 days overdue. Last month:
11 accounts. Support can handle 11 calls; they have been
told what to say.
Expires Aug 15, or the first customer complaint, whichever first.
Then It becomes blocking and the release is not clean until
it is fixed.
^ a waiver with no expiry is a decision to never fix it, written in a
font that suggests otherwise. The date is the whole mechanism.
R-8 Support briefed on what changed and what to say
Evidence Two-paragraph note, sent Jul 14. [link]
Owner Priya Status READY Blocking no
R-9 Feature flag defaults to the old engine on error
Evidence Code review + the fixture for the error path. [link]
Owner Ana Status READY Blocking yes
R-10 US sales tax regression
Owner Sam Status N/A Blocking —
Note Different code path, not touched by this change. Not a gap: this
row does not apply and saying so is worth more than deleting it,
because deleting it invites somebody to ask again next month.
──────────────────────────────────────────────────────────────
DECISION NO-SHIP for Thursday.
Version VAT engine v2, commit 8f2a1c4 Decided Jul 14, 14:20
By Dana (release owner)
Because R-4. Not because of the count.
^ six of ten rows are READY or N/A and the release is not shippable,
and those two facts are not in tension — they are unrelated. R-4 is a
released invoice you cannot take back. R-3 is unknown on a rule that
decides whether we charge people money they do not owe. Neither is a
proportion of anything.
Not blocking the decision: R-7 — which blocks by default. The waiver is the
thing that makes it not block, granted by someone who is not Priya, expiring
Aug 15. That is a different kind of no from R-4, and the difference is that
somebody signed for it.
RECHECK When R-4 has a documented correction path (credit-note procedure,
agreed with Finance, rehearsed) AND R-3 is resolved either way AND
R-6 covers reverse-charge. Re-decide then, against this version.
If the code moves, the evidence rows move with it — this checklist
is about commit 8f2a1c4 and nothing else.
WHAT THIS IS FOR, LATER
In November somebody will ask why v2 shipped with the dunning email wrong.
The answer is on this page, with a date and Dana's name on it, and it is a
good answer. That is the artifact: not the ten rows, the one paragraph that
survives the argument.
Nothing here was checked by a tool. Every status is a person's claim, every
link is a thing somebody has to open, and the decision is Dana's. Fictional
company, fictional invoices, fictional people.Where this fits in NewPrompt
The Release Readiness Checklist Prompt is the nearest starting point and the honest place to begin: a copy-paste prompt that walks ten operational areas — config, secrets, migrations, flags, rollback, monitoring, dependencies, comms, backups and capacity — and ends in a single GO or NO-GO with the blockers named. It asks for a status and a one-line reason per area, which is more than most teams have written down. What it doesn't carry is the apparatus this guide is about: no evidence field, no owner, no blocking flag, no waiver, no unknown as a state distinct from a no, and no version or date on the decision. Its own FAQ is blunt about the ceiling, and the sentence is the right one: a GO "means every checklist item you reviewed came back READY (or N/A), not that the release is guaranteed to succeed" — and it "doesn't deploy anything, verify your environments, or test that the migrations actually run."
Building that prompt is what Markdown Output Builder does, and it ships a genuine readiness preset rather than a blank form: five topic sections and a Go/No-Go heading, with the order pinned. Two gaps to know before you lean on it. There is no input slot. The contract it emits opens by declaring, flatly, that "there is no source text to summarize" — so your own release has to be typed into the goal field, or pasted in after. And the status vocabulary is simply not there. The prompt's own instruction to mark each item READY, NOT READY or N/A with a one-line reason has no counterpart anywhere in the preset; only the GO/NO-GO survives, as the last section's description. The topic sections say what to cover, not how to mark it, and the row schema this guide argues for is not a thing a section list can express at all.
Two things sound like this checklist and are not it, and the difference is worth a sentence each. The Production Readiness Review reads a pull request — you paste the diff, it returns severity-tagged findings and a SHIP or DO NOT SHIP on the code. It's a code review with a deployment verdict, and it has no owners, no evidence links and no waivers, because that isn't its job. It answers "is this change safe to deploy?"; this checklist answers "is the organisation ready for it to arrive?", and a release can pass one and fail the other in either direction. The Rollback Plan Prompt is one row on your list made into a document — and, as the worked example shows, the row where an honest answer sinks a release more often than any other.
One level up, the AI Deployment & Release Workflow has a readiness step of its own — and it is the code-review flavour, a verdict on a diff rather than on an organisation. That is the distinction worth not glossing: the go/no-go and the code review are two gates that happen to share a name, they are owned by different people, and passing one tells you nothing about the other. A clean diff does not mean support has been told. NewPrompt gives you the wording and the sequence; running them, and carrying what gets decided, is yours.
The checklist's second life is the one that justifies the first. In November somebody asks how this shipped with the dunning emails wrong, and there are two ways that conversation goes. One is a room reconstructing a Tuesday from memory, where everyone is sincere and nobody is reliable and the answer arrives as a vibe about how it was probably fine at the time. The other is a page with Priya's request, Dana's grant, the eleven accounts, the fifteenth of August, and 14:20 on the fourteenth of July. The second one is not a better excuse. It's just true, and it took an afternoon.