shipping-and-launch

Name: shipping-and-launch
Author: addyosmani

byaddyosmani· 31 skills

Installs

14k

Stars

80k

Forks

8.7k

How to install shipping-and-launch?

addyosmani/agent-skills/shipping-and-launch

$npx -y skills add addyosmani/agent-skills --skill shipping-and-launch

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/shipping-and-launch"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# Shipping and Launch
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- Deploying a feature to production for the first time
10	- Releasing a significant change to users
11	- Migrating data or infrastructure
12	- Opening a beta or early access program
13	- Any deployment that carries risk (all of them)
14
15	## The Pre-Launch Checklist
16
17	### Code Quality
18
19	- [ ] All tests pass (unit, integration, e2e)
20	- [ ] Build succeeds with no warnings
21	- [ ] Lint and type checking pass
22	- [ ] Code reviewed and approved
23	- [ ] No TODO comments that should be resolved before launch
24	- [ ] No `console.log` debugging statements in production code
25	- [ ] Error handling covers expected failure modes
26
27	### Security
28
29	- [ ] No secrets in code or version control
30	- [ ] The ecosystem's dependency audit (`npm audit`, `pip-audit`, `cargo audit`, ...) shows no critical or high vulnerabilities
31	- [ ] Input validation on all user-facing endpoints
32	- [ ] Authentication and authorization checks in place
33	- [ ] Security headers configured (CSP, HSTS, etc.)
34	- [ ] Rate limiting on authentication endpoints
35	- [ ] CORS configured to specific origins (not wildcard)
36
37	### Performance
38
39	- [ ] Core Web Vitals within "Good" thresholds
40	- [ ] No N+1 queries in critical paths
41	- [ ] Images optimized (compression, responsive sizes, lazy loading)
42	- [ ] Bundle size within budget
43	- [ ] Database queries have appropriate indexes
44	- [ ] Caching configured for static assets and repeated queries
45
46	### Accessibility
47
48	- [ ] Keyboard navigation works for all interactive elements
49	- [ ] Screen reader can convey page content and structure
50	- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)
51	- [ ] Focus management correct for modals and dynamic content
52	- [ ] Error messages are descriptive and associated with form fields
53	- [ ] No accessibility warnings in axe-core or Lighthouse
54
55	### Infrastructure
56
57	- [ ] Environment variables set in production
58	- [ ] Database migrations applied (or ready to apply)
59	- [ ] DNS and SSL configured
60	- [ ] CDN configured for static assets
61	- [ ] Logging and error reporting configured
62	- [ ] Health check endpoint exists and responds
63
64	### Documentation
65
66	- [ ] README updated with any new setup requirements
67	- [ ] API documentation current
68	- [ ] ADRs written for any architectural decisions
69	- [ ] Changelog updated
70	- [ ] User-facing documentation updated (if applicable)
71
72	## Feature Flag Strategy
73
74	Ship behind feature flags to decouple deployment from release:
75
76	```typescript
77	// Feature flag check
78	const flags = await getFeatureFlags(userId);
79
80	if (flags.taskSharing) {
81	// New feature: task sharing
82	return <TaskSharingPanel task={task} />;
83	}
84
85	// Default: existing behavior
86	return null;
87	```
88
89	Feature flag lifecycle:
90
91	```
92	1. DEPLOY with flag OFF → Code is in production but inactive
93	2. ENABLE for team/beta → Internal testing in production environment
94	3. GRADUAL ROLLOUT → 5% → 25% → 50% → 100% of users
95	4. MONITOR at each stage → Watch error rates, performance, user feedback
96	5. CLEAN UP → Remove flag and dead code path after full rollout
97	```
98
99	Rules:
100	- Every feature flag has an owner and an expiration date
101	- Clean up flags within 2 weeks of full rollout
102	- Don't nest feature flags (creates exponential combinations)
103	- Test both flag states (on and off) in CI
104
105	## Staged Rollout
106
107	### The Rollout Sequence
108
109	```
110	1. DEPLOY to staging
111	└── Full test suite in staging environment
112	└── Manual smoke test of critical flows
113
114	2. DEPLOY to production (feature flag OFF)
115	└── Verify deployment succeeded (health check)
116	└── Check error monitoring (no new errors)
117
118	3. ENABLE for team (flag ON for internal users)
119	└── Team uses the feature in production
120	└── 24-hour monitoring window
121
122	4. CANARY rollout (flag ON for 5% of users)
123	└── Monitor error rates, latency, user behavior
124	└── Compare metrics: canary vs. baseline
125	└── 24-48 hour monitoring window
126	└── Advance only if all thresholds pass (see table below)
127
128	5. GRADUAL increase (25% -> 50% -> 100%)
129	└── Same monitoring at each step
130	└── Ability to roll back to previous percentage at any point
131
132	6. FULL rollout (flag ON for all users)
133	└── Monitor for 1 week
134	└── Clean up feature flag
135	```
136
137	### Rollout Decision Thresholds
138
139	Use these thresholds to decide whether to advance, hold, or roll back at each stage:
140
141	\| Metric \| Advance (green) \| Hold and investigate (yellow) \| Roll back (red) \|
142	\|--------\|-----------------\|-------------------------------\|-----------------\|
143	\| Error rate \| Within 10% of baseline \| 10-100% above baseline \| >2x baseline \|
144	\| P95 latency \| Within 20% of baseline \| 20-50% above baseline \| >50% above baseline \|
145	\| Client JS errors \| No new error types \| New errors at <0.1% of sessions \| New errors at >0.1% of sessions \|
146	\| Business metrics \| Neutral or positive \| Decline <5% (may be noise) \| Decline >5% \|
147
148	### When to Roll Back
149
150	Roll back immediately if:
151	- Error rate increases by more than 2x baseline
152	- P95 latency increases by more than 50%
153	- User-reported issues spike
154	- Data integrity issues detected
155	- Security vulnerability discovered
156
157	## Monitoring and Observability
158
159	### What to Monitor
160
161	```
162	Application metrics:
163	├── Error rate (total and by endpoint)
164	├── Response time (p50, p95, p99)
165	├── Request volume
166	├── Active users
167	└── Key business metrics (conversion, engagement)
168
169	Infrastructure metrics:
170	├── CPU and memory utilization
171	├── Database connection pool usage
172	├── Disk space
173	├── Network latency
174	└── Queue depth (if applicable)
175
176	Client metrics:
177	├── Core Web Vitals (LCP, INP, CLS)
178	├── JavaScript errors
179	├── API error rates from client perspective
180	└── Page load time
181	```
182
183	### Error Reporting
184
185	```typescript
186	// Set up error boundary with reporting
187	class ErrorBoundary extends React.Component {
188	componentDidCatch(error: Error, info: React.ErrorInfo) {
189	// Report to error tracking service
190	reportError(error, {
191	componentStack: info.componentStack,
192	userId: getCurrentUser()?.id,
193	page: window.location.pathname,
194	});
195	}
196
197	render() {
198	if (this.state.hasError) {
199	return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
200	}
201	return this.props.children;
202	}
203	}
204
205	// Server-side error reporting
206	app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
207	reportError(err, {
208	method: req.method,
209	url: req.url,
210	userId: req.user?.id,
211	});
212
213	// Don't expose internals to users
214	res.status(500).json({
215	error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
216	});
217	});
218	```
219
220	### Post-Launch Verification
221
222	In the first hour after launch:
223
224	```
225	1. Check health endpoint returns 200
226	2. Check error monitoring dashboard (no new error types)
227	3. Check latency dashboard (no regression)
228	4. Test the critical user flow manually
229	5. Verify logs are flowing and readable
230	6. Confirm rollback mechanism works (dry run if possible)
231	```
232
233	## Rollback Strategy
234
235	Every deployment needs a rollback plan before it happens:
236
237	```markdown
238	## Rollback Plan for [Feature/Release]
239
240	### Trigger Conditions
241	- Error rate > 2x baseline
242	- P95 latency > [X]ms
243	- User reports of [specific issue]
244
245	### Rollback Steps
246	1. Disable feature flag (if applicable)
247	OR
248	1. Deploy previous version: `git revert <commit> && git push`
249	2. Verify rollback: health check, error monitoring
250	3. Communicate: notify team of rollback
251
252	### Database Considerations
253	- Migration [X] has a rollback: `npx prisma migrate rollback`
254	- Data inserted by new feature: [preserved / cleaned up]
255
256	### Time to Rollback
257	- Feature flag: < 1 minute
258	- Redeploy previous version: < 5 minutes
259	- Database rollback: < 15 minutes
260	```
261	## See Also
262
263	- For the project-wide Definition of Done that every change must clear before this checklist, see `references/definition-of-done.md`
264	- For security pre-launch checks, see `references/security-checklist.md`
265	- For performance pre-launch checklist, see `references/performance-checklist.md`
266	- For accessibility verification before launch, see `references/accessibility-checklist.md`
267
268	## Common Rationalizations
269
270	\| Rationalization \| Reality \|
271	\|---\|---\|
272	\| "It works in staging, it'll work in production" \| Production has different data, traffic patterns, and edge cases. Monitor after deploy. \|
273	\| "We don't need feature flags for this" \| Every feature benefits from a kill switch. Even "simple" changes can break things. \|
274	\| "Monitoring is overhead" \| Not having monitoring means you discover problems from user complaints instead of dashboards. \|
275	\| "We'll add monitoring later" \| Add it before launch. You can't debug what you can't see. \|
276	\| "Rolling back is admitting failure" \| Rolling back is responsible engineering. Shipping a broken feature is the failure. \|
277
278	## Red Flags
279
280	- Deploying without a rollback plan
281	- No monitoring or error reporting in production
282	- Big-bang releases (everything at once, no staging)
283	- Feature flags with no expiration or owner
284	- No one monitoring the deploy for the first hour
285	- Production environment configuration done by memory, not code
286	- "It's Friday afternoon, let's ship it"
287
288	## Verification
289
290	Before deploying:
291
292	- [ ] Pre-launch checklist completed (all sections green)
293	- [ ] Feature flag configured (if applicable)
294	- [ ] Rollback plan documented
295	- [ ] Monitoring dashboards set up
296	- [ ] Team notified of deployment
297
298	After deploying:
299
300	- [ ] Health check returns 200
301	- [ ] Error rate is normal
302	- [ ] Latency is normal
303	- [ ] Critical user flow works
304	- [ ] Logs are flowing
305	- [ ] Rollback tested or verified ready

6 picks

Type

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/shipping-and-launch"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

shipping-and-launch

How to install shipping-and-launch?

Related

shipping-and-launch

How to install shipping-and-launch?

Related