Back to Details

ship-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ship a PR

提交 PR

Opening a PR is not the finish line. The finish line is a PR labeled 
Ready for Human Review
: verified against the built packages, reviewed by a fresh pair of eyes, green, and every bot thread handled. A human should only ever spend time on judgment.
Run every step. If one cannot run, say which and why in the handoff instead of skipping it quietly.
创建 PR 并不是终点。真正的终点是 PR 已添加 
Ready for Human Review
标签：已针对构建后的包完成验证、由全新视角审阅、状态全绿，且所有 bot 讨论串均已处理。人工应该只把时间花在需要判断的事项上。
每一步都必须执行。如果某一步无法运行，应在交接说明中指出具体步骤及原因，而不是悄悄跳过。

1. Checks

1. 检查

Run what CI runs for what you touched, and fix everything:
bash
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
Then the repo rules 
pnpm check
cannot see (
AGENTS.md
, "Contracts"):
  • A user-visible change to a published package adds a 
    .changeset/
    entry.
  • Behavior changes update the matching 
    docs/**/*.mdx
    page in the same change, "not implemented yet" callouts included, and 
    skills/e2e/
    when it describes the changed surface.
  • A public API change reviews the emitted 
    .d.ts
    and updates 
    packages/e2e/tests/types/sdk-types.ts
    ; a wire change edits the schema, both fixtures, and the producer together.
  • A new build input or benchmark dependency goes into 
    .github/filters.yml
    .
针对变更部分运行 CI 会执行的检查，并修复所有问题：
bash
pnpm check                    # lint、死代码、类型检查、错误码、对等依赖范围、文档
pnpm test                     # 或针对变更的包：pnpm --filter e2e run test:unit
pnpm --filter @e2e-dev/testbed test
pnpm test:web-benchmark       # 当 runner、web engine 或 benchmark 发生变化时
然后检查 
pnpm check
无法发现的仓库规则（
AGENTS.md
、"Contracts"）：
  • 对已发布包的用户可见变更，需要添加一个 
    .changeset/
    条目。
  • 行为变更需要在同一次修改中更新对应的 
    docs/**/*.mdx
    页面，包括 "not implemented yet" 提示；如果 
    skills/e2e/
    描述了发生变化的功能范围，也需要同步更新。
  • 公共 API 变更需要检查生成的 
    .d.ts
    ，并更新 
    packages/e2e/tests/types/sdk-types.ts
    ；wire 变更需要同时修改 schema、两个 fixture 和 producer。
  • 新增构建输入或 benchmark 依赖时，需要将其加入 
    .github/filters.yml
    。

2. Verify

2. 验证

Prove the change with the verify skill on the surface it touches: the built CLI on the testbed or a benchmark, the MCP server, a scratch project for 
init
, or the docs site. Bug fixes capture main against the branch. Keep the output and any video for the PR.
使用 verify skill，在变更涉及的操作面上证明变更有效：可以是 testbed 或 benchmark 上基于构建产物的 CLI、MCP server、用于测试 
init
的临时项目，或文档站点。Bug 修复需要对比 main 与分支来捕获问题。保留输出及所有视频，以供 PR 使用。

3. Self-review in a fresh context

3. 在全新上下文中自审

The agent that wrote the change does not get to judge it. Spawn a reviewer with no memory of this conversation (a subagent, or a new session) and give it references/review-prompt.md with the base branch filled in. Fix every 
critical
and 
important
finding you agree with, then rerun steps 1 and 2 for what the fixes touched. For each finding you reject, keep the one-line reason for the PR body or handoff.
No way to spawn a reviewer: re-read the whole diff cold against the same prompt yourself, and say so in the handoff.
编写变更的 Agent 不能自行评判自己的变更。创建一个不记得当前对话上下文的审阅者（subagent 或新会话），向其提供 references/review-prompt.md，并填写 base branch。修复所有你认同的 
critical
和 
important
审阅发现，然后针对修复涉及的部分重新执行第 1 步和第 2 步。对于每个未采纳的发现，保留一行原因，以备写入 PR 正文或交接说明。
如果无法创建审阅者：使用相同提示词，以冷静且不受先前上下文影响的方式重新通读整个 diff，并在交接说明中如实注明。

4. Commit and open

4. 提交并创建

  • Branch off an up-to-date 
    origin/main
    . Commits follow Conventional Commits.
  • Title and body with the writing-pr skill. The body carries the verification evidence from step 2.
  • Open it ready, not draft: 
    gh pr create --base main --title ... --body-file <file> --attach <each screenshot and video>
    (
    gh
    2.99+). The body must carry the 
    ## Verified
    section 
    writing-pr
    describes; fix a thin one with 
    gh pr edit --body-file <file> --attach ...
    .
  • Multi-PR change: open every layer, each based on the one below, before babysitting.
  • 从最新的 
    origin/main
    创建分支。Commit 遵循 Conventional Commits。
  • 使用 writing-pr skill 编写标题和正文。正文需要包含第 2 步的验证证据。
  • 创建时就绪，而不是草稿： 
    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，并确保每个 PR 都基于其下方的一层。

5. Babysit

5. 持续跟进

Hand the PR to the babysit skill and run it to the end: green, threads handled, 
Ready for Human Review
label. For a stack, babysit bottom-up; a layer is labeled only when it is ready on its own.
将 PR 移交给 babysit skill，并一直运行到结束：状态全绿、讨论串处理完毕，并添加 
Ready for Human Review
标签。对于 PR 栈，自底向上进行跟进；只有当每一层单独达到就绪状态后，才能为其添加标签。

Handoff

交接

Reply to the human with:
  • the PR URL and its label state
  • how it was verified (surface, what you ran, what you saw, the media)
  • what you fixed from review, what you dismissed and why
  • anything left for them: escalated threads, parts you could not verify, scope you declined
向用户回复以下信息：
  • PR URL 及其标签状态
  • 验证方式（操作面、运行的命令、观察到的结果及相关媒体）
  • 根据审阅意见修复了什么，以及驳回了哪些发现及其原因
  • 仍需用户处理的事项：已升级的讨论串、无法验证的部分，以及拒绝承担的范围