菜单
Verifies a change is truly ready to ship — rollout plan, monitoring, rollback, and communication. Use before deploying or releasing to production, cutting a release, or expanding rollout to more users.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | launch-readiness |
| description | Verifies a change is truly ready to ship — rollout plan, monitoring, rollback, and communication. Use before deploying or releasing to production, cutting a release, or expanding rollout to more users. |
"Done coding" is not "ready to ship." Before a change reaches users, confirm you can release it safely, see if it breaks, undo it fast, and tell people what changed. The riskier the change, the more this matters — a silent 100% deploy with no rollback is a bet, not a release.
Launch readiness is the go/no-go gate at the Ship phase. It chains verification from Build and Review into production safely — not a substitute for [[browser-checks]], [[review-gate]], or [[pipeline-ops]], but the layer that asks "what happens when this hits real traffic?"
Pairs with [[migration-path]] for deploy order and data rollback limits, [[observability]] for signals before and after, [[git-flow]] for tags and hotfix branches, [[incident-response]] if launch degrades prod, [[hardening]] for security-sensitive launches, and [[decision-docs]] / changelog for communicated changes.
Light pass for low-risk changes (copy tweak behind flag, internal-only tool). Full pass for data migrations, payment flows, auth, and large audience flips.
Skip only for changes with zero production surface (local tooling) — rare for this skill.
Work in order. Don't deploy until rollback and observability are in place for the risk level.
| Tier | Examples | Readiness depth |
|---|---|---|
| Low | Copy, CSS behind flag, internal admin | CI green, quick smoke, owner watching |
| Medium | New UI flow, new API field, perf change | Staging verify, metrics, rollback tested, gradual rollout |
| High | Migration, payments, auth, deletion, scale change | Full checklist, canary, exec comms, soak, on-call engaged |
Under-preparing a high-tier launch causes incidents; over-preparing every typo wastes time — classify first.
Production differs from your laptop. Before go:
Staging passed is necessary, not sufficient — scale, cache, and data shape differ in prod.
Wrong order breaks deploys mid-flight ([[migration-path]]):
Typical safe order:
1. Expand DB/schema (backward-compatible migration)
2. Deploy backend that tolerates old + new schema
3. Backfill data (batched, monitored) if needed
4. Deploy frontend / enable flag for new behavior
5. Contract phase later — remove old path when usage zero
Document dependencies: "API v2 before mobile app 2.1", "migration 0042 before app deploy."
Maintenance window only when unavoidable — document start/end and rollback trigger.
Prefer contained exposure over flipping everyone at once:
| Strategy | When | Control |
|---|---|---|
| Feature flag | New behavior toggleable | Off → internal → % → 100% |
| Canary | Infra supports traffic split | 1% → 5% → 25% → 100% |
| Staged regions | Multi-region deploy | Region A → B → all |
| Dark launch | Code in prod, behavior off | Validate metrics at zero traffic |
| Blue/green | Instant switch with two pools | Switch + rollback = switch back |
Define steps and pauses:
10:00 — deploy build + flag OFF (dark)
10:15 — enable internal dogfood (flag: staff)
11:00 — 5% users, watch 30 min
12:00 — 50% if metrics green
14:00 — 100% or halt
Who watches each step — name a person, not "the team."
No flag/canary available for high-tier change → smaller audience first (beta group, single tenant) or explicit risk acceptance documented.
Rollback is not "we'll revert git." Define exact undo for each layer:
| Layer | Rollback action | Data reversible? |
|---|---|---|
| Feature flag | Turn OFF | Usually yes |
| App deploy | Redeploy previous artifact / revert commit | Code yes |
| Config | Restore previous config version | Usually yes |
| DB migration | Often not trivial — plan expand-contract ([[migration-path]]) | |
| Cache | Purge or TTL wait | May serve stale briefly |
Test rollback before launch in staging:
Document in release notes:
Rollback: flip `checkout_v2` flag OFF + redeploy v1.4.2 if needed.
Migration 0042 is expand-only — rollback does NOT remove column.
You must know if the launch broke something ([[observability]]):
Define healthy for this change:
Checkout v2 launch:
- p95 POST /orders latency < 500ms
- error rate on /orders < 0.5%
- conversion rate within 5% of baseline (business metric)
Before go-live:
During launch: same dashboard open; don't discover gaps when users complain.
Explicit hold conditions — anyone can call halt:
GO if:
- CI green, staging sign-off, rollback tested
- On-call aware, dashboard ready
- No open blocker bugs
NO-GO if:
- Unresolved migration risk
- Rollback untested
- Missing alerts on critical path
- Key person unavailable with no backup
Scheduled release with NO-GO → postpone, don't "YOLO" because the calendar says Tuesday.
| Audience | What | When |
|---|---|---|
| Engineering / on-call | What's shipping, rollout steps, rollback commands, dashboard link | Before deploy |
| Support / CS | User-visible changes, known issues, macros | Before user exposure |
| Stakeholders | Risk tier, window, success metrics | Before / after go |
| Users | Changelog, in-app notice, status page if risky | When behavior changes |
Launch owner — single name for "is this launch still go?" during the window.
External comms factual — don't promise what isn't shipped yet.
Active monitoring through each rollout step:
Checklist after each ramp:
5% ramp: errors flat, p95 +12ms (acceptable), proceed
50% ramp: error spike on payment — HALT, flag OFF, incident declared
Within 24–48 hours:
Launch isn't done at deploy — it's done when stable and documented.
Feature behind flag
Deploy dark → internal ON → staged % → full → remove old path in follow-up PR.
Database migration + code
Expand migration deploy → app deploy (dual-read) → backfill job monitored → later contract migration.
Breaking API change
New version live alongside old → migrate clients → deprecate old with metrics ([[interface-design]], [[migration-path]]).
Payment / checkout change
High tier: canary, payment test cards in prod monitor, rollback = flag + revert, finance notified.
Mobile app + server
Server backward-compatible first → app store release → force-upgrade only if unavoidable.
Config-only change
Diff config in staging → deploy → watch dependency that reads config → rollback = previous config rev.
Hotfix during incident
Branch from prod tag ([[git-flow]]); minimal fix; accelerated launch with single watcher; postmortem after ([[incident-response]]).
Low-risk copy / UI polish
CI + staging smoke + owner watches deploy — skip full canary if tier is low and flag exists.
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.