编写或审查 GitHub PR 描述时：生成面向审阅者…

在打开、更新或审查 GitHub PR，或为审阅者总结分支时使用。

适用场景

解决思路

1. 检查分支 diff、commits、相关 issue 或 discussion、tests、docs 和 changesets。
2. 更新 PR 时，先阅读其当前 body。
3. 填写 `.github/pull_request_template.md`；面向审阅者撰写，而不是写成 changelog。
4. 将 Summary 保持为一个短段落：通常 2–4 句话，约 100 词或更少。
5. 开头先写变更背后的具体问题、用户需求或决策，随后写解决方案和有意义的 behavior；优先使用短句，拆分独立要点，而不是合并成长句。
6. 不要罗列文件或叙述 commits；仅当需要评估行为或风险时，才包含实现细节。
7. 仅当 breaking changes、保留的行为、权衡、范围边界、后续跟进或 stacked PRs 对 review 重要时，才提及它们。
8. 当存在 issue 或 discussion 时，用 `Closes #N`、`Related to #N` 或等价方式链接；不要仅为创建 PR 而创建 issue。
9. 只陈述实际运行过的验证，包括限制或失败。
10. 保留 checklist，并且只勾选已验证项。
11. 发布前，确认 Summary 以为什么需要此变更为开头。
12. 将 body 写入文件，然后通过 `--body-file` 传给 `gh pr create` 或 `gh pr edit`。

适用边界 · 注意事项

• 不适用于非 GitHub 的合并请求/代码审查平台。
• 不适用于没有分支差异、提交、测试或验证信息可供检查的情况。
• 不适用于只想罗列文件或提交日志的 changelog 场景。