git:20260713.591c386 to git:20260727.51710ca

---

model_tier: inherit

name: launch-readiness

description: "Use before merging a release-shaped PR — pre-merge checklist, rollout plan, rollback criteria, ops handoff. Triggers on 'ready to ship', 'launch checklist', 'rollout plan for X'."

status: active

tier: senior

domain: process

context_spine: [team, product]

recommended_for_user_types: [ops, developer, founder]

workspaces:

- founder

packs:

- founder-strategy

install:

removable: true

---

# launch-readiness

## When to use

- A change is about to merge that crosses a release boundary (new feature on `main`, version bump, public-facing comms attached).

- An ops handoff is implied — the on-call rotation, support team, or downstream consumers need to know.

- A rollback criterion has not been written down yet.

Do NOT use for routine internal merges

([`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md))

or for the comms text itself ([`release-comms`](../release-comms/SKILL.md)).

This skill produces the **decision** to ship and the rollback contract.

## Cognition cluster

- **Mental model 10 — Reversible vs irreversible.** Map every step

of the rollout to a reversibility class; the rollback criteria

must name the irreversible steps and the abort threshold for each.

See [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 10.

- **Mental model 29 — Pre-mortems.** Imagine the rollout failed in

six hours; what failed first? The pre-mortem becomes the rollback

criteria, not a separate document. See `mental-models.md` § 29.

- **Mental model 4 — Second-order thinking.** Enumerate what

becomes harder *after* the launch (rollback cost, contributor

ergonomics, doc churn). See `mental-models.md` § 4.

- **Team + product context-spine slots.** Read **team** for the

on-call rotation and ops handoff path; read **product** for the

segment / cohort exposure of the rollout. See

[`context-spine`](../../../docs/contracts/context-spine.md).

## Procedure

### 1. Identify the launch shape

One sentence: *"This change ships **X** to **segment Y** behind

**rollout mechanism Z**."* If you cannot, the change is not

release-shaped; route to `finishing-a-development-branch`.

### 2. Inspect the pre-merge checklist

Walk the diff with the following gates:

- Tests green on the integration suite (cite the run).

- Quality gates green (static analysis / linters / type-checks).

- Migrations are reversible OR the irreversibility is explicit.

- Feature flag / kill switch named, default off unless intended.

- Doc / changelog / release notes present (hand off to

[`release-comms`](../release-comms/SKILL.md) for the prose).

- Rollback path tested at least mentally; named in step 4.

Cells without evidence block the launch — surface, do not

hand-wave.

### 2b. Epistemics block — the diagnostic report (contract-backed)

For a consumer-facing diagnostic (not just the merge decision), emit a

report per [`docs/contracts/prelaunch-diagnostics.md`](../../../docs/contracts/prelaunch-diagnostics.md)

(schema: `prelaunch-report.schema.json`). Rules:

- **Coverage backbone** — diagnose exactly the fixed area vocabulary

(`prelaunch-areas.yml`): auth · migrations · secrets · observability ·

rollback · agent-governance. No ad-hoc areas.

- **Every area gets one state:** `pass` (cited evidence REQUIRED) ·

`finding` (IDs listed) · `unknown` (the honest default — **absence of

findings is Unknown, never an automatic Pass**) · `not-applicable`

(reason required).

- **Findings carry immutable IDs** (`AC-<AREA>-NNN`) — retitle freely,

never re-assign; the ID is the diff key across runs.

- **Verdict:** any open P0 → NOT ready, regardless of every other area;

any open P1 or a launch-gate area not at pass/N-A → NOT ready. Ready is

the residual state, never the default.

- **Questions section** — list the questions that would change the

diagnosis; the next run converts them into evidence or findings.

- Validate + verdict via

regression-gate against the committed baseline via

`… diff <baseline> <current> --ci` (contract § 4–6).

### 2c. Fix loop (approval-gated, read-only diagnostic)

Rank open findings by severity, then launch-gate membership; propose the

**safest first approval batch** (reversible, small blast radius — explicitly

not the full backlog). Status vocabulary per finding: `open · fixed ·

accepted-risk · deferred-with-reason · suppressed-with-evidence ·

not-applicable` — everything except open/fixed carries a reason. Rescore

whenever evidence changes. The diagnostic itself never mutates the project;

fixes flow through the normal approval-gated engines.

### 3. Plan the rollout

- **Mechanism** — flag, canary cohort, blue-green, immediate.

- **Order** — internal → trusted segment → general; cite the

segment per stage from the **product** spine slot.

- **Telemetry** — the metric that **proves** rollout health.

- **Owner** — named role per stage (not name); from the **team**

spine slot.

### 4. Write rollback criteria

For each stage:

- **Trip wire** — the metric value that fires rollback.

- **Decision window** — how long the trip wire must hold.

- **Abort path** — what the on-call does (revert PR, flip flag,

drain queue), pre-rehearsed.

- **Irreversible steps** — explicit list; if any irreversible step

is in scope, the launch needs a written sign-off, not implicit.

Pre-mortem rule: every trip wire must answer *"what would have

caused this in six hours?"* If you cannot, the trip wire is wrong.

### 4b. Post-deploy verification fragments (manual checks, not an auto-canary)

Right after deploy, the on-call runs these quick checks by hand. They are

**checklist items, not an automated canary loop** — a real canary is a runtime

and out of scope here; these are cheap "did the deploy silently break a thing

that doesn't page" probes. Include only the ones that apply to the stack:

- **SSE / streaming heartbeat** — if the app serves Server-Sent Events or a

long-lived stream, confirm a connection stays open and emits a heartbeat past

the proxy's idle timeout (a deploy that changes proxy/buffering config silently

kills streaming while every other endpoint looks fine).

- **Static-asset content-type drift** — fetch a built asset and assert the

`Content-Type` (JS as `text/javascript`/`application/javascript`, CSS as

`text/css`); a CDN/build change that serves assets as `text/plain` or

`application/octet-stream` breaks the app in the browser but returns HTTP 200.

- **LCP delta** — spot-check Largest-Contentful-Paint on the top route against

the pre-deploy baseline; a regression beyond the agreed delta is a trip wire

even when no error fires.

Each fragment is a one-shot check with a pass/fail an on-call can eyeball; failures

feed the § 4 trip wires. Do not build a standing canary service for them.

### 5. Ops handoff

- Who is paged on which alert (from **team** spine slot).

- Where the rollback runbook lives (link).

- Date / time of the handoff conversation; sign-off from the

receiving role.

### 6. Hand back

Hand the artefact below to whoever requested the launch decision;

route comms to [`release-comms`](../release-comms/SKILL.md) and

post-launch metrics tracking to the team's monitoring stack.

## Related Skills

**WHEN to use this**

- A release-shaped PR is about to merge.

- Rollback criteria need to land in writing before the merge button

is pressed.

- Ops handoff is implied and not yet executed.

**WHEN NOT to use this**

- The change is internal and routine — route to

[`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md).

- The output is the public comms — route to

[`release-comms`](../release-comms/SKILL.md).

- The rollout decision involves stakeholder conflict — route to

[`stakeholder-tradeoff`](../stakeholder-tradeoff/SKILL.md) first.

- The decision is reversible-and-cheap — write a one-line note,

skip the full artefact.

## When the agent should load this

- "Sind wir launch-ready?"

- "Bau mir die Rollback-Kriterien für Phase X."

- "Ops-Handoff für die Release morgen."

- "Was bricht, wenn wir den Flag flippen?"

- "Pre-merge-Checklist für PR #N."

## Output

1. **Launch shape** — one-sentence statement of the change.

2. **Pre-merge checklist** — gate · status · evidence (citation).

3. **Rollout plan** — stages × mechanism · order · telemetry · owner.

4. **Rollback contract** — per stage: trip wire · decision window ·

abort path · irreversible steps.

5. **Ops handoff** — pager mapping · runbook link · sign-off.

6. **Outstanding** — anything blocking the launch; explicit, not

collapsed.

## Gotcha

- A checklist with all green and no citations is theatre; every

green needs an artefact.

- A trip wire without a decision window is unactionable — *"if

errors spike"* is not a trigger; *"5xx > 2% for 10 min"* is.

- Irreversible steps without written sign-off are the most common

post-mortem ancestor — surface, do not skip.

## Do NOT

- Do NOT write the comms text here — that is `release-comms`.

- Do NOT lock the rollback contract verbally — it lives in the

output block, citable.

- Do NOT let any stage own itself — every stage names a role from

the **team** spine slot.

- Do NOT hand the artefact to a receiver who has not signed off on

ops handoff.