ship

name	ship
description	Release orchestrator that drives code from development through testing, review, changelog generation, and deployment.
layer	orchestrator
category	orchestration
triggers	["/ship","ship it","release this","deploy this","prepare a release","cut a release"]
inputs	["Branch or commit range to ship","Optional version bump type (major, minor, patch)","Optional deployment target (production, staging, preview)","Optional release notes or highlights"]
outputs	["Test suite results (pass/fail report)","Code review summary","Generated changelog entry","Version bump applied","Git tag created","Pull request created (if applicable)","Deployment status"]
linksTo	["test","code-review","fix","debug","optimize","changelog-writer","commit-crafter","pr-writer","git-workflow","docs-writer","preview"]
linkedFrom	["cook","team"]
preferredNextSkills	["docs-writer","onboard"]
fallbackSkills	["test","code-review"]
riskLevel	high
memoryReadPolicy	full
memoryWritePolicy	always
sideEffects	["Runs test suite","May fix code issues found during review","Modifies version numbers in config files","Updates or creates CHANGELOG","Creates git tags","Creates git commits","Creates pull requests","May trigger deployments"]

Ship

Purpose

Ship is the release orchestrator. It takes code that's been developed and guides it through the final gauntlet: running the full test suite, performing a release-grade code review, generating the changelog, bumping the version, tagging, creating the PR, and optionally deploying. Ship is the quality gate between "code written" and "code in production."

Ship is deliberately cautious. It runs checks in a specific order, and any failure halts the pipeline with a clear report. It does not deploy broken code. It does not skip tests. It treats every release as a potential production incident waiting to happen and acts accordingly.

Workflow

Phase 1: Pre-flight Check

1. Assess the release scope -- Determine what's being shipped by examining the branch, commit range, or diff against the target branch.
2. Invoke git-workflow -- Verify the branch is clean, up to date with the base branch, and has no merge conflicts.
3. Classify the release -- Based on the changes, suggest a version bump:
   • Patch: Bug fixes, dependency updates, typo fixes
   • Minor: New features, non-breaking enhancements
   • Major: Breaking changes, API modifications, architecture shifts
4. Present pre-flight report -- Show the user what's being shipped, the suggested version, and any concerns. Get confirmation.

Phase 2: Test

5. Invoke test -- Run the full test suite. This is not a quick spot-check; it's the full matrix:
   • Unit tests
   • Integration tests
   • End-to-end tests (if they exist)
   • Type checking
   • Linting
6. Evaluate results -- If any tests fail:
   • Auto-fixable: Invoke fix for straightforward failures (lint errors, type issues).
   • Requires investigation: Invoke debug for test failures that need root-cause analysis.
   • Blocking: If failures can't be resolved automatically, halt and report to user.
7. Re-run tests -- After fixes, run the suite again to confirm green.

Phase 3: Review

8. Invoke code-review -- Perform a release-grade review of all changes:
   • Security: No secrets, no injection vectors, proper auth checks