shipper

The shipper is your deployment specialist. Once Gate 2 passes, the shipper takes over to execute the full ship sequence — running pre-ship checks, creating conventional commits, opening pull requests on feature branches, verifying CI, and documenting rollback procedures. It never commits directly to main.

Cognitive Framing

"Ship safely. Never commit to main. Every deployment has a rollback plan."

The shipper operates at Phase 5 (Ship) and only activates after Gate 2 (review approval). It is deliberately the simplest agent in the pipeline — its job is to execute a well-defined checklist, not to make judgments about code quality. That judgment has already been made by the reviewer and evaluator.

Key Facts

Type	Core
Phase	5 (Ship)
Auto-activates	After Gate 2 passes
Never does	Commit to main/master, ship without a passing review, skip pre-ship checks, skip rollback docs, force-push to shared branches

When to Use

• After Gate 2 passes — the shipper activates automatically when the reviewer issues a PASS or WARN verdict.
• When you are ready to create a PR and push changes.
• When you need a conventional commit with the correct prefix.
• When deploying to production and need canary deployment support with gradual rollout.

Key Capabilities

• Pre-ship checks — runs test suite, linter, and type checker. All must pass before proceeding.
• Conventional commits — creates commits with appropriate prefixes: feat:, fix:, chore:, refactor:, docs:, test:, perf:, ci:.
• Branch + PR creation — creates a feature branch and opens a pull request. Never commits directly to main.
• CI verification — confirms the CI pipeline passes on the PR before marking the ship as successful.
• Rollback documentation — documents the rollback procedure for every ship.
• Canary deployments — supports gradual rollout for production changes with monitoring checkpoints and rollback triggers.

Behavioral Checklist

• [x] Runs all pre-ship checks (tests, lint, typecheck) before committing
• [x] Creates conventional commits with correct prefix
• [x] Uses feature branches — never commits to main/master
• [x] Opens pull request with descriptive title and body
• [x] Verifies CI passes on the PR
• [x] Documents rollback procedure for every ship
• [x] Never ships without a passing review verdict (Gate 2)
• [x] Never force-pushes to shared branches

Common Use Cases

Scenario	What the shipper does
Standard feature ship	Runs pre-checks → creates conventional commit → opens PR on feature branch → verifies CI
Bug fix deployment	Same sequence with fix: commit prefix, includes rollback documentation
Production deployment	Supports canary deployment with gradual rollout and monitoring checkpoints
CI failure on PR	Reports failure details with log excerpts, routes back to developer or tester for fixes

Pro Tips

Let Pre-Ship Checks Catch Issues Early

The pre-ship checks (tests, lint, typecheck) are your last opportunity to catch issues before they enter the PR. If any check fails, the shipper routes back to the appropriate agent rather than proceeding. This is by design — catching issues at pre-ship is much cheaper than catching them in CI.

Include Rollback Context in Every Ship

Rollback documentation is not optional. Even for small changes, the rollback procedure should answer: "If this change causes problems in production, what is the fastest way to undo it?" This is a one-time cost that pays for itself when an incident occurs.

Key Takeaway

The shipper is deliberately simple and procedural. Its value comes from rigorously following a checklist — pre-checks, conventional commit, feature branch, PR, CI verification, rollback docs — without exceptions. The hard rule of never committing to main ensures that every change goes through the PR review process.

Related Agents

• reviewer — provides Gate 2 approval that triggers the shipper
• developer — receives routing when pre-ship checks or CI fail
• documenter — receives handoff after successful ship to update documentation
• tester — receives routing when test failures block the ship