# Shipping And Launch

> Use when preparing to merge, deploy, release, or declare a development branch complete.

- Skill: `ryan-brosas/shipping-and-launch` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ryan-brosas/shipping-and-launch`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ryan-brosas/shipping-and-launch/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ryan-brosas (https://skillmd.com/u/ryan-brosas)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ryan-brosas/shipping-and-launch

---



# Shipping & Launch

## Core Principle

Do not ship work that cannot be verified, explained, or rolled back. Shipping should be
boring because risk was removed earlier: the ship phase verifies readiness, documents
what changed, and makes rollback possible.

## Overview

Shipping should be boring because risk was removed earlier. The ship phase verifies readiness, documents what changed, and makes rollback possible.

Core principle: do not ship work that cannot be verified, explained, or rolled back.

## When to Use

- User says ship, merge, deploy, release, or finish.
- Before closing tracked work as complete.
- Before creating a PR or release notes.
- After build/review/QA phases pass.

## When NOT to Use

- Work is still being implemented.
- Critical review findings are open.
- Verification cannot run and no user-approved exception exists.

## Workflow

1. Check worktree state and identify intended changes.
2. Confirm spec/plan acceptance criteria are met.
3. Run required verification or use a fresh valid verification stamp.
4. Run phantom completion checks for stubs, placeholders, and disconnected wiring.
5. Review security/secrets/configuration risk in the diff.
6. Confirm docs/ADRs/changelog updates are sufficient.
7. Define rollback path: revert commit, feature flag, migration rollback, or manual procedure.
8. Present ship options when action is irreversible: PR, merge, deploy, hold.
9. Record handoff/memory when useful.

## Pre-Ship Checklist

- Tests relevant to changed behavior pass.
- Build/typecheck/lint pass or exceptions are documented.
- No high-severity review findings remain.
- No secrets or local-only paths in diff.
- User-facing/API behavior is documented.
- Rollback path is clear.
- User approval exists for irreversible actions.

## Common Rationalizations

| Rationalization | Rebuttal |
|-------------------------------|------------------------------------------------------------------------|
| "Tests passed earlier" | Fresh changes require fresh evidence or a valid unchanged-state stamp. |
| "Rollback is just git revert" | Migrations, flags, queues, and external state may need more. |
| "Docs can wait" | Shipped behavior without docs becomes support debt. |
| "Small release, no checklist" | Small releases still leak secrets and break config. |

## Red Flags

- Completion claim without verification evidence.
- Unresolved P0/P1 findings.
- No rollback plan for data or API changes.
- Changelog omits user-visible behavior changes.
- Deployment/merge attempted without explicit user approval.
- Placeholder/stub patterns remain in modified code.

## Verification

- Verification commands and outputs are recorded.
- Acceptance criteria are checked line-by-line.
- Phantom completion scan is clean or exceptions are explained.
- Rollback plan is documented.
- Final action is approved when irreversible.



## Consolidated Branch Completion

`finishing-a-development-branch` was removed as a separate optional skill. Keep merge/PR/cleanup choices, release handoff, rollback planning, and completion evidence in this canonical shipping workflow.

## Host execution boundaries

**Verification**, cite direct behavioral probes and recorded outputs. On pi
hosts, transactional mutation guards live in `skills/fabric-native-execution/`
and project or `~/.pi/` config; ordinary fixes need only the project verification.

## References

N/A, no reference files; the checklist and workflow are fully specified in this file.