用途：用于端到端审查 GitHub 拉取请求，从理解变更到提交结构化反馈，全程使用 gh CLI 与 GitHub 交互。适用场景包括：PR 被指派给你待审、作者修改后二次审查、请求他人审查前自审、对已合并 PR 做事后质量审计，以及希望采用结构化流程而非零散浏览时。
输入：必需 PR 标识（编号、URL 或 owner/repo#number）；可选审查重点（安全、性能、正确性、风格）、代码库熟悉度、时间预算（快速扫描、标准、彻底）。
主要流程：1) 理解上下文，用 gh pr view <number> --json ... 获取元数据，阅读标题与描述，按规模（小/中/大/XL）选择审查方式，用 gh pr view <number> --json commits 查看提交历史，用 gh pr checks <number> 确认 CI 状态。2) 分析 diff，用 gh pr diff <number> 或 gh pr diff <number> --patch 逐文件评估正确性、边界条件、错误处理、安全、性能、命名与测试。3) 按严重级别分类反馈：Blocking [B]（合并前必须修复）、Suggest [S]、Nit [N]、Praise [P]，Blocking 项需说明问题、影响与修复建议。4) 撰写评论：顶层摘要给出整体评估与关键项，内联评论可经 gh api repos/{owner}/{repo}/pulls/{number}/comments 提交，并用 gh pr review <number> --approve/--request-changes/--comment --body 提交审查。5) 跟进：作者更新后重新查看 reviewDecision 与 reviews，仅复审改动，确认 Blocking 已解决后再批准。
限制与注意事项：需要 gh 认证（gh auth status）及仓库访问权限，提交审查需写权限或是被请求的审查者；内联评论失败时可退回把反馈写入审查正文并标注 file:line。应避免橡皮图章式批准、Nit 泛滥、因风格阻塞合并、只挑问题不给表扬、审查超出 PR 范围的既有代码；CI 未通过时不应批准。相关技能包括软件架构审查、代码库安全审计、创建拉取请求与提交变更。资料未提供具体收费、价格或平台信息。