关于 ship-it
ship-it 是用于交付软件变更的开发技能,面向需要提交代码、发布 Pull Request 并跟进 CI 的开发者。它依据请求范围处理分支、审查、验证、证据和结果报告。
主要功能
- 01在功能分支提交变更
- 02创建或复用 Pull Request
- 03运行项目要求的审查与验证
- 04跟踪 CI 并处理相关失败
- 05在 PR 中提供验证证据
适用场景
- 01完成变更并提交可审查的 PR
- 02修复 CI 问题并跟进检查结果
- 03监控 PR 状态并报告阻塞因素
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ jssblck/ agents --skill ship-it安装后在 Claude Code 中输入/ship-it确认已加载。
附带文件agents/openai.yaml
详细介绍
发布
对于完整的发布请求,完成后应提交并推送更改,创建一个已准备就绪的 PR,并确保 CI 全部通过。创建新的 PR 时不要设为草稿,然后在 CI 运行期间完成仓库要求的审查和本地验证。
范围较窄的请求应保持其范围。对于仅修复 CI 的请求,修复受影响的分支和检查项,但不要创建 PR,也不要更改其草稿/就绪状态、目标分支、标题或无关内容。对于仅监控的请求,只报告结果,不做修复。用户明确要求保留草稿时,以此为准,优先于完整工作流。
除非用户要求,否则不要合并 PR。只有遇到重大歧义、必须获得批准,或因现有权限无法解决阻碍时,才暂停。
提交请求的工作
在功能分支上工作,不要在默认分支上工作。如果当前功能分支包含此次更改,就继续使用该分支;否则遵循仓库的命名约定,若没有约定,则使用 agent/。
检查差异和工作区。保留用户的无关更改,并显式暂存指定路径。将相关文件分组为逻辑提交。
提交主题使用祈使语气。若主题未能清楚说明更改原因,则在提交说明中解释。遵循当前生效的署名和标点要求。提交正文每行控制在约 80 列,但 PR 段落不要强行换行。
创建或复用 PR
对于完整的发布请求,推送更改并检查是否已有 PR:
gh pr list --state open --head <branch> --json number,title,url,isDraft,baseRefName,headRefName
复用已有 PR。如果它是草稿,除非用户要求保留草稿,否则使用 gh pr ready 将其标记为已准备就绪。如果不存在 PR,则使用 gh pr create 创建一个非草稿 PR。仅当用户明确要求草稿时,才使用 --draft。除非这是现有堆栈中的依赖层,或用户指定了其他目标分支,否则使用默认分支作为目标分支。
说明更改的必要性和具体内容。适用时,使用 Fixes #<n> 引用原始议题。编辑 PR 正文时,保留已有上下文。除非用户要求,否则不要添加标签或审查者。
按需执行配置的审查和验证
对于完整的发布请求,如果项目定义了签核工作流,则在创建或复用 PR 并设置其预期就绪状态后,运行该工作流。遵循仓库当前的审查政策;没有要求时,不要自行设置门槛。
阅读仓库的检查命令。运行必需的本地检查,以及覆盖所改行为的测试。构建前先生成必需的代码。
- 如果更改涉及集成边界,则包含集成测试。确认相关测试确实运行,而不是被悄然跳过。
- 现有自动化端到端测试可以提供运行时证据。如果没有需要单独检查的风险,不要手动重复这些测试的覆盖范围。
- 对于尚未覆盖的集成或视觉风险,进行手动交互测试。测试有代表性的受影响流程,而不是共享同一组件的所有路由。若更改影响响应式布局,则检查这些布局。
- 对于 CLI 或 API 行为,可通过针对性测试或实际命令/请求提供证据。选择能够发现相应风险的方法。
- 对于没有运行时表面影响的更改,说明无需运行时验证。
- 报告本地环境限制;需要特定平台的检查交由 CI 覆盖。
检查通过后,仅针对新增编辑、失败项或未解决风险,重复或扩展验证。不要为了改进验证流程而重构无关代码。提交并推送任何必要的修复。
添加证据
对于完整的发布请求,请添加一个测试部分,列出准确的命令、结果和相关缺口。现有自动化输出足够时,请直接使用。
使用带语言标记的代码围栏,以精简的内嵌文本提供证据:命令记录使用 console,JSON 使用 json,其他输出使用 text。发布前,请从证明材料中移除密钥和私人数据。
使用 gh --attach 附上有用的屏幕截图或录屏,不要使用 gh-image。
有关受支持的媒体、附件语法和验证方式,请遵循 github-image-upload。如果文本证据足以涵盖更改,则无需媒体。不要提交证明文件。
调用此完整工作流即表示授权将证明材料添加到 PR。请将证据保留在 PR 正文中,保留原有说明,并确保任何必需的署名页脚位于最后。
使用 gh pr view 验证预期的 PR 基准分支、头分支、状态和证据。
跟进已发布的 PR
发布并验证 PR 后,使用 babysit 在等待前检查合并冲突,并持续观察 CI,直至完成。 监控完整的检查集,避免筛选后的视图隐藏失败。对于仅要求监控的请求,请报告冲突,但不要解决冲突。
对于请求范围内的失败,请诊断问题、修复、运行受影响的检查、提交、推送,然后再次观察。行为发生变化时,请更新证明材料。保留必需的检查;不要绕过这些检查,也不要在检查失败、已取消或未按预期运行时声称成功。
请报告无关失败,不要擅自扩大工作范围。如果权限或基础设施阻碍了进度,请指出阻碍因素以及仍未解决的检查。
报告
链接 PR,并说明其实际就绪状态和 CI 结果。概述有意义的更改和验证缺口。只有完整的适用检查集支持这一结论时,才能说 CI 全部通过。