需要评估测试覆盖或起草/更新 GitHub PR 描述时…

适用于有 GitHub PR 或分支变更，需要判断测试是否足够、起草本地 PR 描述、或明确授权后更新 GitHub PR body 的场景。

适用场景

解决思路

1. 先解析请求要交付的结果：Assessment 是判断分支测试是否足够，不要起草或更新 PR body。
2. Draft 是在本地或响应中生成建议 body，不要改动 GitHub。
3. Update/post 仅在明确要求 update、edit、post 或 publish 时，才起草并更新 GitHub。
4. 当请求组合了多种结果时，分别执行每个被请求的结果。
5. CLI 访问权限绝不等于授权修改 PR。
6. 识别 PR 和 base：优先运行 `gh pr view --json number,title,body,baseRefName,headRefName,url`；没有 PR 时，与用户提供或仓库默认 base 比较；依赖 ref 前先 fetch，避免使用过期 ref。
7. 从 `git status --short`、diff 统计与文件名、相关 commits、changed files、tests、docs、migrations、config、generated artifacts 建立证据。
8. 将 `.context/` 视为草稿区；因为它是未跟踪文件，任何有用事实都要在交付内容中重新陈述。
9. 行为性断言不要依赖聊天或记忆。
10. 明确问题、方案、结果、刻意排除项、风险、兼容性、边缘情况、运维坑点、迁移、标志/flag、清理项和 reviewer 关注点。
11. 对需要 close review 的条目，给出精确的文件/行引用和解释。
12. 每个 PR body 必须包含一个 fenced excerpt，来自最需要 review 的 hunk 的实际变更代码、配置或文档，最多 15 行。
13. PR body 的 review 部分不能只有链接；只有链接的 review 部分不够。
14. 清点受影响和新增的 tests。
15. 运行最窄且可靠的检查，然后在可行时运行文档化的更广泛验证。
16. 将覆盖率分类为 sufficient、partially sufficient 或 insufficient。
17. 说明覆盖率能捕获哪些回归、重要缺口和具体后续测试。
18. 绝不要基于未运行或不相关的 tests 声称有信心。
19. 只交付被授权的结果。
20. Assessment：报告证据和覆盖率判断，不创建 body。
21. Draft：返回 body 或写入 `.context/pr-description.md`；绝不调用 `gh pr edit`。
22. Update/post：写入 `.context/pr-description.md`，然后使用 `gh pr edit <number> --body-file .context/pr-description.md`。
23. 如果发布失败，保留草稿并解释原因。
24. 对于 draft/update 工作，加载 `assets/pr-body.md.tmpl`，除非仓库有更强的模板。
25. PR body 必须独立成立，不依赖聊天或本地笔记。
26. 优先高信号上下文；仅在相关时添加 screenshots、rollout、migrations、flags、performance、accessibility、security 或 release notes。
27. 仅当空 section 确实不适用时才删除；当省略可能隐藏重要 review 维度时，使用 `Not applicable`。
28. 用 code、tests、docs、commits 或 command output 支撑结论；区分事实、假设和判断。
29. 保留现有 title 和有用 body 内容，除非替换更清晰。
30. 命名具体行为，不要写“various fixes”或“improves behavior”。
31. 对 close-review 条目引用精确文件/行；包含一个实际变更摘录，放在 fenced code block；必须实质有帮助且最多 15 行。
32. 包含 failed、skipped、unavailable 的验证及原因。
33. 除非明确要求，不要做无关代码改动。
34. 最终响应中报告 PR URL（如果存在）、结果类型是 assessment、local draft 还是 posted update、验证命令/结果，以及底线覆盖率评估。
35. 如果授权的 post 失败，报告草稿路径。

适用边界 · 注意事项

• 未明确要求 update、edit、post 或 publish 时，不要修改 GitHub PR；Draft 和 Assessment 都不应调用 `gh pr edit`。
• 没有实际代码、测试、文档、commit 或命令输出支撑时，不要声称测试覆盖足够或行为已验证。
• 不要在 PR 描述中只放链接而没有实际变更摘录，也不要为凑模板保留不适用且会隐藏关键 review 维度的空 section。