用途
该技能的目标是让 Pull Request 更容易被评审：帮助评审者快速理解变更意图、重要文件和风险。默认目标是在不改变代码行为的前提下提升可评审性。
主要能力
- 解析目标 PR：根据用户提供的 URL 或当前分支确定要处理的 PR。
- 检查现状：查看提交、diff 规模、变更路径、生成文件以及 PR 描述。
- 识别可评审性问题：噪声提交、过时描述、无关改动、机械改动与逻辑改动混杂、缺少测试、评审入口不清晰等。
- 提出计划：在重写历史或强制推送之前先给出方案。
- 应用安全改进：实施改进后，验证目录树或 diff 仍与预期代码一致。
使用方式
历史清理
仅在用户要求或同意计划时才重写历史。重写前可执行：
gh pr view <PR> --json title,headRefName,baseRefName,state,commits
git fetch origin <headRefName> <baseRefName>
ORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree})
良好的提交分组通常遵循依赖顺序：
- Schema/存储或生成的 API 定义。
- 核心逻辑。
- 接线与集成。
- UI 或表层行为。
- 测试。
重写后验证内容一致性：
echo "Original tree: $ORIGINAL_TREE"
echo "Current tree: $(git rev-parse HEAD^{tree})"
git diff origin/<headRefName> --stat
如果目录树发生了非预期的变化，不要推送。
评审指引
当代码行为应保持不变时，优先通过 PR 描述和评审说明来改善可评审性：
- 添加与实际 diff 一致的 TL;DR。
- 将核心文件与生成或机械文件分开说明。
- 指出有风险的行为变更、迁移顺序、发布计划和测试覆盖。
- 当 issue 跟踪器、看板或设计文档能解释意图时，提供链接。
适用场景
- 提交历史杂乱、需要整理为清晰分组以便评审。
- PR 描述过时或缺失，评审者难以理解意图。
- 变更中混有生成文件、机械改动与核心逻辑改动，需要区分重点。
- 需要向评审者标注风险、迁移顺序、发布计划与测试覆盖。
限制与护栏
- 绝不把有意义的行为变更隐藏在“清理”之中。
- 除非用户明确要求，否则不要绕过 hooks。
- 如果 PR 过大，无法仅靠说明变得可评审，应建议拆分，而不是围绕问题做表面修饰。
- 重写历史或强制推送前必须先提出计划并获得用户同意。
- 重写后若目录树非预期变化，不得推送。