review-pr

用途

review-pr 是一项审查者侧的合并风险评估技能，面向三类目标：GitHub Pull Request、分支差异（branch diff）以及本地工作区差异（working-tree diff）。其核心理念是把变更当作一个带有预期结果的提案来审阅，而不是一堆文件的集合，审查时优先关注目标达成、正确性、安全性、数据安全、契约兼容性、测试证据以及已有审查状态。

适用场景

资料列出的触发场景包括：

“review PR #123”“review this PR”“review github.com/owner/repo/pull/N”
“is this safe to merge?”“merge readiness check”“give this PR a review”
“walk this diff”“review main...feature-branch”“review origin/main...HEAD”
“review my staged changes”“review my working tree”“review this local diff”
“validate this codex-review finding against the diff”（程序化逐项模式）
“the PR already has CodeRabbit/Copilot/Greptile comments — what's left to flag?”
“cluster the changed files and flag the highest-risk ones”
“this PR has 40 changed files; tell me what to look at first”

资料同时列出了不适用场景：作者侧交接（应使用 review-self）、对已收到的反馈做分类（应使用 review-feedback）、仓库状态清理（应使用 run-repo-cleanup）、运行时调试（应使用 debug-runtime），以及仅涉及样式或格式化的反馈（应交给 lint/formatter 自动化）。

主要能力

该技能定义了调用契约（invocation contract），涵盖了用户提示模式、技能工具模式和斜杠命令/编排模式，分别对应不同的输入、输出与变更边界。程序化逐项模式会输出如下形状的 JSON：

{
  "decision": "accepted|rejected|ambiguous",
  "severity": "blocker|important|suggestion|question",
  "evidence": ["file:line"],
  "rationale": "Why the item does or does not survive review.",
  "intended_fix_shape": "Optional only for accepted items."
}

在逐项模式下，除非调用方要求解释性 Markdown，否则只返回该 JSON 对象。

技能还定义了严重程度标定（severity calibration）与证据契约（evidence contract）。严重程度分为：🔴 Blocker（安全缺陷、数据丢失、常见路径崩溃或导致 PR 不安全的目标准确性缺失）、🟡 Important（可能的 bug、契约缺口、缺失校验/错误处理、明显性能问题或高风险行为的覆盖缺失）、🟢 Suggestion（不改变合并安全性的改进）、💡 Question（意图或行为不清晰，或证据不足）、🎯 Praise（做得好的具体之处，至少包含一条）。标定规则指出：超过 3 个 blocker 需重新评估；总发现超过 10 条需重新应用可操作性门槛；同一问题跨多个文件应合并为一条发现。

证据契约要求每条发现都必须包含：严重程度、简洁标题、确切的 file:line 或行范围、观察到的行为、在该 PR 中的影响，以及建议的修复或澄清问题。

使用方式

技能以 SKILL.md 承载 8 个操作阶段，并通过引用文件与脚本展开深层能力：

阶段 1 — 分类请求（triage）
阶段 2 — 在查看代码前收集上下文（使用 references/workflow/review-workflow.md、references/workflow/gh-cli-reference.md、scripts/parse-pr.sh）
阶段 3 — 范围界定与文件聚类（references/analysis/file-clustering.md、scripts/cluster-files.sh）
阶段 4 — 读取已有审查状态（references/workflow/comment-correlation.md、references/workflow/automation.md、scripts/parse-pr.sh）
阶段 5 — 目标验证（references/workflow/review-workflow.md）
阶段 6 — 按聚类审查（references/dimensions/review-dimensions.md、security-review.md、performance-review.md、bug-patterns.md、language-specific.md、references/analysis/diff-analysis.md）
阶段 7 — 横切扫描（references/analysis/cross-cutting.md、references/analysis/large-pr-strategy.md）
阶段 8 — 校准、综合与输出（references/output/output-templates.md、communication.md、anti-patterns.md）

在开始审查前，必须用一行命名确切的对比目标（如 owner/repo#123、origin/main...HEAD、main...feature-branch、HEAD + staged + unstaged）。若无法用一行命名目标，则应停止并请求缺失的目标。

深度按变更行数校准：少于 100 行全diff深度审查；100–500 行深度审查高风险聚类并轻量扫描低风险聚类；500–1000 行深度审查最高风险聚类并说明哪些区域被略读；超过 1000 行或范围混乱时标记 PR 规模/范围并建议具体拆分点。

输出与边界

默认输出为 Markdown/聊天。只有在请求明确要求 submit、post、publish 或 comment 时，才允许对 GitHub 做变更。形式化 GitHub 审查模式要求一条 gh pr review 判决及正文，不产生意外的行内评论；行内评论模式在明确请求且带行元数据时才批量合并为一个审查事件。

判决阶梯为：✅ Approve（无 blocker、目标达成、仅剩次要问题或疑问）、💬 Comment（存在非阻塞问题或开放疑问）、🔄 Request Changes（存在 blocker、目标失败或未处理的风险缺口）。仅有建议时不应请求变更。

限制

资料明确说明该技能不用于作者侧交接、已收到反馈的分类、仓库清理和运行时调试；纯样式或格式化反馈应交由自动化工具处理。本地 diff 模式下 PR 正文、CI 和审查线程可能不可用，此时需标注“Existing review state: unavailable in local diff mode.”。该技能不应用修复，应用操作由调用方负责（逐项模式下 caller owns apply）。仓库地址、安装命令、平台与价格信息在资料中暂未提供。

技能介绍

用途

适用场景

主要能力

使用方式

输出与边界

限制