这个 Skill 能做什么，适合哪些场景？
ship-pr 是 e2e 仓库（tester-army/e2e）内置的技能，定义了一条从"实现完成"到"可人工审查"的完整 PR 流程。它要求先跑与 CI 相同的检查、用 verify 技能证明改动、再由一个没有本次对话记忆的"新鲜"评审者自审，然后按 Conventional Commits 提交并开 PR，最后交给 babysit 技能盯到绿灯、处理完所有机器人线程。终点被明确定义为一个打了 Ready for Human Review 标签的 PR，而不是仅仅打开了 PR。它的核心信念是：人只需要花时间做判断，机械性的工作全部由流程承担。
- 对改动涉及的 docs/**/*.mdx 页面先跑 authoring-docs 的缩短流程，再执行 pnpm check、pnpm test、testbed 测试和（必要时）web 基准测试
- 对照 AGENTS.md 和"Contracts"里 pnpm check 看不到的仓库规则：changeset 条目、文档同步、.d.ts 与 sdk-types.ts 更新、filters.yml 登记
- 用 verify 技能在实际界面（CLI、MCP 服务器、init 项目或文档站）上证明改动，保留输出和视频作为 PR 证据
- 生成一个无记忆的评审者（子代理或新会话），用 references/review-prompt.md 对基线分支做冷读自审，并处理每条 critical/important 发现
- 从最新 origin/main 分支、按 Conventional Commits 提交、用 writing-pr 技能写标题和正文（含 ## Verified 章节），通过 gh pr create 开非草稿 PR 并附截图/视频
- 调用 babysit 技能盯到 CI 绿灯、机器人线程处理完毕、打上 Ready for Human Review 标签（多 PR 堆栈自底向上逐层处理）
- 在 e2e 仓库里完成了一项实现，被要求"开 PR"或"提交这个改动"的贡献者
- 修复 bug 后需要在 PR 里附上 main 与分支对比的验证证据的核心开发者
- 修改了 runner、web 引擎或基准时，需要连带跑 web 基准测试的维护者
- 处理公开 API 变更时需要审查生成的 .d.ts 并更新 sdk-types.ts 的包作者
- 需要提交多层堆栈式改动、每层各开一个 PR 并逐层盯到就绪的贡献者
- 想确保 PR 打开前每条文档锚点、changeset 和机器人线程都被处理掉的流程执行者
- 不属于 tester-army/e2e 仓库的其他代码库——技能硬编码了 pnpm check、@e2e-dev/testbed、filters.yml、Ready for Human Review 标签等该仓库专属约定，直接迁移需要大改
- 只想快速开一个草稿 PR、不做验证和自审的个人小改动场景——流程强制要求验证证据、新鲜上下文评审和 babysit，无法跳过
- 没有子代理机制且无法接受"自己冷读 diff"这一降级方案的平台使用者——技能的核心设计依赖无记忆评审者
如何安装这个 Skill？
- 本技能为内部工作流技能（internal: true），只适用于 tester-army/e2e 仓库的 CI 与目录结构，勿在其他仓库套用。
- 技能强依赖同仓库的 verify、babysit、writing-pr、authoring-docs 技能与 gh 2.99+，静态审查无法确认这些引用在当前修订下全部有效。
- 发布者 TesterArmy 未经过 FollowSkills 企业注册表验证，归属证据有限。
- 静态审查未执行任何命令，所有评分均为源文件推断，置信度低。
- Shell / 命令行
- 网络访问
- 本地文件系统
pnpmGitHub CLI (gh 2.99+)gitNode.js/pnpm workspace for the e2e repo
源材料未提供独立的安装命令。该技能位于 e2e 仓库的 .dev/skills/ship-pr/SKILL.md，随仓库一起分发，属于仓库内部工作流技能（元数据标注 internal: true）。
git clone https://github.com/tester-army/e2e
cd e2e如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 实现已经完成，帮我开一个 PR，把这个修复提交给 e2e 仓库的 main 分支
- 按 ship-pr 流程把这个改动 ship 出去，包括验证证据和自审
- 这个功能做完了，下一步是审查——跑一遍完整的 PR 流程直到打上 Ready for Human Review 标签
- 帮我提交这三层堆栈改动，每层各开一个 PR 并逐层盯到就绪
触发方式：当你被要求 open / create / ship / submit 一个 PR，或实现已完成、下一步是审查时，代理会读取该技能的描述并进入流程。流程为固定五步：1) 先跑文档缩短流程，再跑 pnpm check / pnpm test / testbed 测试及仓库规则检查；2) 用 verify 技能在实际界面上验证并保留输出和视频；3) 生成无记忆评审者做冷读自审（无子代理时自己冷读 diff 并声明）；4) 从最新 origin/main 分支按 Conventional Commits 提交，用 writing-pr 写 PR，gh pr create 开非草稿 PR 并附媒体；5) 交给 babysit 技能盯到绿灯和 Ready for Human Review 标签。任何一步无法执行，必须在交接中说明原因，不得悄悄跳过。多 PR 堆栈按自底向上顺序 babysit，每层独立就绪才打标签。
这个 Skill 有哪些优点和局限？
- 终点定义清晰：不是打开 PR 而是打到 Ready for Human Review 标签，机器人线程全部处理完
- 强制验证证据：PR 正文必须携带 ## Verified 章节，附输出、截图和视频，人类可快速复核
- 新鲜上下文自审机制：要求由无记忆的评审者判断改动，明确指出'写改动的代理不评判它'，并有降级方案
- 覆盖 CI 之外的仓库规则：changeset、文档同步、.d.ts/schema 一致性等 pnpm check 捕捉不到的约定被显式列出
- 失败模式被治理：无法执行的步骤必须显式交接说明，禁止悄悄跳过
- 深度绑定单一仓库：pnpm 脚本、@e2e-dev/testbed、filters.yml、AGENTS.md、Ready for Human Review 标签均为 e2e 仓库专属，换仓库需重写
- 依赖一整套兄弟技能（authoring-docs、verify、writing-pr、babysit），单独使用 ship-pr 流程不完整
- 元数据标注 internal: true，设计意图是仓库内部工作流而非对外通用技能
- 最佳运行方式（无记忆子代理评审）依赖平台的子代理能力；没有时只能降级为自己冷读 diff
- 依赖 gh 2.99+ 的 --attach 参数等较新功能，环境过旧会失败
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| Ship a PR（e2e 仓库 PR 交付流程） 本页 | 59 · 推荐 | ★ 8.7k | 1 天前 | Apache-2.0 |
| writing-pr：PR 标题与描述撰写规范 | 58 · 推荐 | ★ 8.7k | 1 天前 | Apache-2.0 |
| RenderCV PR 审查助手 | 55 · 谨慎使用 | ★ 18k | 6 个月前 | MIT |
| Codex Pull Request 编辑器 ✓ OpenAI · 官方 | 50 · 谨慎使用 | ★ 128k | 3 天前 | Apache-2.0 |
| Yeet 一键 GitHub PR 流程 ✓ OpenAI · 官方 | 41 · 不推荐 | ★ 28k | 3 个月前 | — |
仓库未提供与其他 PR 工具的直接对比，无法从源材料得出可靠比较。
FollowSkills 如何评估这个 Skill？
该技能仅描述仓库内 PR 流程：运行 pnpm 检查、用 gh 打开 PR、生成评审子代理。无破坏性默认操作、无需凭据读取、无数据外传；仓库另有详尽 SECURITY.md 与遥测披露，权限意识强（CI 明确拒绝 pull_request_target 接密钥）。扣分项：技能自身未声明最小权限边界（gh 调用、子代理生成的副作用未逐一说明），回滚/中止路径未写明，未验证的发布者使归属核实不完全，故不满分。
指令内部自洽，步骤编号清晰，对异常有明确交代规则（'若一步无法运行，说明是哪一步及原因'），且为无法生成评审者的场景提供了自评审回退。扣分项：强依赖四个未在本次源材料中给出的同级技能（verify、babysit、writing-pr、authoring-docs）及 gh 2.99+、pnpm 等环境，静态阅读无法确认引用完整或路径有效，未展示失败反馈的具体形态，按静态上限不超过 10。
frontmatter 描述明确触发词（被要求打开/创建/提交 PR），internal: true 标注了非公开范围，受众（本仓库维护者）清楚。扣分项：能力边界主要局限于 tester-army/e2e 仓库的 CI 结构（filters.yml、testbed 等），对其他仓库的非适用性未声明；中文支持与中国大陆可达性未提及（依赖 GitHub/npm，一般可达但未确认），边界证据不足，故 11。
文档分层好：SKILL.md 主流程 + references/review-prompt.md 补充材料 + 关联技能链接；仓库层面有 Apache-2.0 许可、changesets 版本管理与清晰的 CI 治理注释。扣分项：技能本身无版本号/变更记录，internal 技能的维护责任与更新路径未写明，部分关键假设（如 changeset 条目格式、AGENTS.md 内容）未随文给出，扣至 11。
工作流设计有明显边际价值（新鲜上下文自评审、验证证据随 PR、babysit 到标签），输出格式（PR 正文 Verified 节）有明确要求。扣分项：静态阅读无法验证实际产出可直接使用，效果依赖未见的兄弟技能与真实 CI 行为，按静态上限不超过 7，保守评 6。
仓库含可审计的 CI 工作流（benchmark、agent）与大量真实测试文件，为技能所述检查命令（pnpm check/test、testbed）提供了旁证。扣分项：技能的关键路径（打开 PR、评审、babysit）无提交的执行证据，第三方独立复现不存在，静态上限 5，评 4。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →