create-pr

创建 PR

创建一个无需阅读对话内容、审核者也能理解的 PR。利用额外的调用文本和会话发现，说明问题、最终行为和证据。遵循用户要求的格式和目标仓库的指导。

工作流

1. 检查范围和基准

   • 阅读仓库指导，并检查 git status、已暂存的更改和当前分支。
   • 遵守仅处理已暂存内容的要求。切勿暂存无关工作；如果分支已包含所请求的更改，也无需要求创建新的提交。
   • 确认目标远程仓库和基准分支。从 main/master 创建分支前，先获取该远程仓库，并使用 git merge --ff-only <remote>/<base> 将本地基准快进到最新状态。保留未提交的工作；如果快进失败则停止。切勿通过重置丢弃这些工作。
   • 按照仓库的命名规范创建简短分支。切勿直接提交到 main。

2. 完成并检查更改

   • 提交前对已暂存的差异运行 /simplify，并应用其发现。仅文档差异无需处理。对于任何已暂存的更改，遵循 commit-staged。
   • 仅当请求的更改导致现有文档不准确时，才更新文档。
   • 检查所有提交中的 git diff <remote>/<base>...HEAD。对于已有 PR，使用其实际基准分支和头部分支；如果当前检出的是其他分支，则使用 gh pr diff <pr>。
   • 运行适当的检查并收集实际结果。根据最终更改核实会话发现，包括链接、数量、错误和基准测试的来源。

3. 撰写并发布

   • 使用以下标题和正文指南。如果 PR 已存在，使用 update-pr-summary，不要重复创建。
   • 将正文原样写入仓库之外的临时文件，并将其传给 gh 的 --body-file。切勿在 shell 命令中插入文本，也不要意外包含命令输出。
   • 推送分支，并使用明确的基准分支、--title、--body-file 和 -a @me 创建 PR。
   • 仅当用户明确要求添加审核者，或该作者近期的 PR 有审核者时才添加审核者： gh pr list --repo <owner>/<repo> --author @me --limit 5 --json reviewRequests。
   • 使用 gh pr view <pr> --json title,body,url 读取已发布的标题和正文。检查代码围栏、表格、链接和媒体是否保留。对于视觉更改，打开 PR 并确认图片可正常显示。报告 URL 及任何未完成的核实项。

标题和正文

• 标题：以大写动词开头，并明确指出具体行为，例如 修复复制会话文本时丢失换行符的问题。不要添加类型前缀、内部品牌名称或 含糊的说法。最终范围发生变化时，重写标题和正文。
• 开篇说明触发条件和后果：漏洞何时发生、会导致什么问题，以及修复为何重要？ 对于功能，说明用户现在可以做什么。不要以“此 PR”开头。
• 将不同要点写成简短的项目符号，通常为 1-3 条。不要把多个想法塞进一个段落，也不要 为了满足字数要求而删掉有用的证据。小改动可能只需一句话和一个代码片段。需要区分 复现、修复和结果时，使用简短的小节。省略空白或模板化的小节。
• 对于漏洞，提供最精简且有用的复现步骤、实际错误／输出和预期行为，然后说明最终 改动如何修复问题。能体现故障时，使用准确的日志。省略无关的设置过程、原始工具输出 和调试过程记录。
• 使用可复制的用法／复现代码片段、简洁的修复前／修复后表格，或分别标注的修复前和 修复后代码块来展示行为。优先使用这些方式，而不是要求审阅者自行推断结果的红绿 差异行。不要强行为仅修改文案的改动添加代码片段。
• 将测量结果和主分支与当前分支的对比放入小表格。说明解读数据所需的数据集、工作负载 或样本数量。在相关问题、提交、文档和结果产物能支撑论述时，添加链接，而不是只列出 改动文件。
• 简洁说明已完成的验证：相关命令或检查、结果，以及重要限制或已有故障。未来的 测试清单不能作为证据。不要根据有针对性的检查声称完整运行成功，也不要淡化已验证的 完整运行结果。
• 只写能解释修复或权衡的实现细节。必要时提及净增减的行数或基础分支中的无关改动， 以便区分实际审阅范围。
• 不要添加 AI 署名、会话链接、重复标题或总结性的宣传语。

视觉证据和现有内容

• UI／设计改动需要在双列表格中展示清晰易读的修复前／修复后图片或 GIF。保持视口和 场景一致，并在使用前检查视觉效果。分析／绘图改动需要提供有代表性的输出和测量结果， 并确保它们在显示尺寸下清晰可读。
• 绝不要将 PR 截图或生成的图表提交到分支。遵守用户和仓库的托管规则。如果允许上传 发布资源，请使用现有且合适的发布版本，并嵌入资源 URL。也要保留现有的 GitHub 附件 URL。
• 对于 Ultralytics 仓库，绝不要将视觉素材上传到发布资源中。向用户提供本地绝对路径、 PR 链接，以及每张图片应手动上传的位置（具体句子或表格单元格）。不要编造附件 URL， 也不要声称待上传的内容已可见。
• 编辑正文时，保留用户上传的图片／GIF、机器人添加的上下文、相关链接和仍然有效的证据， 除非用户要求删除。只编辑相关部分，不要替换整个正文。将证明材料保留在正文中，不要 在单独的评论里重复。

示例：已完成检查的漏洞

Copying a multiline command into a session loses its line breaks.

| Before | After |
|---|---|
| Pasted command becomes one line | Original line breaks survive |

- Preserve clipboard newlines at paste time
- Reuse the existing text insertion path

**Reproduce**
```sh
printf 'first\nsecond\n' | pbcopy
# Paste into an open session.
```

**Checked:** paste regression passes for multiline and single-line commands.

根据证据调整此结构。对于 UI 改动，对比表格的单元格应包含实际截图／GIF。对于较长的 输出，使用表格之外的独立代码块。