Workflow·Cloud & DevOps

Shipping and Launch

Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up…

You say
Buy it · $35 Read it before you buy $35 Written by addyosmani · unverified publisher
Context cost
2.5k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 10.1 kBtext throughout, nothing executable
Licence
MITpaid listing
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

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.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

devops
Filed under

Cloud & DevOps

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

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

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈70
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,455
on trigger
The instruction body, read only when the skill fires.
1.3%
of a 200k window
Ten skills this size would take about 13% of the window before you open a file.
050k100k150k200k context window

2.5k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 10.1 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md10.1 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$35 once
Shipping and Launch · MIT · addyosmani
one-time
Price$35 once
LicenceMIT — the author’s, unchanged by this purchase
Paid throughStripe, once, on the card you add at the checkout
Keeps workingfor good — the files are yours once they are on disk
Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
Price$35
Referenceaddyosmani/shipping-and-launch

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Publisher
Servers0