ship 是一个全自动化的发布工作流，用户执行「ship」即表示「直接做」，全程无需逐步确认，最终输出 PR URL，中途只在特定情况下停止。
用途 ship 面向功能分支的发布流程，把合并主干、跑测试、评审 diff、更新版本号、生成 CHANGELOG、提交、推送与创建 PR 串联为一条自动化流水线。
主要能力与流程
- 预检（Step 1）：检查当前分支，若在 main 上则中止并提示「You're on main. Ship from a feature branch.」；运行 git status（不使用 -uall），未提交改动一律包含；通过 git diff main...HEAD --stat 与 git log main..HEAD --oneline 了解待发布内容。
- 合并 origin/main（Step 2，在测试之前）：执行 git fetch origin main && git merge origin/main --no-edit，使测试针对合并后的状态运行。简单冲突（VERSION、schema.rb、CHANGELOG 顺序）可尝试自动解决；复杂或含糊的冲突则停止并展示。
- 运行测试（Step 3，在合并后的代码上）：并行运行 bin/test-lane 与 npm run test，输出分别写入 /tmp/ship_tests.txt 与 /tmp/ship_vitest.txt，随后读取结果判断通过与否。任何测试失败都会展示失败并停止。文档特别提示：不要运行 RAILS_ENV=test bin/rails db:migrate，因为 bin/test-lane 内部已调用 db:test:prepare；裸跑测试迁移（无 INSTANCE）会命中孤立数据库并损坏 structure.sql。
- Eval 套件（Step 3.25，条件触发）：当 diff 涉及提示词相关文件时强制运行。会先通过 git diff origin/main --name-only 匹配一类文件模式（如 _prompt_builder.rb、_generation_service.rb、_evaluator.rb、config/system_prompts/.txt、test/evals/**/* 等），若无匹配则跳过。随后通过 grep eval runner 中的 PROMPT_SOURCE_FILES 定位受影响的套件，并按 runner → test 文件映射运行；judges/support/fixtures 的改动会影响所有使用它们的套件。ship 作为合并前门禁，始终使用 EVAL_JUDGE_TIER=full，命令为 EVAL_JUDGE_TIER=full EVAL_VERBOSE=1 bin/test-lane --eval test/evals/<suite>_eval_test.rb。多套件需串行执行，首个失败即停止以避免继续消耗 API 成本。通过后记录通过数与成本，并把 eval 结果与成本看板写入 PR 正文。
- 落地前评审（Step 3.5）：读取 references/review-checklist.md（读不到则停止并报告错误），对 git diff origin/main 的完整 diff 分两轮应用清单：Pass 1（CRITICAL）关注 SQL 与数据安全、LLM 输出信任边界；Pass 2（INFORMATIONAL）覆盖其余类别。始终输出全部发现，并给出汇总头「Pre-Landing Review: N issues (X critical, Y informational)」。若发现 CRITICAL，逐条直接向用户提问，包含问题（file:line + 描述）、建议修复方案与三个选项：A) 立即修复（推荐）、B) 知悉后继续发布、C) 属于误报并跳过。若任一问题选择了 A，则应用修复、仅按文件名提交被修复文件（git add <fixed-files> && git commit -m "fix: apply pre-landing review fixes"），然后停止并让用户重新运行 ship 以带修复重测；若全部只选 B 或 C，则继续 Step 4。
- 版本号提升（Step 4，自动决定）：读取 VERSION 文件（四段式 MAJOR.MINOR.PATCH.MICRO）。按改动幅度自动决定：MICRO（第 4 位）用于少于 50 行改动、细微调整、拼写或配置；PATCH（第 3 位）用于 50 行以上改动、缺陷修复、中小功能；MINOR（第 2 位）与 MAJOR（第 1 位）需询问用户，分别对应重大功能或显著架构变更、里程碑或破坏性变更。提升某一位会把其右侧各位重置为 0（如 0.19.1.0 + PATCH → 0.19.2.0），然后写回 VERSION 文件。
- CHANGELOG 自动生成（Step 5）：读取 CHANGELOG.md 头部以了解格式，基于分支上全部提交（git log main..HEAD --oneline）与完整 diff（git diff main...HEAD）自动生成，覆盖进入 PR 的全部改动；若分支上已有条目覆盖部分提交，则替换为针对新版本的统一条目。按适用章节分类：### Added（新功能）、### Changed（既有功能变更）、### Fixed（缺陷修复）、### Removed（移除的功能），写简洁描述性要点，插入文件头部之后（第 5 行），日期为今天，格式为 ## [X.Y.Z.W] - YYYY-MM-DD。不询问用户描述改动，而是从 diff 与提交历史推断。
- 提交（Step 6，可二分查找的分块）：把改动分组为逻辑提交，每个提交代表一个连贯变更而非单个文件。提交顺序为先基础设施（迁移、配置、路由），再模型与服务（含其测试），再控制器与视图（含其测试），VERSION 与 CHANGELOG 始终在最后一次提交。拆分规则：模型与其测试同提交，服务与其测试同提交，控制器、视图与其测试同提交，迁移单独提交（或与其支持的模型分组），配置/路由可与所启用的功能同组；若总 diff 较小（< 50 行且 < 4 个文件）可用单次提交。每个提交必须独立有效，不得有破损导入或引用尚不存在代码，依赖需排在前面。提交信息首行为 <type>: <summary>（type = feat/fix/chore/refactor/docs），正文简述内容；仅最后一次提交（VERSION + CHANGELOG）带版本标签与 Co-Authored-By 尾注。
- 推送（Step 7）：git push -u origin <branch-name>，使用常规 push，绝不 force push。
- 创建 PR（Step 8）：用 gh pr create 创建 PR，标题为 <type>: <summary>，正文包含 ## Summary（来自 CHANGELOG 的要点）、## Pre-Landing Review（Step 3.5 的发现，或无问题）、## Eval Results（若运行了 eval：套件名、通过/失败数与成本看板摘要；若跳过则说明无提示词相关文件变更、eval 已跳过）、## Test plan（勾选 Rails 测试与 Vitest 测试通过情况）。最终输出 PR URL。
停止条件 会停止的情况：在 main 分支上；无法自动解决的合并冲突；测试失败；落地前评审发现 CRITICAL 问题且用户选择修复；需要 MINOR 或 MAJOR 版本提升（需询问）。不会停止的情况：未提交改动（始终包含）、版本提升选择（自动选 MICRO 或 PATCH）、CHANGELOG 内容（自动从 diff 生成）、提交信息审批（自动提交）、多文件变更集（自动拆为可二分提交）。
限制与注意 工作流要求从功能分支运行；始终使用 VERSION 文件中的四段式版本格式；CHANGELOG 日期格式为 YYYY-MM-DD；测试与落地前评审不可跳过（若清单文件不可读则停止）；除 MINOR/MAJOR 版本提升与 CRITICAL 评审发现外不请求确认；eval 越界时会倾向于多测以防漏掉回归。资料未提供该工具的安装方式、收费或价格、支持的平台范围等信息，暂未提供。