mcpField
S
ship-it

ship-it

github.com/timlai666开发045 次安装1 天前更新
代码仓库

关于 ship-it

面向编码 Agent 的交付技能，指导从确认范围到测试、审查、更新 PR 和汇报状态的流程，并依据项目规则和验证结果报告交付情况。

主要功能

  1. 01确认范围、分支、远程端和 PR 基础分支
  2. 02按项目约定同步分支
  3. 03运行测试并审查待提交差异
  4. 04推送前检查机密信息
  5. 05创建或更新 PR 并检查 CI
  6. 06汇报交付状态与阻碍

适用场景

  1. 01准备功能分支以供交付
  2. 02创建 PR 前验证变更
  3. 03更新现有 PR 并检查 CI
  4. 04汇报部署或验证阻碍

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/timlai666/skills --skill ship-it

安装后在 Claude Code 中输入/ship-it确认已加载。

附带文件assets/pr-body.md

详细介绍

第 1 步 — 确认范围和项目规则

阅读项目的协作与交付说明。根据仓库设置和用户意图，确认预期结果、当前分支、目标远程仓库和 PR 基础分支；基础分支未知时，不要猜测为 main。

使用项目现有的交付文档。没有其他约定时，查找 delivery-status.md；旧项目还可使用 delivery-plan.md。阅读当前阶段、预期输出和验收要求，而不只是开头几行。如果差异与约定范围冲突，应在交付前与用户解决这一决定。不要仅为此检查而创建状态文件。

如果存在 delivery-plan.md，请遵循旧版状态迁移规则，检查已保存的决定；如有未解决事项，请询问，并在更改状态安排前记录用户的选择。

检查工作区更改和待推送提交。仅纳入预期工作。对于已获授权的提交，无需再次询问；不要悄悄暂存、丢弃或纳入无关更改。如果工作位于基础分支上，应建立合适的 PR 分支，不要重置现有工作。

创建提交时，编写提交消息前请遵循提交消息规则。

将 _SHIP_REMOTE、_SHIP_BASE 和 _SHIP_BRANCH 设置为已核实的值后：

git status --short
git diff "$_SHIP_REMOTE/$_SHIP_BASE...HEAD" --stat
git log "$_SHIP_REMOTE/$_SHIP_BASE..HEAD" --oneline

第 2 步 — 按需同步

获取目标基础分支，并检查是否需要同步。遵循项目的合并或变基惯例；不要自动将基础分支合并到每个分支中。未经授权，不要改写共享历史。

git fetch "$_SHIP_REMOTE" "$_SHIP_BASE"

根据预期行为和双方的更改解决冲突，然后验证解决结果。只有在无法根据现有证据判断重要的行为或范围决策时，才进行询问。

第 3 步 — 验证行为并审查最终差异

根据更改和风险运行适当的测试。按照项目规则运行完整测试套件。只有在先前结果涵盖当前代码和相关环境时，才可复用；后续编辑或冲突解决后，应重新运行受影响的检查。

检查重要行为、边界条件和错误处理是否都有覆盖。如果这些行为缺少证据，应补充有意义的测试，而不是要求每条新增代码路径都必须有测试，或只测试实现细节。

修复由此分支引入的故障。为已有故障或环境阻碍建立证据，遵循项目交付规则，并报告任何剩余的门槛，不要把部分结果说成全部通过。

除非已有审查涵盖相同差异，否则请对待推送的差异运行 diff-inspector。审查后续更改及其影响。根据严重程度和项目规则处理已确认的问题，并区分尚未解决的疑问与已确认的缺陷。

第 4 步 — 推送并创建或更新 PR

推送前，检查即将推送的提交和差异，查找密钥、令牌、凭据和敏感连接字符串等机密信息。如果发现机密信息，请停止推送并报告其位置，但不要复述机密值。

git push "$_SHIP_REMOTE" "$_SHIP_BRANCH"

创建 PR 前，先检查该分支是否已有 PR。遵循仓库的 PR 模板。如果没有模板，请使用PR 正文模板，填写实际变更和验证结果。根据变更调整详细程度，并删除不相关的部分。

不要在 PR 标题或描述中添加共同作者署名、Co-authored-by 署名行或 Agent 签名。

使用已通过身份验证的 GitHub CLI 时，将填写完成的正文保存到临时文件，并将其路径用作 _SHIP_PR_BODY。根据实际变更设置 _SHIP_TITLE：

gh pr create --base "$_SHIP_BASE" --head "$_SHIP_BRANCH" \
  --title "$_SHIP_TITLE" --body-file "$_SHIP_PR_BODY"

对于已有 PR，请使用填写完成的正文文件，通过 gh pr edit 更新。如果 CLI 不可用或未通过身份验证，请使用可用且经过授权的替代方式，或提供填写完成的标题和正文供手动提交。报告实际成功完成的操作。

第 5 步 — 检查 CI 并记录经验

读取最终 PR 的检查结果，并报告其状态是通过、失败、待处理还是不可用：

gh pr checks "$_SHIP_PR_URL"

如果交付要求包括等待必需的 CI，请主动持续监控这些检查，直到得出结果，并在范围内处理失败：

gh pr checks "$_SHIP_PR_URL" --watch

如果要求验证部署，请找出针对目标修订版本和环境的部署工作流运行。将 _SHIP_RUN_ID 设置为已确认的运行 ID，并明确监控该运行：

gh run watch "$_SHIP_RUN_ID" --exit-status

检查失败的检查项或任务，并在范围内解决问题。报告成功前，验证部署是否达到了要求的结果；无关工作流通过不能作为部署已成功的证据。如果监控受阻或中断，请报告最后观察到的状态、PR 或运行的 URL，以及仍未验证的事项。

在此收尾检查点运行 project-memory，并遵循其记录标准。保存符合条件的项目专属经验，并报告已保存的条目。如果没有符合条件的内容，则无需说明。

交付报告

报告分支和范围、实际测试与审查结果、PR URL、CI 状态以及未解决的要求。根据证据区分已推送、已创建或更新 PR、已合并和已部署。创建 PR 并不能证明其已合并或已部署。

评论

支持 Markdown