Skills · dev-team

`launch-readiness`

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. Use when the user asks "are we ready to launch", "go/no-go", "production readiness review", "launch checklist", or "can we ship this to users".

Pack dev-teamTier standardJob Run and recover the servicev0.1.0

npx skilldrop-cli install launch-readiness

Other ways to install

With the sibling skills it hands off to:

npx skilldrop-cli install launch-readiness --with-related

The whole pack it belongs to:

npx skilldrop-cli install --pack dev-team

By hand, from a clone of the repo:

cp -R packs/dev-team/skills/launch-readiness ~/.claude/skills/

In Claude Code, with the dev-team plugin installed, invoke it as:

/dev-team:launch-readiness

Try it

A realistic prompt from the skill's acceptance evals:

Are we ready to launch? PR #412 adds a `loyalty_points` column to `customers`, backfills it from order history, and shows points on the checkout page. Going to 100% of users Thursday. Load test hit p99 180ms against a 250ms target (link: grafana/d/lt-412). We have a dashboard but haven't added alerts yet. Support hasn't been told.

What a good result looks like

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.

Example output

schema change that comes out REVISE · the skill's own worked example, source

Input

Go/no-go for release orders-v4.2. It splits orders.address into shipping_address_id pointing at a new addresses table. We followed the migration plan (docs/migrations/orders-address.md): expand and backfill are done in staging, and dual-write is behind the flag orders.address_split. Rollback is "turn the flag off". It was rehearsed in staging on 2026-09-28 (log: ci/run/88213). The p99 target for order reads is 120ms, and the canary at 5% shows 96ms (grafana/d/orders-canary). The existing orders-5xx alert covers this. Release notes are drafted in PR #977. Plan is 5% → 50% → 100% over three days.

Output

Launch readiness — orders-v4.2 (address split)

Change: release orders-v4.2 · Reach: 5% → 50% → 100% over 3 days · Release owner: Orders tech lead Assessed: 2026-10-01 · Inputs: migration plan, staging rollback log, canary dashboard, PR #977

New failure modes

#	Failure mode	Who is hurt	Reversible?
F1	Dual-write diverges: an order is saved with an `addresses` row that doesn't match `orders.address`	Customers shipped to the wrong address	Partly. Data can be fixed, parcels already sent cannot
F2	The read path picks the new column before the backfill is complete for that tenant	Customers who see a blank address at checkout	Yes, by turning the flag off
F3	The extra join pushes order reads past p99 under full load	All checkout users	Yes, by turning the flag off

Checks

#	Check	Covers	Status	Evidence	Owner
1	Rollback	all	met	Flag-off rehearsed in staging, ci/run/88213. While the old column is still written, flag-off loses no data	Orders on-call
2	Detection	F1–F3	not met	`orders-5xx` catches F3 errors only. Nothing detects F1 divergence or F2 blank reads, because both return 200	Orders on-call
3	Response	F1–F3	not met	There is no runbook entry for divergence. `orders-5xx` has a runbook entry, but it does not mention the flag	Orders on-call
4	Quality targets	F3	met	Canary p99 96ms against a 120ms target at 5%, grafana/d/orders-canary	Orders tech lead
5	Data & privacy	—	n/a — no new personal data. Address data moves between tables, and retention and processors are unchanged	Migration plan §2	Data protection lead
6	Comms	—	met	Release notes drafted in PR #977. No customer-visible change	Orders tech lead
7	Exposure	—	met	Staged 5% → 50% → 100% behind `orders.address_split`	Release owner

Open items

Row 2: add a reconciliation metric for dual-write divergence, and an alert on any non-zero count, plus an alert on blank-address reads. Orders on-call, before the 5% → 50% step. Hand off to observability-plan.
Row 3: add a runbook entry for "divergence alert fires" (flag off, then run the reconciler), and add the flag to the orders-5xx entry. Orders on-call, same deadline. Hand off to runbook-generator.

Verdict

REVISE. Row 2 is not met: the two failure modes that do lasting damage (F1, F2) return 200, so nothing would detect them. Fix rows 2 and 3, then run readiness again.

Why this is a good output: the rollback is genuinely in place, so the verdict is REVISE and not BLOCKED. The report notices that an existing alert covering the change only catches the failure that is easiest to undo. It does not draft the alert or runbook itself; it names the gap, the owner and the hand-off.

How it's checked

Measured against plain Claude Code (2026-10-23): it met 79% of its checks, against 51% without it, and a blind judge preferred it. How skills are checked

21 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks

What the output must do

Lists 3-5 failure modes specific to this change (e.g. backfill load on customers, wrong point totals shown at checkout) before the checklist
Every check row has a status of met, not met, or n/a with a reason, plus an evidence column and an owner expressed as a role
Rollback is the first row and is not met, because no tested rollback or data story was supplied
Detection is not met because no alerts exist, and the report hands off to observability-plan rather than drafting the alert inline
The quality-targets row is met and cites the supplied load-test link as evidence
Exposure is flagged because a 100% launch is not staged and no reason is given for why all-at-once is safe
The verdict is BLOCKED, and the reason given is the missing rollback
No dashboards, test results, or sign-offs are invented beyond what the prompt supplied
Does not say the launch is green; it recommends not launching on Monday as planned until the named problems are fixed
Catches that the load test only sustained 1,200 messages per minute, with rate limiting above 1,250, against an expected peak of 1,500, which contradicts the brief's 'tested at 3x peak'
Catches that the SMS template includes the medication name, which the privacy sign-off explicitly does not approve
Catches that turning the flag off does not undo migration 0042, which drops patients.reminder_opt_in, so the stated rollback is not a full one
Notes that no alerts exist yet and that switching on all 140 stores at once leaves no staged rollout
Does not invent evidence, owners' names, dates or test results that are not in the files
Fits on one page
Does not declare the studio ready, because nothing has been shown beyond the setup person saying it is done
Gives a short checklist, not a long report
Includes trying a real booking from start to finish, including payment and a cancellation or refund
Includes a fallback for if the booking system fails on the day (for example taking bookings by phone or on paper) and telling customers about the change
Uses plain language a studio owner can follow
Does not invent details of their booking system, prices or policies

When it should and shouldn't activate

Should activate:

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

Should leave to another skill:

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
Write the runbook for the payments service

Hands off to

migration-plan — when the change has no tested rollback path. Plan the phases and the rollback, and name the point of no return, before readiness is judged again.
observability-plan — when a new failure mode has no alert. Define the SLI and the burn-rate alert that would detect it.
runbook-generator — when an alert exists but has no runbook entry. Write the procedure the on-call follows when that alert fires.

Source

SKILL.md · the whole folder on GitHub.

launch-readiness