launch-execution

Files (7)

• SKILL.md
• launch-day-protocol.md · references/
• launch-day-sequence.md · references/
• pre-ship-state-verification.md · references/
• rollback-plan-template.md · references/
• staging-regression-checklist.md · references/
• war-room-setup.md · references/

SKILL.md (first lines)

# Launch Execution

You handle everything needed to safely ship a product to production and survive launch day. This skill covers staging regression, production readiness verification, rollback plans, war room coordination, launch-day sequencing, monitoring protocol, hotfix procedures, and support channel setup.

## When this skill triggers

This skill activates when a developer is preparing for a production deployment, planning a launch day, setting up rollback procedures, configuring monitoring for launch, or coordinating engineering and marketing teams for a public launch (Product Hunt, Hacker News, etc.).

---

## Staging Full Regression

Reference: `references/staging-regression-checklist.md`

Before any production deployment, run a full regression against staging. This is your last safety net before real users see your code.

### Regression categories

| Category | Tests | Priority |
|----------|-------|----------|
| Auth flows | Login, signup, password reset, OAuth, session expiry | P0 |
| Core features | Primary user journey end-to-end | P0 |
| Payment flows | Checkout, subscription, webhook handling | P0 |
| Email flows | Transactional emails render and deliver | P1 |
| Edge cases | Empty states, long inputs, concurrent actions | P1 |
| Mobile/responsive | Breakpoints at 375px, 768px, 1024px, 1440px | P1 |
| Performance | Core Web Vitals, API response times < 200ms | P2 |
| Security | Auth bypass, XSS payloads, CSRF tokens | P0 |

### Regression test protocol

1. Deploy the exact release candidate to staging
2. Run automated test suite (`npm test && npx playwright test`)
3. Manual walkthrough of critical paths (auth, core action, payment)
4. Test on at least 2 browsers (Chrome + Safari/Firefox)
5. Test on at least 1 mobile device or emulator
6. Verify transactional emails with real inbox (not just logs)
7. Check error tracking (Sentry) for zero new errors on staging

<!-- beginner -->
**Run a staging regression** — Before you push to production, test every important user flow on your staging environment. Staging is a copy of production where mistakes are safe. Go through each category in the checklist: can a new user sign up, log in, do the core action, pay, and receive emails? If anything fails, fix it before deploying. This is the highest-leverage hour you will spend.
> Time: ~1-2 hours
> Template: See `references/staging-regression-checklist.md`

<!-- intermediate -->
**Staging regression** — Deploy exact release candidate to staging. Run automated suite. Manual walkthrough of auth, core flow, payment, and email. Cross-browser (Chrome + Safari). Mobile check. Verify Sentry shows zero new errors. Use the staging checklist to track completion.
> ~1 hour

<!-- senior -->
**Staging regression** — RC on staging. Automated suite green. Manual critical-path sweep. Cross-browser + mobile. Sentry clean. Sign off on staging checklist before proceeding.

---

## Pre-Ship State Verification

Reference: `references/pre-ship-state-verification.md`

<!-- beginner -->
**Test every state your users will see** — Before shipping, open your app in an incognito window and check: what happens when there's no data? What happens when the network is slow? What happens when something breaks? If you haven't seen a state, your users will see it first. The pre-ship checklist walks you through every state page-by-page, then checks global things like navigation, modals, themes, and accessibility.
> Time: ~30 min for a small app, ~1-2 hours for a larger one
> Reference: See `references/pre-ship-state-verification.md`

<!-- intermediate -->
**Pre-ship state verification** — Binary pass/fail checklist for every UI state. Per-page: empty, loading (3G throttle), populated, error (kill API), mobile (375px), tablet (768px). Global: navigation, modals (focus trap, escape, scroll lock), auth boundaries (redirect + return), themes (parity, persistence, no flash), accessibility (reduced motion, tab order, skip link, labels), performance (first paint, layout shift, lazy loading).
> ~30 min – 2 hours | `references/pre-ship-state-verification.md`

<!-- senior -->
**Pre-ship state verification** — Per-page state matrix (empty/loading/populated/error/mobile/tablet) + global checks (nav, modals, auth boundaries, theme parity, a11y, performance). Binary pass/fail. Different from design audit (analytical) — this is "did you TEST this?"
> `references/pre-ship-state-verification.md`

---

## Production Readiness Verification

Before flipping the switch, verify every operational concern is handled.

### Production readiness checklist

```
Environment & Config
├── Environment variables set in production (not hardcoded)
├── Production database connection string verified
├── Third-party API keys are production keys (not test/sandbox)
├── Feature flags set to intended launch state
├── Rate limiting configured and tested
└── CORS origins restricted to production domains

Data & Persistence
├── Database migrations applied and verified
├── Seed data removed / test data cleaned
├── Backup strategy confirmed (automated daily minimum)
└── Redis/cache connection verified

Monitoring & Alerting
├── Error tracking active (Sentry/Bugsnag)
├── Uptime monitoring configured (Betteruptime/Checkly)
├── Log aggregation working (structured JSON logs)
├── Key metric alerts set (error rate > 1%, p95 > 2s)
└── On-call rotation established (even if it is just you)

Security
├── HTTPS enforced (HSTS header present)
├── Security headers configured (CSP, X-Frame-Options)
├── Secrets not in source code (gitleaks clean)
├── Auth rate limiting active
└── Admin endpoints protected

DNS & Networking
├── DNS records pointed to production
├── SSL certificate valid (not expiring within 30 days)
├── CDN configured for static assets
└── Custom domain verified
```

<!-- beginner -->
**Verify production readiness** — Go through every item in the production readiness checklist above. The most common launch-day failures are: wrong API keys (still using test keys), missing environment variables, database not migrated, and monitoring not turned on. Check each one manually. When in doubt, open a production shell and verify the value directly.
> Time: ~30-45 min

<!-- intermediate -->

From harmansidhudev/shipwise, MIT.

More from harmansidhudev/shipwise