Run a Deployment Go/No-Go Review With One Reusable Prompt

The release call starts at 4pm. Six people join, someone shares a checklist, and for twenty minutes the room reads questions out loud: tests green? rollback ready? on-call briefed? Half the answers are a shrug and a "probably." That's the meeting a deployment go/no-go review prompt replaces. Not the decision itself, but the part where readiness lives in people's heads instead of on the page.

A go/no-go review is a release gate that asks one question: should this change ship right now, or hold? The honest answer depends on evidence you already have scattered across a CI dashboard, an incident channel, and a few Slack threads. The job is pulling it into one verdict.

This is the same job the Release Train Coordination Harness pack runs across a whole fleet of services. The single prompt below is the per-release core of it.

Why the go/no-go meeting keeps failing

Most teams already own a checklist. The Institute of Project Management publishes a 36-question, nine-section go/no-go template with yes/no answers and weighted scoring. TestCollab has a release-readiness dashboard approach. getDX publishes a production-readiness checklist for dependable releases.

They're all useful. They're also all static. A downloadable file doesn't read your test report, doesn't notice the P2 incident still open from yesterday, and doesn't push back when someone marks "rollback tested" without evidence. You bring the judgment; the checklist just sits there.

A prompt closes that gap. Paste the evidence, get a scored verdict back. Same dimensions every time, no dimension quietly skipped.

What you can do with this prompt

• Score a release across readiness dimensions: tests, rollback, observability, on-call, dependencies, comms
• Get a single verdict, GO, GO_WITH_CONDITIONS, or HOLD, with the reasoning attached
• Surface blockers you'd otherwise discover at 2am, with an owner named for each
• Generate the conditions a conditional-go depends on, so "ship it but watch X" is written down
• Produce a short record of the decision for the audit trail, not just a verbal yes
• Run the same review for a hotfix and a quarterly release without rewriting the criteria

Anatomy of the prompt

The structure is plain: feed the evidence in as variables, lock the verdict format in the output contract.

Variables
  {{release_summary}}    – what's shipping: change set, services touched
  {{test_evidence}}      – CI status, coverage, manual QA notes
  {{open_incidents}}     – active incidents, recent regressions
  {{rollback_readiness}} – rollback method, whether it was tested
  {{signoffs}}           – who has approved, who hasn't

Prompt
  Role: release manager running a go/no-go review.
  Score each readiness dimension 0–2. List blockers with owners.
  Return one verdict and the conditions for a conditional go.

Output contract (locked)
  ## Verdict: GO | GO_WITH_CONDITIONS | HOLD
  ## Dimension scores (table)
  ## Blockers (each: description, owner, severity)
  ## Conditions (only if GO_WITH_CONDITIONS)

The contract is what makes it reusable. Without it, the model writes an essay. With it, every release produces the same shape, so you can diff this week's verdict against last week's.

How to run it

1. Gather the evidence

Pull the CI report, the open-incident list, and the rollback notes into one place. The prompt is only as honest as {{test_evidence}} and {{open_incidents}}. Garbage in, confident garbage out.

2. Fill the variables

Paste each block into its variable. Don't summarize the incident list down to "looks fine", paste the actual open items. The model can't weigh a risk it never sees.

3. Run and read the verdict first

Start at the verdict line. If it's HOLD, jump straight to blockers. If it's GO_WITH_CONDITIONS, the conditions are the part you'll forget by tomorrow, so capture them now.

4. Challenge a clean GO

A flat GO with every dimension at 2 deserves one skeptical pass. Did the prompt have the incident data, or did it score blind? A verdict built on missing evidence isn't a verdict.

5. Record the decision

Save the output next to the release. When something breaks later, the go/no-go record tells you what was known at decision time. That's the difference between a postmortem and a blame session.

Model behavior worth knowing

Claude honors the ## Verdict: heading and the enum reliably; it tends to keep the three states distinct rather than inventing a fourth. GPT-4o needs the enum restated on the final line of the prompt, or it'll soften HOLD into prose like "you may want to consider waiting." Gemini is the most likely to add unrequested sections, so pin the contract hard and tell it to emit nothing outside the four headings.

One more, across all three: a model will happily score rollback_readiness as 2 when you paste "rollback exists." Existing and tested are different things. Word the variable so it captures whether the rollback was actually run, not just whether it theoretically exists.

Variables you'll set

Getting started

1. Copy the prompt skeleton above into ChatGPT, Claude, or Gemini.
2. Paste real evidence into each variable, not placeholders.
3. Lock the output contract with the four headings.
4. Run it and read the verdict first.
5. For a HOLD, route each blocker to its named owner.
6. Save the verdict alongside the release record.
7. Reuse the same prompt next release, unchanged.

For the deeper version of this job, the Production Readiness Review Rubric grades a service across reliability and observability before it ever reaches a go/no-go call.

Once the verdict says go, the next two jobs are writing it up and watching it land. The release-notes prompt that drafts changelogs from git commits handles the announcement, and the CI failure diagnosis prompt is what you reach for if the deploy goes sideways. Pair them with the Release Train Coordination Harness and the meeting that used to eat twenty minutes becomes a paste-and-read.