Use launch-readiness

Produce a go/no-go launch readiness report for a merged change before it goes live

Produce a go/no-go launch readiness report for a merged change before it goes live — one row per check (rollback path, alert and runbook per new failure mode, NFR targets measured, comms drafted, data/privacy sign-off), each with an owner, evidence link, and met / not met / n/a-because status, ending in a PROCEED / PROCEED WITH CONDITIONS / REVISE / BLOCKED verdict.

Reach for it when the user asks "are we ready to launch", "go/no-go", "production readiness review", "launch checklist", or "can we ship this to users".

Install it

npx skilldrop-cli install launch-readiness                 # Claude Code, your user folder
npx skilldrop-cli install launch-readiness --project       # Claude Code, this repo
npx skilldrop-cli install launch-readiness --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

"Are we ready to launch this to users on Monday?"
"Run a go/no-go check on the checkout redesign before we turn it on"
"Do a production readiness review for the new search service"
"Give me a launch checklist for this release and tell me what's missing"

Requests like these belong to a different skill, so it shouldn't answer them:

"Is this PR safe to merge?"
"Plan the phased rollout and backfill for moving users to the new auth provider"
"Write the release notes for everything since v2.3"

If another skill answers instead, ask for this one by name: "use launch-readiness".

Check what you get

A good result:

Every row has evidence or is not met. Readiness asserted is not readiness.
The failure modes are specific to this change. "The service could go down" is true of everything and checks nothing.
Rollback is judged first and can block alone. Every other gap can be fixed while live; an irreversible launch with no way back cannot.
The verdict follows mechanically from the rows. Two reviewers given the same rows reach the same verdict.
Owners are roles. "Payments on-call", not a person who will change teams.

See a worked example

schema change revise

Use something else when

Deciding whether to merge. That is pre-merge-review's gate, which happens earlier.
Planning the rollout phases themselves. That is migration-plan; this skill checks that the plan exists and has been rehearsed.
Choosing when to launch. Timing and freeze windows are the release owner's call, or council-review's if they are contested.

Where a loop runs it

Stage cutover of the modernize loop, where gate G10.1 decides
Stage ready of the release loop, where gate G3 decides

SKILL.md, the instructions the agent reads
Its page on the site
Related: migration-plan, observability-plan, runbook-generator, nfr-spec, release-notes, council-review, pre-merge-review

Edit this page on GitHub · View source