review-pr

本地评审

系统地进行评审，仅提供可执行且经过验证的反馈。 将此技能用作交付前明确的本地自检步骤，而非原生 PR 评审工具的通用替代方案。 如果编码会话产生了值得检查的更改，请在 /done 前运行此技能。

参考文件

文件	阅读时机
references/severity-rubric.md	默认：选择严重程度标签并筛除依据不足的发现
references/comment-examples.md	生成本地评审报告前
references/review-surfaces.md	决定工作应继续进行本地自检，还是交接给 PR 专用工作流时
references/security-checklist.md	差异涉及身份验证、输入处理、外部 API、文件上传或环境配置时
references/performance-checklist.md	差异涉及数据获取、渲染、图像、依赖项或会影响打包结果的导入时

范围

• 默认目标：已暂存或尚未提交的本地更改
• 次要目标：工作树干净或用户要求评审分支时，将当前分支与基线进行比较所得的差异
• 明确的 PR 请求属于次要情况：采用相同的评审标准，但将其视为交接路径，而非主要工作流
• 将此技能聚焦于具体错误、明显重要的验证／测试缺失，以及对仓库说明文件的遵循情况
• 不要将此技能用于处理收到的 PR 评论或解决讨论串；请改用 pr-comments

工作流

复制此清单以跟踪进度：

Review progress:
- [ ] Discover local review target
- [ ] Gather context and scoped instruction files
- [ ] Choose the local review path
- [ ] Validate findings
- [ ] Produce the review report

1. 确定评审目标：
   • 如果存在已暂存或未暂存的更改，优先评审这些更改
   • 否则，评审当前分支与基线之间的差异
   • 只有当用户明确指向现有 PR 时，才改为提供 PR 交接摘要
   • 记录当前分支和已更改文件，确保报告以本地会话为依据
2. 收集上下文：
   • 从会话、近期提交或用户请求中了解更改意图
   • 加载相关的仓库说明文件（适用时包括 AGENTS.md / CLAUDE.md，以及其代码位于差异中的嵌套 package/MFE 目录下的文件）
   • 仅对已更改路径应用适用的说明文件规则
   • 运行项目的 lint、类型检查和测试命令（取自 package.json 脚本），以记录当前状态；注明已有的失败，以便与更改造成的回归区分开来。在报告中包含 lint、类型检查和测试的状态，让读者了解评审时的基线状态
3. 选择本地评审路径：
   • 默认进行本地自检：评审当前差异／分支，并在聊天中提供本地报告
   • 现有 PR 请求属于次要情况：采用相同的验证标准，然后提供简明的交接摘要，而不是改变主要工作流
   • 对于大型更改，按子系统拆分评审，并汇总为最终报告
4. 验证问题：
   • 报告前重新检查具体行
   • 只保留可信度高的问题；删除推测性或重复的问题
   • 确认每个问题仍适用于最新差异，且对应某个已更改行
   • 将根因相同的多条评论合并为一个发现
5. 生成报告：
   • 默认输出：在聊天中提供本地评审报告
   • 将发现归入 推送前必须修复、应尽快修复 和 可交接 三类
   • 不要发布行内评论、解决讨论串，也不要通过此技能处理收到的评审反馈
   • 将收到的 PR 反馈交由 pr-comments 处理

仅报告高置信度问题

仅在确认无误时报告：

• 代码无法编译（语法、类型、导入）
• 代码会产生错误行为（明确的逻辑或状态错误）
• 代码引入了具有直接利用途径的具体安全风险——如果 diff 涉及身份验证、输入处理、外部 API 或环境配置，请加载 references/security-checklist.md，按照其中的三层分类进行评估
• 代码引入了可衡量的性能退化——如果 diff 涉及数据获取、渲染、图像或依赖项，请加载 references/performance-checklist.md，检查其中常见的瓶颈模式
• 更改的行为明显缺少必要的回归测试或验证测试，包括：新增组件或 Hook，却没有随附的测试文件；或者现有测试中的每条断言都只是检查渲染内容是否存在（expect(getByText(...)).toBeInTheDocument()），没有用户交互或分支覆盖
• 修复 Bug，却没有先编写能复现该问题的失败测试（先证明模式：如果修复正确，针对该 Bug 的测试应在修复前失败、修复后通过）
• 测试代码对共享设置进行了过度抽象，导致读者必须追踪辅助函数才能理解单个测试（测试代码应优先采用 DAMP — 描述性且有意义的短语，而不是 DRY）
• 更改导致 lint、类型检查或测试失败（请与步骤 2 中记录的既有失败区分开来）
• 明确违反指令文件（引用规则并确认其适用范围）
• YAGNI 违规：代码添加了当前需求并不需要的抽象、配置系统或扩展点（三行相似代码也胜过过早抽象）
• KISS 违规：实现比问题所需的更复杂——存在能达到相同效果的更简单做法

绝不报告：

• 风格、质量或主观偏好
• 与更改无关的既有问题
• 依赖未知输入的潜在问题
• 可能会被自动捕获的仅限 linter 的问题
• 已明确忽略的违规

输出格式

如果需要回顾格式，请先阅读 references/comment-examples.md，再生成报告。

默认本地输出：

## Local review

### Must fix before push
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

### Should fix soon
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

### Ready for handoff
- <brief readiness summary>

如果用户明确指出了一个现有 PR，请将同样经过验证的问题整理成简洁的交接摘要：

## PR handoff summary

- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

摘要（如果没有问题）：

## Local review

### Must fix before push
- None.

### Should fix soon
- None.

### Ready for handoff
- No blocking issues found. Checked for high-confidence bugs, missing validation/tests, and instruction-file compliance on the current local changes.

反模式

• 本地更改可用时，先询问 PR 编号 → 先审查本地 diff
• 默认将行内审查评论作为输出 → 优先采用本地审查流程
• “这可能会导致问题” → “变量 x 在 src/foo.ts:45 处未定义，导致运行时出现 ReferenceError。”
• “考虑重构” → “违反了指令文件中的规则‘<引用规则>’，适用文件为 src/foo.ts。”
• 针对同一根本原因提出多条评论 → 合并为一条评论，并链接所有受影响的位置

相关技能

• 审查完成后使用 done 记录会话
• 收到反馈后使用 babysit-pr 对传入的审查讨论串进行分类和处理

每个报告的问题都应是资深工程师会发现的问题。