---
name: "launch_day_ops"
description: "Runs a product launch day end to end: builds the minute-by-minute runbook, staffs the war-room roles, handles the go/no-go gate, and drives post-launch triage. Use when someone says 'launch day', 'go live', 'runbook', 'war room', or needs help triaging problems right after a release."
metadata: { "includeInPrompt": true }
---

# Launch Day Ops

## Purpose

Turn launch day from chaos into a checklist. This skill produces a complete launch-day plan: the T-minus timeline, named owners for every line, the go/no-go decision gate, rollback triggers decided in advance, and a post-launch triage protocol with severity levels and comms cadences. It covers both the marketing side (press, email, social, community launch) and the technical side (deploy, flags, monitoring, rollback). Adapt the depth to the launch tier: a Tier 1 public launch gets the full runbook, a quiet Tier 3 feature flag flip gets the short version.

## Workflow

1. **Classify the launch.** Ask for the tier if it is not obvious:
   - Tier 1: public launch (press, Product Hunt, email blast, big feature). Full runbook, war room, all roles.
   - Tier 2: notable release (blog post, customer email, no press). Medium runbook, launch channel, core roles.
   - Tier 3: quiet ship (feature flag, in-app nudge). Short checklist only.
2. **Collect the inputs.** Product name, launch date/time and timezone, deploy method (flag flip, rolling deploy, big-bang), key contacts per role, launch channels, critical user flows, rollback mechanism. Do not invent these; ask for what is missing.
3. **Build the runbook.** Use `bin/runbook_gen.py` (see Tooling) to generate the filled timeline from the inputs, or write it by hand for Tier 3. The runbook must have, for every action line: the time, the action, and exactly one named owner. No ownerless lines, ever.
4. **Run the go/no-go gate.** At T-24h (Tier 1) or T-4h (Tier 2/3), walk the readiness checklist from `references/runbook-templates.md`. Every gate is PASS or FAIL with evidence. Any FAIL means NO-GO unless a named approver accepts the risk in writing with a mitigation and rollback plan.
5. **Execute the timeline.** On launch day, work the timeline top to bottom. Check error rates at T+15min, T+1hr, T+4hr. If rollout is staged by flag, expand 5-10% first, then 50% after T+2hr checks pass, then 100% after T+4hr checks pass.
6. **Triage what breaks.** Classify every issue with the severity matrix (references). SEV-1 opens the war room immediately with all roles. Mitigate before diagnosing: roll back, fail over, flag off, or shed load first, and investigate after the bleeding stops.
7. **Close out.** Confirm sustained recovery before declaring resolution (never close on one green dashboard). Log the timeline, run the 48-hour SEV-1/SEV-2 postmortem, and file every SEV-3/4 as a ticket.

## Tooling

`bin/runbook_gen.py` generates a filled runbook markdown from a JSON config:

```bash
python3 ~/workspace/skills/launch-day-ops/bin/runbook_gen.py config.json -o runbook.md
```

Minimal config (see `references/runbook-templates.md` for the full schema):

```json
{
  "product": "Acme Widget",
  "launch_time": "2026-10-02T09:00:00-05:00",
  "tier": 1,
  "roles": {
    "launch_lead": "Maya",
    "deploy_operator": "Jon",
    "qa_lead": "Priya",
    "comms_lead": "Leo",
    "oncall_engineer": "Sam",
    "comments_owner": "Nadia",
    "amplify_owner": "Chris"
  },
  "critical_flows": ["signup", "checkout"],
  "rollback": "feature flag acme_widget_v2 -> off; redeploy 1.4.2 tag"
}
```

Every role in the config maps to exactly one name. The generator fails loudly if any required role is missing or unnamed.

## Output Contract

A launch runbook always contains, in this order:

1. **Header**: product, launch time (with timezone), tier, decision owner, rollback owner.
2. **T-minus timeline**: T-24h through T+4hr, each line with time, action, owner.
3. **Go/no-go checklist**: the gates, each with owner and evidence.
4. **Rollback triggers**: automatic triggers (error rate above X% of baseline, a critical flow broken, data integrity issue, security issue) and who calls rollback.
5. **War-room roles table**: role, name, responsibility, contact.
6. **Triage matrix**: severity definitions, response times, comms cadence.
7. **Status-page and comms templates**: pre-written, ready to paste.
8. **Post-launch checklist**: T+24hr and T+1week follow-ups.

For Tier 3, sections 4 and 7 may be one-liners, but sections 2, 3, and 6 are always present.

## Operating Rules

1. One name per line. If an action has no owner, the runbook is not done.
2. Freeze scope at T-24h for Tier 1: no new copy, features, or channels after the freeze. Changes after the freeze go through the launch lead.
3. Decide rollback triggers BEFORE the launch, not during the incident. The launch lead (or named deputy) calls rollback; nobody debates the call mid-crisis.
4. Mitigate before diagnosing. A recent change that likely broke things gets rolled back first, investigated later. Forward-fixes during an incident are a last resort.
5. Communicate on cadence even with no news: SEV-1 every 15 min, SEV-2 every 30 min, SEV-3 hourly or on change. "Still investigating, next update in 15 min" beats silence every time.
6. Never close an incident on a hopeful dip. Resolution requires sustained recovery, then a postmortem for SEV-1/2.
7. All severity ratings, comms templates, and checklists live in `references/runbook-templates.md`; keep SKILL.md to the workflow.