mcpField
S
ship-pr

ship-pr

github.com/e2e-inc开发13.8k271 次安装今天更新
代码仓库

关于 ship-pr

指导贡献者将 Pull Request 准备到可供人工审查的仓库技能，涵盖检查、使用构建后的包验证、独立审查、创建 PR 及后续跟进。

主要功能

  1. 01运行 CI 和仓库专属检查
  2. 02在相关使用界面验证变更
  3. 03在全新上下文审查差异
  4. 04创建可供审查的 PR
  5. 05跟进修复和审查讨论

适用场景

  1. 01准备包变更以供审查
  2. 02验证 CLI 或 MCP 服务变更
  3. 03处理多层 PR 变更栈
  4. 04完成 PR 检查并处理机器人讨论

MCP 相关

该技能要求通过 testbed 上的 e2e MCP 服务验证 MCP 变更，并说明按需注册和重启服务以进行验证。

安装

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

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

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

详细介绍

发布 PR

打开 PR 并非终点。终点是让 PR 带上 Ready for Human Review 标签：根据构建后的软件包完成验证，由一位全新的审阅者审查，所有检查通过，并处理每条机器人评论。人类只应花时间做判断。

运行每个步骤。如果某一步无法运行，请在交接说明中写明具体步骤及原因，不要悄悄跳过。

1. 检查

**重要：**首先，对变更涉及的每个指南页面（docs/**/*.mdx 中除 docs/reference/ 以外的页面）运行 authoring-docs 中的精简流程，即使只改了一段内容也要运行。变更涉及的参考页面则应遵循 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；wire 变更应同时修改 schema、两个 fixture 和 producer。
  • 新的构建输入或基准测试依赖应添加到 .github/filters.yml。
  • 新集成、CI 服务或迁移指南应在每个链接到它的卡片上使用供应商的 logo，不得使用 Font Awesome 占位图标，并且要在所属章节的概览页面添加卡片（参见 authoring-docs，供应商 logo）。软件包 PR 也同样需要遵守此规则，文档 PR 也不例外。

2. 验证

使用 verify 技能，在变更涉及的功能范围内证明变更有效：在测试环境或基准测试中验证构建后的 CLI，验证 MCP 服务，使用临时项目测试 init，或验证文档站点。修复错误时，应将 main 与分支进行对比。保留输出和 PR 所需的视频。

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

编写变更的 Agent 不得自行评判。启动一位不了解本次对话的审阅者（子 Agent 或新会话），并提供填写了基准分支的 references/review-prompt.md。对于你认同的每条 critical 和 important 发现，都要修复，然后针对修复涉及的内容重新运行步骤 1 和 2。对于你驳回的每条发现，都要留下一句理由，供 PR 正文或交接说明使用。

如果无法启动审阅者：根据同一提示词，冷静地重新审阅完整差异，并在交接说明中注明。

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