用途：Ship 是一条“交付流水线”，把当前分支从代码完成一路推进到合并，本身只做编排，每一步都调用已有的同类技能，不在这里重新实现审查规则、提交规范或 PR 模板。
主要能力与流水线：共 6 步——1. 预检：确认存在 diff、工作区状态已知并选定基线分支；2. 代码审查：对基线分支的 diff 调用 review-code，仅分析不改文件，出现 Critical/High 必须修复或由用户明确接受风险后重跑，3 轮仍失败即停止；3. 预合并检查：自动探测项目自身的门禁，如 justfile 的 visual-diff/test/check 配方、Makefile 的 test/check/lint 目标、package.json 的 test/lint/typecheck/e2e 脚本，没有则回退到框架原生命令（pytest、cargo test 等），任何非零退出都要修复后重跑；4. 提交：按 git-commit 规范（Conventional Commits、祈使语气、只暂存相关文件）；5. PR：按 git-create-pr 规范创建 PR；6. CI 与合并（可选）：用 gh pr checks <number> --watch 观察 CI，绿了才合并，默认 squash，除非仓库自身约定不同，禁止强推和绕过钩子或必需检查。每个门禁最多 3 轮修复，之后停止并报告。
必要用法与依赖：需要 git 与 gh（brew install gh），并确认 gh auth status 成功，否则先运行 gh auth login。基线分支可用 --base 指定，否则取 gh repo view --json defaultBranchRef -q .defaultBranchRef.name，再否则 main。拒绝在 main/master/dev 上直接运行；--no-merge 或用户只要求开 PR 时在第 5 步停止。检测阶段建议用 Haiku 的 Explore 子代理以免占用主线程上下文。
限制与报告：每个阶段的结果必须引用真实执行的命令及其真实退出状态或输出，未运行的阶段标为 SKIPPED:，绝不估算或推断；所有报告（停止或完成）都以阶段表收尾，列为 # | Stage | Command | Result。