make-pr-easy-to-review

让 PR 易于审查

准备好 PR，让审查者能快速了解意图、重要文件和风险。默认目标是在不改变行为的前提下提升可审查性。

工作流

1. 根据用户提供的 URL 或当前分支确定目标 PR。
2. 检查提交、差异大小、变更路径、生成文件和 PR 描述。
3. 找出影响可审查性的问题：嘈杂的提交、过时的描述、不相关的变更、混杂的机械性变更与逻辑变更、缺少测试，或审查者不清楚从何处入手。
4. 在重写历史或强制推送之前，先提出计划。
5. 应用安全的改进，然后确认工作树或差异仍符合预期代码。

清理历史

只有在用户提出要求或同意计划后，才重写历史。在重写之前：

gh pr view <PR> --json title,headRefName,baseRefName,state,commits
git fetch origin <headRefName> <baseRefName>
ORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree})

合理的提交分组通常遵循依赖顺序：

1. 架构／存储或生成的 API 定义。
2. 核心逻辑。
3. 接线和集成。
4. UI 或表层行为。
5. 测试。

重写后，验证内容一致性：

echo "Original tree: $ORIGINAL_TREE"
echo "Current tree:  $(git rev-parse HEAD^{tree})"
git diff origin/<headRefName> --stat

如果工作树发生了非预期变化，请勿推送。

审查者指南

如果代码行为应保持不变，优先完善 PR 描述和审查说明：

• 添加与实际差异相符的 TL;DR。
• 将核心文件与生成文件或机械性变更分开说明。
• 指出有风险的行为变更、迁移顺序、发布计划和测试覆盖情况。
• 如果问题跟踪器、仪表板或设计文档有助于说明意图，请添加链接。

护栏

• 切勿将有实质意义的行为变更隐藏在“清理”中。
• 除非用户明确要求，否则不要绕过钩子。
• 如果仅靠说明无法让 PR 变得易于审查，请建议拆分，而不是试图粉饰问题。