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
- Check worktree state and identify intended changes.
- Confirm spec/plan acceptance criteria are met.
- Run required verification or use a fresh valid verification stamp.
- Run phantom completion checks for stubs, placeholders, and disconnected wiring.
- Review security/secrets/configuration risk in the diff.
- Confirm docs/ADRs/changelog updates are sufficient.
- Define rollback path: revert commit, feature flag, migration rollback, or manual procedure.
- Present ship options when action is irreversible: PR, merge, deploy, hold.
- 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.
1---2name: shipping-and-launch3description: Use when preparing to merge, deploy, release, or declare a development branch complete.4---567# Shipping & Launch89## Core Principle1011Do not ship work that cannot be verified, explained, or rolled back. Shipping should be12boring because risk was removed earlier: the ship phase verifies readiness, documents13what changed, and makes rollback possible.1415## Overview1617Shipping should be boring because risk was removed earlier. The ship phase verifies readiness, documents what changed, and makes rollback possible.1819Core principle: do not ship work that cannot be verified, explained, or rolled back.2021## When to Use2223- User says ship, merge, deploy, release, or finish.24- Before closing tracked work as complete.25- Before creating a PR or release notes.26- After build/review/QA phases pass.2728## When NOT to Use2930- Work is still being implemented.31- Critical review findings are open.32- Verification cannot run and no user-approved exception exists.3334## Workflow35361. Check worktree state and identify intended changes.372. Confirm spec/plan acceptance criteria are met.383. Run required verification or use a fresh valid verification stamp.394. Run phantom completion checks for stubs, placeholders, and disconnected wiring.405. Review security/secrets/configuration risk in the diff.416. Confirm docs/ADRs/changelog updates are sufficient.427. Define rollback path: revert commit, feature flag, migration rollback, or manual procedure.438. Present ship options when action is irreversible: PR, merge, deploy, hold.449. Record handoff/memory when useful.4546## Pre-Ship Checklist4748- Tests relevant to changed behavior pass.49- Build/typecheck/lint pass or exceptions are documented.50- No high-severity review findings remain.51- No secrets or local-only paths in diff.52- User-facing/API behavior is documented.53- Rollback path is clear.54- User approval exists for irreversible actions.5556## Common Rationalizations5758| Rationalization | Rebuttal |59|-------------------------------|------------------------------------------------------------------------|60| "Tests passed earlier" | Fresh changes require fresh evidence or a valid unchanged-state stamp. |61| "Rollback is just git revert" | Migrations, flags, queues, and external state may need more. |62| "Docs can wait" | Shipped behavior without docs becomes support debt. |63| "Small release, no checklist" | Small releases still leak secrets and break config. |6465## Red Flags6667- Completion claim without verification evidence.68- Unresolved P0/P1 findings.69- No rollback plan for data or API changes.70- Changelog omits user-visible behavior changes.71- Deployment/merge attempted without explicit user approval.72- Placeholder/stub patterns remain in modified code.7374## Verification7576- Verification commands and outputs are recorded.77- Acceptance criteria are checked line-by-line.78- Phantom completion scan is clean or exceptions are explained.79- Rollback plan is documented.80- Final action is approved when irreversible.81828384## Consolidated Branch Completion8586`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.8788## Host execution boundaries8990**Verification**, cite direct behavioral probes and recorded outputs. On pi91hosts, transactional mutation guards live in `skills/fabric-native-execution/`92and project or `~/.pi/` config; ordinary fixes need only the project verification.9394## References9596N/A, no reference files; the checklist and workflow are fully specified in this file.
ryan-brosas