mcpField
S
ship-it

ship-it

github.com/jssblck开发01.7k 次安装3 周前更新
代码仓库

关于 ship-it

ship-it 是用于交付软件变更的开发技能,面向需要提交代码、发布 Pull Request 并跟进 CI 的开发者。它依据请求范围处理分支、审查、验证、证据和结果报告。

主要功能

  1. 01在功能分支提交变更
  2. 02创建或复用 Pull Request
  3. 03运行项目要求的审查与验证
  4. 04跟踪 CI 并处理相关失败
  5. 05在 PR 中提供验证证据

适用场景

  1. 01完成变更并提交可审查的 PR
  2. 02修复 CI 问题并跟进检查结果
  3. 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 全部通过。

评论

支持 Markdown