---
name: loom-shipping-and-launch
description: "Use when release readiness or launch coordination is the work: production deploys, feature-flag enablement, staged rollout, migrations/API/infrastructure release, rollback, monitoring, changelog, or launch communication."
disable-model-invocation: true
---

# loom-shipping-and-launch

Shipping and launch is a release-readiness playbook.

It checks the graph, verifies the artifact, defines rollout and rollback, records
launch evidence, and runs retrospective follow-up.

## Loom Routing

Common routes use these Loom skills for durable records or follow-up workflow:
`loom-plans`, `loom-tickets`, `loom-evidence`, `loom-audit`, `loom-specs`,
`loom-knowledge`, and `loom-retrospective`.

Ensure the `using-loom` skill is loaded before applying this workflow.

When routing to any named Loom skill, follow that skill's procedure and guidance
completely. This playbook adds workflow pressure; it does not shorten the target
skill's requirements.

## Use This Playbook When

Use this playbook when:

- deploying a feature or significant change to production
- enabling a feature flag for users
- launching beta, staged rollout, or early access
- releasing a migration, API change, or infrastructure change
- preparing rollback, monitoring, changelog, or release notes
- launch claims need evidence and audit before communication

## Route

Use this route:

```text
readiness -> rollout -> observe -> decide -> communicate -> clean up
```

## Readiness

Start from the tickets, plan, specs, evidence, and audit records that define the
release.

Check:

- ticket closure or review state
- spec requirements and scenarios in scope
- evidence for tests, builds, browser checks, migrations, and manual checks
- audit findings and dispositions
- known residual risk
- feature flag state
- migration and rollback readiness
- docs, changelog, and operator-facing notes

If the records cannot support the launch claim, route back to the missing record.

## Launch Checklist

Use only checks relevant to the release risk:

- tests, type check, lint, build
- CI status
- browser or runtime observations
- accessibility checks for UI
- security checks for auth, input, secrets, and dependencies
- performance baseline or budget checks
- migration dry run or backup plan
- environment variables and secrets present/configured, with values never recorded
- logging, health checks, and error reporting
- rollback command or flag-disable procedure
- user-facing docs or release notes

Record durable observations with `loom-evidence`. For secrets, record only
redacted presence or configuration metadata.

## Rollout

Choose a rollout shape:

- deploy inactive behind a feature flag
- internal enablement
- canary
- staged percentage rollout
- region or tenant rollout
- full launch
- maintenance-window migration

For each stage, name:

- entry criteria
- monitoring window
- metrics to watch
- rollback triggers
- accountable operator decision point
- evidence to capture

## Observe

Post-launch evidence may include:

- deployment or release run ID
- health check result
- error dashboard observation
- latency or performance metric
- business or usage metric
- logs showing no new error signature
- browser smoke test
- migration verification
- feature flag state

Name limitations. A short clean monitoring window does not prove all future states.

## Decide

At each stage, decide:

- advance
- hold and investigate
- roll back
- gather more evidence
- open follow-up ticket
- request audit

Use `loom-audit` when launch confidence depends on Ralph-backed review of evidence,
rollout risk, migration integrity, security, or user impact.

## Communicate

Draft release notes, changelog entries, PR summaries, or operator updates from
Loom records and evidence.

Do not claim more than tickets, specs, evidence, and audit support.

Route durable user-facing behavior changes back to specs or docs that the project
actually maintains. Promote recurring launch procedure to knowledge.

## Clean Up

After full launch:

- remove completed feature flags when safe
- close or update follow-up tickets
- update knowledge and atlases
- retire stale docs or warnings
- record retrospective prevention notes
- keep rollback notes if they remain useful

## Done Means

The launch pass is done when:

- readiness checks match the release risk
- rollout and rollback paths are explicit
- launch observations are recorded when durable claims depend on them
- communication mirrors Loom records and evidence
- follow-up, cleanup, and retrospective routes are visible
