piv-review-pr

审查 PR：人工审查前的 Agentic 把关

输入：$ARGUMENTS

这项技能的核心是以全新视角审查：在干净的上下文中审查 PR——而不是编写代码时使用的上下文——并可将深入分析交给 code-reviewer agent。这正是审查能够发现作者自己的上下文会合理化忽略的问题的原因。它会在 PR 上发布审查结论，然后由人工做出最终决定。

阶段 1 — 获取 PR

将输入解析为 PR 编号（数字、URL，或通过 gh pr list --head <branch> --json number -q '.[0].number' 查询分支）。然后：

gh pr view {N} --json number,title,body,author,headRefName,baseRefName,state,additions,deletions,changedFiles,files
gh pr diff {N}
gh pr checkout {N}

状态检查：MERGED/CLOSED → 停止（“无需审查”）；DRAFT → 给出审查方向，不要批准或阻止。

阶段 2 — 加载上下文（以便按照正确标准审查）

• CLAUDE.md 和任何 .claude/references/ — 项目标准就是审查准则。
• 实现报告（如果 piv-implement 编写过 — .claude/reports/*{branch}*）及其计划：阅读记录的偏差。记录在案的偏差是有意的决定，不是问题——只标记未记录的偏差。（没有报告？照常审查，并注明缺少报告。）
• PR 自身的意图（标题/正文）：它声称要解决什么问题。

阶段 3 — 运行验证

运行项目实际使用的验证套件（piv-validate 技能，或计划中的验证命令）——测试、类型检查、lint、构建。记录通过/失败情况及数量。验证套件失败本身就是一项问题。

阶段 4 — 审查差异（派发 code-reviewer agent）

如果项目有 code-reviewer 子 Agent（.claude/agents/code-reviewer.md），就将深入审查交给它；否则在本次会话中以干净的上下文进行审查——依据项目标准检查，并且只报告高置信度问题。为了解上下文，要完整阅读每个变更文件（不只是差异）。审查范围：正确性 · 类型安全 · 是否符合模式/标准 · 安全性 · 性能 · 是否包含测试 · 可维护性。

按严重程度对每个问题分类：

严重程度	含义
Critical	阻断性问题——安全、数据丢失、崩溃
High	合并前应修复——类型安全漏洞、缺少错误处理、逻辑错误
Medium	模式不一致、缺少边界情况、未记录的偏差
Low	建议、细微润色

也要肯定做得好的地方——审查应当具有建设性，而不只是列出缺陷。

阶段 5 — 做出决定

• 批准 — 没有 Critical/High 问题，验证通过，且符合意图。
• 请求更改 — 存在 High 问题、可修复的验证失败，或未记录的模式违规。
• 阻止（强烈请求更改）— 存在 Critical 安全/数据问题，或采用了根本错误的方案。
• 遵循显式的 --approve / --request-changes 标记，但绝不能在尚有未解决的 Critical 问题时批准。

阶段 6 — 发布到 GitHub 并保存报告

将报告写入 .claude/code-reviews/pr-{N}-review.md（摘要 · 按严重程度列出问题，并附 file:line 和修复方案 · 验证表 · 做得好的地方 · 建议）。然后发布：

# approve
gh pr review {N} --approve --body-file .claude/code-reviews/pr-{N}-review.md
# request changes
gh pr review {N} --request-changes --body-file .claude/code-reviews/pr-{N}-review.md
# or just comment (draft PRs / advisory)
gh pr comment {N} --body-file .claude/code-reviews/pr-{N}-review.md

输出 + 交接

打印：PR 编号/URL · 各严重程度的问题数量 · 验证结果 · 建议。然后交接： “已发布到 PR。现在由人工审查代码和这份审查报告，然后合并。” 如果存在问题，自然的下一步是根据报告运行 piv-fix-review-findings，然后重新运行验证。

说明

• 以全新视角审查是核心——在干净的上下文中运行此流程（或让 code-reviewer agent 提供干净的上下文）。不要用编写代码的会话进行审查；它会合理化，而不是仔细审视。
• 这是 agentic 把关流程；它不会取代人工，而是为人工提供一份经过验证、完成分级的 PR 以供批准。要深入推进，可以使用多个审查 Agent、针对你的技术栈调整审查者，并在其后构建验证金字塔。