pr-code-review

PR 代码审查

面向 open-skills 的可移植 PR 审查。结合 Anthropic Claude Code code-review 插件流程（资格检查、多视角、≥80 置信度、永久链接评论）、mattpocock 的 Standards∥Spec 分离 + 固定点 diff，以及 Superpowers 的 计划一致性 / 严重程度 / 优势优先 习惯。平台无关的 Agent 调度（不对宿主模型层级进行硬编码）。

安装：npx skills add FuDesign2008/open-skills -g --skill pr-code-review --yes

适用场景

• 用户要求审查一个已开启的 PR/MR，或 merge-discipline Part R 要求合并前审查。
• 跳过（说明原因，不要发表评论）：PR 已关闭、处于草稿状态、改动琐碎或由自动化生成，或者本次会话中本技能已审查过该 PR 的当前 tip。

深度（full | light）

调用方（尤其是 merge-discipline Part R）可以传入 depth=full 或 depth=light。默认值：full。

深度	行为
full	双轴 Standards∥Spec；宿主支持时优先并行进行多视角审查（当前默认流程见下文）
light	仍必须对固定的 tip 进行双轴 Standards∥Spec 审查；不要求并行多视角协作。Critical/Important 问题的置信度 ≥80 才能通过，以及发布规则均不变

未指定深度参数的独立用户请求必须使用 full。

流程

1. 资格检查 — PR 已开启、非草稿且需要审查；本次会话中尚未审查过该 tip。否则停止。
2. 确定深度 — 使用调用方指定的 full（默认值）或 light。
3. 固定审查点 — 使用 PR/MR 的 base ref、用户提供的 commit/branch，或合并候选的 origin/<default-branch>。确认 ref 可解析，且与 tip 的三点 diff 非空。diff 为空 → 中止（不要启动多视角审查）。
4. 确定 Spec 来源（采用首个匹配项）：PR/issue 正文及其链接的工单 → 用户指定路径 → OpenSpec change delta / 相关的 openspec/specs → 询问用户 → 否则 Spec 轴 = 跳过（无可用规范）。
5. 确定 Standards 来源 — AGENTS.md / CLAUDE.md（根目录 + PR 涉及的目录），以及存在时的编码规范文档。可选的代码异味基准：reference.md（仓库文档优先；代码异味属于判断事项，绝不能单独作为硬性违规依据）。
6. 概述 — 简要总结变更（标题、意图、diff 形态）。
7. 双轴审查（不要跨轴合并排序）：
   • Standards 轴 — 违反文档所述指导原则的情况（引用文件 + 规则）；可选代码异味启发式检查。
   • Spec 轴 — 计划行为缺失或不完整；无正当理由的范围扩张；错误实现已声明的要求（引用规范/计划中的原文）。没有 Spec 来源时跳过整个轴。
   • 仅限 full： 也优先并行进行多视角审查（仅关注 diff 中的 bug、blame/历史记录、同一文件的过往 PR 评论、文件内注释指导）。
   • light： 跳过强制并行协作；单次双轴审查即可。
8. 校准 — 对每个保留的问题候选，评定严重程度 Critical / Important / Minor，然后评定置信度 0–100（见下方标准）。剔除低于 80 分的候选。 对应关系：经验证的 Critical/Important 通常为 ≥75–100；Minor 通常会被剔除，除非属于指导原则中的硬性要求。
9. 优点 — 如有，先于问题简要列出（准确的肯定有助于建立对其余内容的信任）。
10. 重新检查资格 — 发布前确认 PR 仍处于开启状态且 tip 未变。
11. 发布 — 通过 gh / glab 发表评论（或宿主禁止发表评论时在当前会话中报告）。评论中分设双轴章节；使用完整 SHA 永久链接。模板见：reference.md。

置信度标准

分数	含义
0	误报 / 预先存在的问题 / 经不起仔细推敲
25	未经验证 / 风格问题 / 指导原则中未提及
50	问题属实，但只是小问题或极少出现
75	很可能属实且重要；或指导原则/计划中明确要求
100	确凿属实；证据充分

应丢弃的误报

已有问题；相似但并非缺陷的问题；吹毛求疵的小问题；可由代码检查器／类型检查器／编译器发现的问题；泛泛的“增加更多测试／文档／安全措施”建议（除非指南／计划有要求）；未更改的行；PR 范围内的有意行为。

宿主约定（merge-discipline Part R）

• 针对即将合并的已打开 PR/MR运行，并采用 Part R 选定的深度（full 或 light）。
• 通过 → 两个维度均不保留评分 ≥80 的严重或重要问题（仅有轻微问题或所有评分均低于 80，均视为通过）。light 深度不得弱化此门槛。
• 未通过 → 向调用方报告未通过。merge-discipline Part R 负责修复 → 持续重新审查，直至无问题（或用户在 Part R 中明确选择跳过／接受残留并留痕），之后才能进入 Part D。仅实现审查发现的问题不代表 Part R 已通过。
• CI 通过／跳过覆盖率检查不能作为替代。
• 不得要求完成完整的代码审查意见处理流程，才能通过 Part R。

反馈后的处理（可选指引）

处理审查意见（来自人工或此技能）时：更改前先对照代码库核实；不要只做表面认同；如果意见有误，应给出有理有据的技术反驳；不清楚的事项应先澄清再实现。完整的意见处理规范是可选的，且不属于 Part R。

集成指南

• 强依赖 merge-discipline；若缺失，则中止并执行
  npx skills add FuDesign2008/open-skills -g --skill pr-code-review --yes
• 不要重命名为 code-review（会与外部名称冲突）。