Ship production releases with confidence and safety

A shipping and launch process built on making every deploy reversible, observable, and incremental. A pre-launch checklist covers six categories: code quality (all tests pass, clean build/lint, code reviewed, no debug console.log or unresolved TODOs); security (no committed secrets, no critical/high npm audit findings, input validation, auth checks, security headers, rate limiting on auth endpoints, CORS scoped to specific origins); performance (Core Web Vitals within Good thresholds, no N+1 queries, optimized images, bundle size budget, indexed queries, caching); accessibility (keyboard navigation, screen reader support, WCAG 2.1 AA color contrast, correct focus management, descriptive error messages, no axe-core/Lighthouse warnings); infrastructure (env vars set, migrations applied, DNS/SSL/CDN configured, logging and error reporting wired up, a working health check endpoint); and documentation (README, API docs, ADRs, changelog, user-facing docs all current). Features ship behind flags to decouple deployment from release, following a five-stage lifecycle - deploy with the flag off, enable for team/beta, gradual rollout (5% to 25% to 50% to 100%), monitor at every stage, then clean up the flag and dead code path - with rules that every flag has an owner and expiration date, cleanup happens within 2 weeks of full rollout, flags are never nested (exponential state combinations), and both flag states are tested in CI. The staged rollout sequence runs staging deploy with full test suite, production deploy with the flag off (health check plus error-monitoring verification), team-only enablement with a 24-hour monitoring window, a canary at 5% of users with a 24-48 hour window comparing metrics against baseline, gradual increase through 25/50/100% with the same monitoring and rollback-to-previous-percentage ability at each step, and finally full rollout with a week of monitoring before flag cleanup. A four-metric threshold table decides advance/hold/rollback at each stage: error rate (green within 10% of baseline, yellow 10-100% above, red over 2x baseline), P95 latency (green within 20%, yellow 20-50% above, red over 50% above), client JS errors (green no new types, yellow new errors under 0.1% of sessions, red over 0.1%), and business metrics (green neutral/positive, yellow under 5% decline as possible noise, red over 5% decline) - with immediate rollback triggers for error rate beyond 2x baseline, P95 latency beyond 50% above baseline, a spike in user-reported issues, data integrity problems, or a discovered security vulnerability. Monitoring spans application metrics (error rate, response time percentiles, request volume, active users, business metrics), infrastructure metrics (CPU/memory, DB connection pool, disk, network latency, queue depth), and client metrics (Core Web Vitals, JS errors, client-perceived API error rate, page load time), with error reporting wired through both a React error boundary and server-side middleware that never exposes internals to users. Post-launch verification in the first hour checks the health endpoint, error and latency dashboards, manually tests the critical user flow, confirms logs are flowing, and verifies the rollback mechanism actually works. Every deployment gets a written rollback plan before shipping - trigger conditions, rollback steps (flag disable or git revert and redeploy), database migration rollback considerations, and a stated time-to-rollback per mechanism (flag under 1 minute, redeploy under 5, database under 15).

Use it for a first production deployment of a feature, releasing a significant change to users, migrating data or infrastructure, opening a beta program, or any deployment carrying risk - which the skill treats as all of them.

Input is a feature or change ready to ship. Output is a completed pre-launch checklist, a feature flag with a defined rollout lifecycle, a staged rollout plan with metric thresholds per stage, configured monitoring across application/infrastructure/client layers, and a written rollback plan with stated rollback times.

References a project-wide Definition of Done plus separate security, performance, and accessibility pre-launch checklists; error reporting wires through a React error boundary and server middleware to an error tracking service.

Developers and teams shipping a risky or significant change who want a systematic pre-launch checklist, a feature-flagged staged rollout with objective advance/hold/rollback thresholds, and a rollback plan written before anything ships rather than improvised after something breaks.