create-pull-request

创建拉取请求

将已完成的更改发布为一个准确、可供审查的 GitHub 拉取请求。

用户要求创建 PR，即授权在需要时创建分支、提交范围内的更改、以非强制方式推送，以及创建 PR 或更新匹配的未关闭 PR。无需暂停确认即可执行这些操作。此请求不授权合并、自动合并、强制推送、重写历史、添加标签、审查者或受理人、编辑问题，也不授权处理无关更改。

仅在以下情况下停止并报告：

• 更改为空、不完整，或混有归属不明的更改
• 必需的检查失败或无法运行
• 发布失败

1. 确认更改

• 阅读仓库说明、源问题（如有）以及近期的几条提交，了解仓库的惯例。
• head 为当前分支，除非用户指定了其他分支。base 为用户或仓库说明中指定的分支，否则为仓库默认分支。如果 head 就是 base 分支，或 HEAD 处于分离状态，则创建一个以更改命名的分支。
• 审查相对于 base 分支合并基点的完整差异，以及已暂存、未暂存和未跟踪的更改。只暂存属于此次更改的路径。绝不要为了完成发布而暂存、重置、清理、修订提交或变基。
• 如果存在从此 head 指向此 base 的未关闭 PR，则更新该 PR，而不是另建一个。

2. 验证

运行仓库要求的检查。如果仓库未指定检查，则运行能够验证已更改行为的最小范围检查，并运行 git diff --check。如果代码自上次检查后没有变化，则可复用此前的检查结果。绝不要通过弱化测试或绕过失败路径来让检查通过，也绝不要报告未运行的检查。

3. 提交并推送

将所有尚未提交且属于此次更改的修改作为一个提交，提交说明遵循仓库的风格。以非强制方式推送 head 分支。

4. 编写标题和正文

根据已提交的差异、源问题和检查结果撰写标题和正文。仅在对话内容体现于差异中的情况下，才将其用于说明此次更改背后的决策和未采纳的替代方案。读者是需要审查许多拉取请求的工程师。使用简单、日常的措辞，仅在技术术语准确指代某个对象（如文件、命令或 API）时使用。段落要简短，首先说明最重要的内容，并用反引号标记代码标识符。正文长度应与更改规模相称。

标题：用简单的措辞说明结果，让审查者无需打开 PR 也能理解，例如“使用退避机制重试失败的 webhook 投递”，而不是“更新 webhook 逻辑”。

正文，按以下顺序撰写：

## Summary

Two to four sentences: what problem this solves, why it matters, and how behavior changes. A reader who stops here should know what the PR does. End with `Closes #N` when the PR fully resolves that issue in the same repository and targets the default branch, since GitHub closes linked issues only for those merges; otherwise reference it without closing it.

## Changes

The changes grouped by concern, each with the behavior before and after. Explain decisions a reviewer might question and the alternatives you rejected.

## How to review

Where to start, which parts need careful reading, and which are mechanical, such as renames, moved code, or generated files. Name any specific question you want the reviewer's judgment on.

## Verification

The commands run and their results, and manual checks with what they showed, such as how a UI change looks at each width checked. Say what was not tested and why.

## Risks and non-goals

What could break, such as compatibility, migrations, performance, or security; the known limits of a deliberately simple approach, such as "scans the HTML with patterns rather than parsing it, so logos inside nested `<template>` elements are missed"; and what this PR deliberately does not do. Reviewers and `babysit-pr` judge comments against this section, so name each limit and non-goal plainly.

始终包含 Summary 和 Verification。只有在其他部分有实际内容时才添加；单文件修复通常只需要这两部分。绝不要写内容为“无”的章节。

省略逐文件更改清单、对差异内容的复述、未勾选的复选框、机密信息、绝对本地路径和原始命令输出。

将正文写入仓库外的临时文件，并通过 --body-file 传入。

5. 发布并报告

对于匹配的未关闭 PR，如有需要，使用 gh pr edit 更新；如果它是草稿，则运行 gh pr ready。否则，使用明确的 --repo、--base、--head（对于 fork，格式为 OWNER:BRANCH）、--title 和 --body-file 运行 gh pr create。绝不要传入 --draft。如果创建失败或输出不明确，请先检查 PR 是否已存在，再重试。

报告 PR URL、已运行的检查及其结果，以及任何仍在等待的 CI 检查。对于 UI 更改，请将检查时截取的屏幕截图以带绝对本地路径的 Markdown 图片形式展示；这些图片应放在此报告中，而不是 PR 中。保持 PR 未关闭。仅在用户收到 URL 后提出要求时才合并。