Launch Readiness skill for Claude Code

A launch is ready when every item that could hurt customers, the business, or the team has an owner who has signed off against an objective criterion, the team knows exactly what signal triggers a rollback and who pulls it, and the people who will field questions (support, sales, success) have what they need before customers ask. “Feels ready” is not a criterion.

Ground rules

• Tier the launch first; the checklist scales with the tier. A copy change does not need a go/no-go meeting; a pricing change does.
• Every checklist item has one owner, a status (Go / No-go / N/A with reason), and evidence (link to test run, dashboard, doc, ticket).
• Exit criteria are objective: “0 open P0/P1 bugs”, “p95 latency ≤ 300 ms at 2x peak in load test”, not “QA is happy”.
• Rollback is tested before launch, not designed during the incident. Prefer a feature flag kill switch over a redeploy.
• Rollout is staged with written promotion gates and kill criteria.
• The decision is recorded: who decided, what was known, which risks were accepted.
• Production deploys, data migrations, and flag flips to 100% happen only with explicit confirmation from the accountable owner; Claude prepares the checklist and plan, it does not trigger them.

Launch tiers

Tier	Examples	Readiness process
T1	New product, pricing or packaging change, breaking API change, major redesign	Full checklist, go/no-go meeting with leads, staged rollout, comms plan, war room on launch day
T2	Notable feature for a segment, new integration, workflow change	Full checklist async sign-off, staged rollout, support and docs required
T3	Small improvement, internal tool, minor UI change	Short checklist: tests, flag, monitoring, changelog

If unsure, pick the higher tier. Anything touching billing, permissions, data deletion, or a public API is at least T2.

Workflow

- [ ] 1. Set tier, launch owner, target date, and the go/no-go date (T-2 to T-5 business days for T1/T2)
- [ ] 2. Generate the checklist for the tier; assign owners
- [ ] 3. Define success metrics, guardrails, rollout stages, and kill criteria
- [ ] 4. Owners collect evidence; track status daily in the final week
- [ ] 5. Dry-run the rollback in staging (or production with the flag off)
- [ ] 6. Hold the go/no-go review; record the decision
- [ ] 7. Execute staged rollout; check gates at each stage
- [ ] 8. Post-launch review at T+7 / T+30 days

Readiness checklist (condensed)

The full checklist with criteria per item is in references/checklist.md; read it when generating the checklist for a T1 or T2 launch. Condensed version:

Area	Go criterion (default)	Owner
Scope	All P0 requirements done and demoed; known gaps listed	PM
Quality	0 open P0/P1 bugs; P2s triaged with dates; regression suite green	QA / eng lead
Performance	Load test at ≥ 2x expected peak; p95 within SLO; no new N+1 or hot queries	Eng
Security and privacy	Threat review done for new data flows; PII handling reviewed; pen-test findings ≥ high closed	Security
Data	Migrations tested on production-size copy; backfill time known; reversible or backed up	Eng / data
Observability	Dashboard for success metrics and guardrails; alerts with runbook links; error tracking tagged	Eng
Rollback	Kill switch or rollback tested; time to roll back known (target ≤ 15 min)	Eng
Support	Help article, macros, internal FAQ, escalation path; support trained	Support lead
Sales / CS	Enablement doc, pricing and packaging FAQ, demo ready; customer comms for affected accounts	PMM / CS
Legal / compliance	Terms, DPA, accessibility (WCAG 2.2 AA for new UI), regional requirements	Legal
Comms	Changelog, in-app announcement, email, blog as per tier; internal announcement	PMM
Analytics	Events instrumented and verified in production-like env	PM / data

Rollout stages and gates

Stage	Audience	Minimum duration	Promote when	Kill when
0	Internal / employees	2–3 days	No P0/P1 found; dashboards show data	Any data loss or security issue
1	1–5% of users or beta accounts	2–7 days	Error rate and latency within guardrail; no spike in tickets	Error rate > baseline + 0.5 pt, or p95 latency > SLO for 15 min
2	25–50%	3–7 days	Success metric trending to target; guardrails flat	Guardrail breach sustained 1 h; support tickets > 2x baseline
3	100%	—	—	Same as stage 2

Adjust durations to traffic: each stage needs enough exposure to see problems (as a rule of thumb, ≥ 1,000 active users or a full weekly cycle for low-traffic products). For measuring impact rather than safety, run a proper experiment (see experiment-analysis); use feature-flags for the flag mechanics.

Go/no-go meeting

• 30 minutes, launch owner facilitates. Attendees: owners of each area, decision maker.
• Walk only the exceptions: items not Go. Do not re-read green items.
• For each No-go item: fix before launch, launch with accepted risk (decision maker names it), or delay.
• Decision options: Go, Go with conditions (named, owned, dated), No-go (new date and what must change).
• One person decides. Consensus is welcome, not required.

Go/no-go record

# Go/no-go: <launch> — <date>
Tier: T1   Launch owner: <name>   Decision maker: <name>
Decision: Go with conditions
Conditions: Help article published before stage 2 (owner: Support lead, due Oct 28)
Accepted risks: P2 #4821 export column order on Safari — workaround documented; fix by Nov 4
Rollout: stage 0 Oct 24 → stage 1 Oct 27 → stage 2 Oct 30 → 100% Nov 4 (gates as per plan)
Kill switch: flag `bulk_exports`; on-call can disable; tested Oct 22 (rollback 2 min)
Launch-day contacts: eng on-call <name>, support <name>, comms <name>
| Area | Status | Evidence | Owner |

Gotchas

• Checklist theater. Items ticked without evidence. Require a link for every Go.
• Rollback that only works one way. A migration that drops a column cannot be rolled back by a redeploy. Expand-contract migrations or backups first.
• Support learns from customers. Train support before stage 1, not after the first ticket.
• Launching Friday or before a holiday with nobody watching dashboards. Default to Tuesday–Thursday mornings in the team’s time zone for T1/T2.
• No kill criteria written. Teams then debate during the incident whether it is bad enough. Write thresholds beforehand.
• Marketing date fixed before readiness. Set the public date after the go/no-go, or keep a buffer of at least one week for T1.
• Forgetting downstream consumers: API clients, data pipelines, partner integrations, mobile apps on old versions.

Verification

• Every checklist item has an owner, status, and evidence link, or N/A with a reason.
• Rollback was rehearsed and its duration recorded.
• Rollout stages have numeric promote and kill thresholds tied to live dashboards.
• The go/no-go record names the decision maker, conditions, and accepted risks.
• A post-launch review is on the calendar with the success metrics to check.

Output contract

# Launch readiness: <launch>
Tier: <T1/T2/T3>  Owner: <name>  Target: <date>  Go/no-go: <date>
Success metrics: <metric baseline → target>  Guardrails: <list>

## Checklist
| Area | Item | Criterion | Owner | Status | Evidence |
## Rollout plan
| Stage | Audience | Dates | Promote when | Kill when |
## Rollback plan (mechanism, who, tested on, duration)
## Comms plan (internal, customers, timing)
## Open risks
## Decision record