用途：引导维护者逐步理解一个 PR，先弄清目标与质量门槛，再梳理改动历史与上下文，确保在形成意见或起草评论前真正读懂 PR。全程要求回复简短、信息密集，并以 A/B/C/D 字母选项结尾，用户只需输入单个字母继续。
主要阶段：解析 PR 编号与可选 --working-file 路径，校验分支、获取 PR 元数据与 diff、识别当前用户。人员分析：判断作者是维护者、常规贡献者还是首次贡献者，统计其合并 PR 数、关联 issue 作者及其 issue 数。关联 issue：读取 PR 引用的 issue 标题、正文、标签、评论与作者。阶段 1 PR 目标：基于描述、提交信息和关联 issue 总结目标；若涉及公共 API、导出接口、CLI、配置或用户可见行为，需展示改动前后对用户的影响，然后让用户确认。阶段 2 质量门槛：检查 CI 状态、测试改动、diff 是否聚焦、changeset、仓库其他要求，以及作者是否声明亲自验证，未达标时给出应对选项。阶段 3 历史与上下文：对每个改动文件查 git log、--all 与 blame，阅读周边代码、architecture、测试质量与方案合理性，并把理解写入工作文件或 .pr-review/HISTORY.md，逐块交互呈现。阶段 4 逐段讲解 diff。阶段 5 理解检查，可出 3-5 道选择题。阶段 6 先听用户意见再直接给出自己的判断。阶段 7 可选起草评论。
用法与限制：需在仓库中运行，依赖 gh 与 git；gh 输出常含 ANSI 颜色码破坏 jq，应使用 gh 的 --jq 或 NO_COLOR=1。未经用户明确批准不得发布评论；发布时经由 REST API 避免 GraphQL 速率限制，可用 gh api rate_limit 查看配额。