shipping-and-launch

Name: shipping-and-launch
Author: addyosmani

13kinstalls8.6kforks

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.

Summary

Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

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	- [ ] `npm 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

People who liked this also viewed

6 picks

Type

shipping-and-launch

13kinstalls8.6kforks

View on GitHub

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.

Summary

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	- [ ] `npm 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

People who liked this also viewed

6 picks

Type