Shipping And Launch
Run a production-ready shipping ritual with checklist, monitoring, staged rollout, and rollback before users see the change.
Overview
shipping-and-launch is an agent skill most often used in Ship (also Operate) that prepares production launches with checklists, monitoring, staged rollout, and rollback strategy.
Install
npx skills add https://github.com/addyosmani/agent-skills --skill shipping-and-launchWhat is this skill?
- Pre-launch checklist spanning code quality, security, and operational readiness
- Emphasizes reversible, observable, incremental launches—not one-shot deploys
- Covers staged rollout, beta access, and migration-style high-risk releases
- Expects monitoring in place and a documented rollback strategy before go-live
- Security block includes audit, authZ, headers, rate limits, and CORS checks
- 2 major pre-launch checklist sections detailed (Code Quality, Security) with 6+ items each
Adoption & trust: 3.8k installs on skills.sh; 49.1k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+200% hot-view momentum).
What problem does it solve?
You are about to deploy something meaningful to production but lack a unified pre-launch gate, observability plan, and rollback path.
Who is it for?
Indie developers doing first production deploys, betas, or risky migrations who want agent-guided launch hygiene without hiring a release manager.
Skip if: Local-only experiments, docs-only commits, or teams that already enforce an identical automated release train with no human checklist gap.
When should I use this skill?
Preparing to deploy to production, need a pre-launch checklist, monitoring setup, staged rollout, or rollback strategy.
What do I get? / Deliverables
You finish with checklist-backed launch readiness, monitoring and rollback defined, and a staged rollout plan that treats success criteria as part of shipping—not an afterthought.
- Completed pre-launch checklist review
- Monitoring and rollback plan
- Staged rollout approach with success criteria
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is the canonical shelf because the skill explicitly prepares production launches and pre-launch gates—not ideation or growth campaigns. Launch subphase matches deploy-to-production timing, observability setup, and reversible rollout planning.
Where it fits
Gate a first customer-facing feature behind tests, review, and rollback steps.
Verify auth, rate limits, and npm audit severity before exposing endpoints.
Define what observable signals mean launch success before traffic hits.
How it compares
Launch-readiness workflow skill, not a CI pipeline template or hosting provider deploy button.
Common Questions / FAQ
Who is shipping-and-launch for?
Solo and indie builders using coding agents who are preparing a real production deployment and need structure around safety, monitoring, and rollback.
When should I use shipping-and-launch?
Use when deploying to production for the first time, releasing significant user-facing changes, planning staged or beta rollouts, or migrating infra—typically in Ship launch and early Operate monitoring setup.
Is shipping-and-launch safe to install?
It is procedural guidance; review the Security Audits panel on this page and still run your own secret scanning and dependency audits—the checklist reminds you to, but does not replace tooling.
SKILL.md
READMESKILL.md - Shipping And Launch
# Shipping and Launch ## Overview Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental. ## When to Use - Deploying a feature to production for the first time - Releasing a significant change to users - Migrating data or infrastructure - Opening a beta or early access program - Any deployment that carries risk (all of them) ## The Pre-Launch Checklist ### Code Quality - [ ] All tests pass (unit, integration, e2e) - [ ] Build succeeds with no warnings - [ ] Lint and type checking pass - [ ] Code reviewed and approved - [ ] No TODO comments that should be resolved before launch - [ ] No `console.log` debugging statements in production code - [ ] Error handling covers expected failure modes ### Security - [ ] No secrets in code or version control - [ ] `npm audit` shows no critical or high vulnerabilities - [ ] Input validation on all user-facing endpoints - [ ] Authentication and authorization checks in place - [ ] Security headers configured (CSP, HSTS, etc.) - [ ] Rate limiting on authentication endpoints - [ ] CORS configured to specific origins (not wildcard) ### Performance - [ ] Core Web Vitals within "Good" thresholds - [ ] No N+1 queries in critical paths - [ ] Images optimized (compression, responsive sizes, lazy loading) - [ ] Bundle size within budget - [ ] Database queries have appropriate indexes - [ ] Caching configured for static assets and repeated queries ### Accessibility - [ ] Keyboard navigation works for all interactive elements - [ ] Screen reader can convey page content and structure - [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text) - [ ] Focus management correct for modals and dynamic content - [ ] Error messages are descriptive and associated with form fields - [ ] No accessibility warnings in axe-core or Lighthouse ### Infrastructure - [ ] Environment variables set in production - [ ] Database migrations applied (or ready to apply) - [ ] DNS and SSL configured - [ ] CDN configured for static assets - [ ] Logging and error reporting configured - [ ] Health check endpoint exists and responds ### Documentation - [ ] README updated with any new setup requirements - [ ] API documentation current - [ ] ADRs written for any architectural decisions - [ ] Changelog updated - [ ] User-facing documentation updated (if applicable) ## Feature Flag Strategy Ship behind feature flags to decouple deployment from release: ```typescript // Feature flag check const flags = await getFeatureFlags(userId); if (flags.taskSharing) { // New feature: task sharing return <TaskSharingPanel task={task} />; } // Default: existing behavior return null; ``` **Feature flag lifecycle:** ``` 1. DEPLOY with flag OFF → Code is in production but inactive 2. ENABLE for team/beta → Internal testing in production environment 3. GRADUAL ROLLOUT → 5% → 25% → 50% → 100% of users 4. MONITOR at each stage → Watch error rates, performance, user feedback 5. CLEAN UP → Remove flag and dead code path after full rollout ``` **Rules:** - Every feature flag has an owner and an expiration date - Clean up flags within 2 weeks of full rollout - Don't nest feature flags (creates exponential combinations) - Test both flag states (on and off) in CI ## Staged Rollout ### The Rollout Sequence ``` 1. DEPLOY to staging └── Full test suite in staging environment └── Manual smoke test of critical flows 2. DEPLOY to production (feature flag OFF) └── Verify deployment succeeded (health check) └── Check error monitoring (no new errors) 3. E