mcpField
S
ship-pr

ship-pr

github.com/tester-army测试与质量12.1k270 次安装今天更新
代码仓库

关于 ship-pr

ship-pr 是一项技能，用于将代码库变更从验证推进到评审和 PR 跟进。它规定检查、验证证据、独立上下文评审及后续处理步骤，直到 PR 可供人工评审。

主要功能

  1. 01运行代码库检查与测试
  2. 02在受影响的界面验证变更
  3. 03安排独立上下文评审
  4. 04创建并跟进 PR

适用场景

  1. 01准备软件包或文档 PR
  2. 02依据构建产物验证变更
  3. 03处理评审意见并完成交接

MCP 相关

该技能包含在 MCP 服务界面上验证变更的步骤。

安装

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

$npx skills add https://github.com/tester-army/e2e --skill ship-pr

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

详细介绍

发布 PR

打开 PR 并不代表大功告成。真正的终点是 PR 已标记为 Ready for Human Review：已根据构建后的软件包完成验证，经另一位审阅者审查，所有检查通过，且已处理每条机器人的讨论线程。人只应花时间做判断。

运行每个步骤。如果某一步无法运行，请在交接说明中指出是哪一步以及原因，不要默默跳过。

1. 检查

**重要：**首先，对本次变更涉及的每个指南页面运行 authoring-docs 中的精简流程（docs/**/*.mdx，不包括 docs/reference/），即使只修改了一段内容也不例外。本次变更涉及的参考页面则按 authoring-docs，参考页面 的要求处理：先写 ## Reference，使用精简的摘要表格，并保留所有事实。之后的检查会捕捉这两种流程破坏的锚点。

对你修改的内容运行 CI 中的检查，并修复所有问题：

pnpm check                    # lint, dead code, typecheck, error codes, peer ranges, docs
pnpm test                     # or the touched package: pnpm --filter e2e run test:unit
pnpm --filter @e2e-dev/testbed test
pnpm test:web-benchmark       # when the runner, web engine, or benchmark changed

然后检查 pnpm check 无法发现的仓库规则（AGENTS.md 中的“Contracts”）：

  • 对已发布软件包的用户可见变更，添加 .changeset/ 条目；即使是功能变更，0.x 版本也要提升 patch。只有变更不兼容（摘要以 **Breaking:** 开头）或维护者要求发布大版本（**Release:**）时，才提升 minor。
  • 行为变更要在同一变更中更新相应的 docs/**/*.mdx 页面，包括“尚未实现”的提示；如果 skills/e2e/ 描述了变更涉及的界面，也要更新。
  • 公共 API 变更要检查生成的 .d.ts，并更新 packages/e2e/tests/types/sdk-types.ts；协议线上的变更要同时修改 schema、两个 fixture 和生产方。
  • 新增的构建输入或基准测试依赖要加入 .github/filters.yml。
  • 新增的集成、CI 服务或迁移指南，侧边栏图标以及每张链接到它的卡片都要使用供应商的徽标，不能用 Font Awesome 占位图标。集成页面或 CI 页面还要在其概览页面中添加卡片（参见 authoring-docs，页面图标）。软件包 PR 和文档 PR 一样，都必须遵守此项规则。

2. 验证

使用 verify 技能，在变更涉及的界面上证明变更有效：在测试床或基准测试中验证构建后的 CLI、MCP 服务、init 的临时项目，或文档站点。Bug 修复要对比 main 与当前分支。保留输出和任何视频，供 PR 使用。

3. 在新的上下文中自我审查

编写变更的 Agent 不应负责评判它。启动一个不了解本次对话内容的审阅者（子 Agent 或新会话），并将填写了基准分支的 references/review-prompt.md 提供给它。修复你认可的所有 critical 和 important 问题，然后针对修复涉及的内容重新运行步骤 1 和 2。对于拒绝的每项问题，保留一句话说明理由，以便写入 PR 正文或交接说明。

无法启动审阅者：自己在全新的上下文中，按照同一提示从头到尾重新审阅整个 diff，并在交接说明中注明。

4. 提交并创建 PR

  • 从最新的 origin/main 分支创建分支。提交遵循 Conventional Commits。
  • 使用 writing-pr 技能撰写标题和正文。正文应包含步骤 2 的验证证据。
  • 创建可直接审查的 PR，不要创建草稿： gh pr create --base main --title ... --body-file <file> --attach <each screenshot and video> （gh 2.99+）。正文必须包含 writing-pr 中说明的 ## Verified 部分；如果内容过于简略，使用 gh pr edit --body-file <file> --attach ... 修正。
  • 多 PR 变更：先创建所有层级的 PR，每一层都基于其下方的一层，然后再跟进处理。

5. 跟进处理

将 PR 交给 babysit 技能并执行到底：所有检查通过、讨论线程已处理、已添加 Ready for Human Review 标签。对于 PR 堆栈，从底层开始跟进处理；只有当某一层自身已准备就绪时，才为其添加标签。

交接

向用户回复以下内容：

  • PR URL 及其标签状态
  • 如何完成验证（界面、运行的内容、看到的内容、媒体）
  • 根据审查意见修复了什么、忽略了什么及原因
  • 留给用户处理的事项：升级处理的讨论串、无法验证的部分、拒绝处理的范围

评论

支持 Markdown