detailed-pr-description

PR 详细说明

明确处理结果

• 评估： 判断分支测试是否足够有力；不要起草或更新 PR 正文。
• 起草： 在本地或回复中生成拟议的正文；不要修改 GitHub。
• 更新／发布： 仅在明确要求更新、编辑、发布或公布时，才起草正文并更新 GitHub。

若请求包含多个结果，请逐一完成。可访问 CLI 绝不代表获得了修改 PR 的授权。

工作流程

1. 确定 PR 和目标分支。优先使用 gh pr view --json number,title,body,baseRefName,headRefName,url；如果没有 PR，则与用户提供的基准分支或仓库默认基准分支进行比较。依赖旧引用之前，先获取最新内容。
2. 从 git status --short、差异统计和文件名、相关提交、变更文件、测试、文档、迁移、配置及生成的产物中收集证据。将 .context/ 视为临时目录；任何有用信息都要重新陈述，因为其中的文件未被跟踪。不得依赖聊天记录或记忆来说明行为。
3. 确定问题、方法、结果、刻意排除的内容、风险、兼容性、边界情况、运维注意事项、迁移、标志、清理工作及评审重点。对于需要仔细评审的内容，提供精确的文件／行号引用和说明。每篇 PR 正文都必须包含一段来自最重要评审代码片段中实际变更代码、配置或文档的围栏代码块，最多 15 行；仅提供链接的评审部分并不足够。
4. 列出受影响的测试和新增测试。先运行范围最小且可靠的检查；可行时，再运行文档中说明的更广泛验证。将覆盖情况评为充分、部分充分或不足；指出这些测试能捕获的回归、重要缺口及具体的后续测试。不得根据未运行或不相关的测试声称有信心。
5. 仅交付获准的结果：
   • 评估：报告证据和覆盖情况判断，不创建正文。
   • 起草：返回正文或写入 .context/pr-description.md；绝不调用 gh pr edit。
   • 更新／发布：写入 .context/pr-description.md，然后使用 gh pr edit <number> --body-file .context/pr-description.md。如果发布失败，保留草稿并说明原因。

PR 正文

对于起草／更新工作，使用 assets/pr-body.md.tmpl，除非仓库有更优先的模板。正文必须脱离聊天记录或本地备注也能独立理解。优先提供高价值上下文；仅在相关时添加截图、发布计划、迁移、标志、性能、无障碍、安全或发行说明。仅当某个章节确实不适用时才删除空章节；如果省略该章节可能掩盖重要的评审维度，则填写「不适用」。

质量标准

• 以代码、测试、文档、提交或命令输出为依据陈述；区分事实、假设和判断。
• 保留现有标题和有用的正文内容，除非替换版本更清晰。
• 描述具体行为，不要使用「各种修复」或「改善行为」之类的说法。
• 对需要仔细评审的内容提供精确的文件／行号引用。包含一段实际变更内容的围栏代码块；该内容必须具有实质帮助，且不超过 15 行。
• 说明验证失败、跳过或不可用的情况及其原因。
• 除非明确要求，否则不要进行无关的代码修改。

最终回复

如果存在 PR URL，请报告该 URL，并说明结果属于评估、本地草稿还是已发布更新；列出验证命令及结果，并给出最终的覆盖情况判断。如果获准的发布失败，请报告草稿路径。