关于 ship
ship 是将已完成的改动从工作区推进到提交、推送和部署检查的技能。它指导开发者按逻辑拆分提交、管理拉取请求、监控 CI，并确认线上结果。
主要功能
- 01检查改动文件并扫描机密
- 02按逻辑变更分别提交
- 03使用 Conventional Commit 格式
- 04推送并处理合并与分支
- 05监控 CI 检查
- 06确认线上部署结果
适用场景
- 01发布已完成的功能或修复
- 02为不同改动准备独立拉取请求
- 03确认 CI 与生产环境状态
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/ship确认已加载。
附带文件agents/openai.yaml
详细介绍
发布
此技能将已完成的工作从工作树交付到生产环境。它会拆分为小型提交、推送、合并、监控检查，并确认结果已上线。
推送就意味着推送
当用户说推送、发布或合并时，要完成所有步骤。除非需要用户提供凭据或批准，否则把命令交还给用户就算违规。提交中出现秘密信息始终属于 HIGH。
变更本身的检查会在此技能启动前通过 verify 运行。
1. 检查工作树
运行 git status 并阅读每个已更改的文件。指出本任务中并非由你修改的文件，并在提交前询问用户。提交意外文件属于 ship-flag-stray-files。扫描差异，查找密钥、令牌、密码和 .env 文件。提交秘密信息属于 ship-no-secrets。
2. 按变更提交
每个逻辑变更单独提交。把一个功能、一项修复和一次重命名放进同一个提交属于 ship-commit-per-change。每条提交消息都要遵循 Conventional Commit 格式：type(scope): summary，使用祈使语气、小写字母，且不加句号。使用 feat、fix、docs、refactor、chore 或其他标准类型；有破坏性变更时，在类型后加 !。使用类似“Remove the archive.” 的消息属于 ship-conventional-commits。在会发布版本的软件包中，随变更一并添加 changeset。发布版本相关的变更没有 changeset 属于 ship-changeset-for-packages。
3. 推送、合并并清理
推送分支。用户要求合并时，合并分支、删除该分支，并切回默认分支。合并后仍留存的分支属于 ship-merge-and-tidy。每个缺陷或功能都要单独开一个拉取请求。一个拉取请求捆绑三项修复属于 ship-one-pr-per-bug。更改 UI 的拉取请求要附带截图。这属于 ship-screenshot-ui-prs。
4. 监控检查
等待 CI，并修复失败项。在检查仍失败或仍在运行时报告“已推送”属于 ship-watch-checks。
5. 完成闭环
变更修复了某个问题时，关联该问题、关闭它，并在问题提出处回复。缺陷已修复但对应问题仍未关闭属于 ship-close-the-loop。变更部署后，打开线上 URL 或已发布版本并进行检查。没有查看生产环境就说“已部署”属于 ship-confirm-live。
6. 只把需要用户处理的事交还给用户
完成所有你能自行执行的步骤。只在需要登录、双重验证代码或批准时询问，并明确说明具体需要什么。列出命令让用户运行属于 ship-do-the-steps。
对照
每条检查都有一组对照：有问题的做法旁边就是替代做法。
| 规则 | 有问题的做法 | 替代做法 |
|---|---|---|
ship-flag-stray-files | 工作树中有他人的文件时运行 git add -A | 指出该文件，然后询问 |
ship-no-secrets | 提交 .env.local | 忽略 .env.local，并标记该秘密信息以便轮换 |
ship-commit-per-change | 一个提交包含一个功能、一项修复和一次重命名 | 三个提交，每项变更一个 |
ship-conventional-commits | Remove the archive. | chore: remove the archive |
ship-changeset-for-packages | 软件包修复没有 changeset | 在同一提交中包含 changeset |
ship-merge-and-tidy | 已合并，但仍检出该分支 | 已合并、已删除，并切回 main |
ship-one-pr-per-bug | 一个拉取请求包含三个缺陷 | 三个拉取请求 |
ship-screenshot-ui-prs | UI 拉取请求没有图片 | 在说明中附上截图 |
ship-watch-checks | CI 仍在运行时说“已推送” | “已推送，所有检查均已通过” |
ship-close-the-loop | 修复已合并，但问题仍未关闭 | 问题已关联、关闭并回复 |
ship-confirm-live | “已部署” | “已在生产 URL 上线并完成检查” |
ship-do-the-steps | “准备好后运行 npm publish” | 已发布，或“需要你的双重验证代码” |
报告
严重程度。 HIGH 表示提交了机密信息、提交了多余文件，或发布时检查未通过。MEDIUM 表示提交或拉取请求捆绑在一起、修复后仍有未关闭的问题，或交回了本可自行执行的步骤。LOW 表示消息不符合 Conventional Commit、缺少屏幕截图，或合并后仍留有分支。
格式。 每个根本原因列出一项发现；若不适用于任何文件，则注明步骤：
file:line - [rule-id] what is wrong
step 3 - [rule-id] what is wrong
然后提供 Rule | Count | Severity 汇总。若仍有任何 HIGH，则标记为 Block；否则标记为 Approve。对于所有未能全程观察的检查，标记为 Not verified。