pr-reviewer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Local Review

本地审查

Perform systematic review with actionable, validated feedback only. Use this skill as an explicit local self-review step before handoff, not as a generic replacement for native PR review tools. Run it before

/done

when a coding session produced changes worth checking.

仅提供可执行、经验证的反馈，开展系统性审查。将此技能作为移交前明确的本地自我审查步骤，而非原生PR审查工具的通用替代方案。当编码会话产生值得检查的变更时，在运行

/done

前执行此技能。

Reference Files

参考文件

File	Read When
`references/severity-rubric.md`	Default: choosing severity labels and filtering weak findings
`references/comment-examples.md`	Before producing a local review report
`references/review-surfaces.md`	When deciding whether the work stays in local self-review or should hand off to PR-specific workflows
`references/security-checklist.md`	When the diff touches auth, input handling, external APIs, file uploads, or environment configuration
`references/performance-checklist.md`	When the diff touches data fetching, rendering, images, dependencies, or bundle-affecting imports

文件	阅读时机
`references/severity-rubric.md`	默认场景：选择严重程度标签并过滤次要问题
`references/comment-examples.md`	生成本地审查报告前
`references/review-surfaces.md`	决定工作是留在本地自我审查还是移交至PR特定工作流时
`references/security-checklist.md`	当差异涉及认证、输入处理、外部API、文件上传或环境配置时
`references/performance-checklist.md`	当差异涉及数据获取、渲染、图片、依赖项或影响包体积的导入时

Scope

审查范围

Default target: staged or uncommitted local changes
Secondary target: current branch diff against base when the working tree is clean or the user asks for branch review
Explicit PR requests are secondary: keep the same review criteria, but treat them as a handoff path rather than the main workflow
Keep the skill focused on concrete bugs, missing validation/tests that clearly matter, and repository instruction-file compliance
Do not use this skill for inbound PR comments or thread resolution; use
```
pr-comments
```
for that

默认审查目标：已暂存或未提交的本地变更
次要审查目标：当工作树干净或用户要求分支审查时，当前分支与基准分支的差异
明确的PR请求为次要场景：保持相同审查标准，但将其视为移交路径而非主要工作流
聚焦于具体Bug、明显缺失的验证/测试以及仓库说明文件合规性
请勿将此技能用于处理入站PR评论或线程解决；此类场景请使用
```
pr-comments
```
技能

Workflow

工作流

Copy this checklist to track progress:

text

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

Discover the review target:
- If staged or unstaged changes exist, review those first
- Otherwise review the current branch diff against its base
- Only switch to a PR handoff summary when the user explicitly points at an existing PR
- Record the current branch and changed files so the report is grounded in the local session
Gather context:
- Capture the change intent from the session, recent commits, or the user's request
- Load relevant repository instruction files (
```
AGENTS.md
```
  /
```
CLAUDE.md
```
  as applicable, including any in nested package/MFE directories whose code is in the diff)
- Apply only in-scope instruction-file rules for the changed paths
- Run the project's lint, type check, and test commands (from
```
package.json
```
  scripts) to capture current status — note pre-existing failures so they are distinguishable from regressions caused by the change. Include the lint/type-check/test status in the report so the reader knows the baseline at review time
Choose the local review path:
- Local self-review is the default: current diff/branch with a local report in chat
- Existing PR requests are secondary: apply the same validation bar, then produce a concise handoff summary instead of changing the main workflow
- For large changes, shard by subsystem and keep the final report consolidated
Validate issues:
- Re-check exact lines before reporting
- Keep only high-confidence issues; drop speculative or duplicate items
- Confirm each issue still applies to the latest diff and maps to a changed line
- Collapse multiple comments that share the same root cause into one finding
Produce the report:
- Default output: a local review report in chat
- Organize findings into
```
Must fix before push
```
  ,
```
Should fix soon
```
  , and
```
Ready for handoff
```
- Do not post inline comments, resolve threads, or handle inbound review feedback from this skill
- Hand off inbound PR feedback to
```
pr-comments
```

复制以下检查清单跟踪进度：

text

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

确定审查目标:
- 若存在已暂存或未暂存的变更，优先审查这些内容
- 否则审查当前分支与其基准分支的差异
- 仅当用户明确指向现有PR时，才切换为PR移交总结
- 记录当前分支和变更文件，确保报告基于本地会话
收集上下文:
- 从会话、近期提交或用户请求中获取变更意图
- 加载相关仓库说明文件（适用的
```
AGENTS.md
```
  /
```
CLAUDE.md
```
  ，包括差异中涉及的嵌套包/MFE目录中的相关文件）
- 仅对变更路径应用范围内的说明文件规则
- 运行项目的lint、类型检查和测试命令（来自
```
package.json
```
  脚本）以捕获当前状态——记录预先存在的失败，以便区分变更导致的回归。在报告中包含lint/类型检查/测试状态，让读者了解审查时的基线
选择本地审查路径:
- 默认路径：本地自我审查，在聊天中生成本地报告
- 现有PR请求为次要路径：应用相同验证标准，然后生成简洁的移交总结，而非更改主要工作流
- 对于大型变更，按子系统拆分审查，最终合并报告
验证问题:
- 报告前重新检查具体代码行
- 仅保留高置信度问题；剔除推测性或重复项
- 确认每个问题仍适用于最新差异，且对应变更行
- 将具有相同根本原因的多个评论合并为一个问题
生成报告:
- 默认输出：聊天中的本地审查报告
- 将问题分为「推送前必须修复」「应尽快修复」和「可移交」三类
- 请勿发布内联评论、解决线程或处理入站审查反馈；此类操作不属于此技能范畴
- 将入站PR反馈移交至
```
pr-comments
```
  技能处理

High signal only

仅保留高信号问题

Flag only when certain:

Code will fail to compile (syntax, types, imports)
Code will produce incorrect behavior (clear logic or state errors)
Code introduces a concrete security risk with direct exploit path — load
```
references/security-checklist.md
```
for the three-tier classification when the diff touches auth, input handling, external APIs, or environment configuration
Code introduces a measurable performance regression — load
```
references/performance-checklist.md
```
for common bottleneck patterns when the diff touches data fetching, rendering, images, or dependencies
Changed behavior is clearly missing a necessary regression or validation test, including: a new component or hook shipped with no co-located test file, or an existing test where every assertion is a render-only presence check (
```
expect(getByText(...)).toBeInTheDocument()
```
) with no user interaction or branch coverage
Bug fix without a failing test that reproduces it first (Prove-It Pattern: if the fix is correct, a test for the bug should fail before and pass after)
Test code over-abstracts shared setup to the point where individual tests are unreadable without tracing helpers (prefer DAMP — Descriptive And Meaningful Phrases — over DRY in test code)
Lint, type check, or tests fail as a result of the change (distinguish from pre-existing failures captured in step 2)
Unambiguous instruction-file violation (quote rule, verify scope)
YAGNI violation: code adds abstractions, config systems, or extension points not justified by a current requirement (three similar lines is better than a premature abstraction)
KISS violation: implementation is more complex than the problem demands — a simpler approach exists that achieves the same result

Never flag:

Style, quality, or subjective preferences
Pre-existing issues unrelated to the change
Potential issues dependent on unknown inputs
Linter-only issues likely caught automatically
Explicitly silenced violations

仅在确定以下情况时标记问题：

代码无法编译（语法、类型、导入错误）
代码会产生错误行为（明确的逻辑或状态错误）
代码引入具有直接利用路径的具体安全风险——当差异涉及认证、输入处理、外部API或环境配置时，加载
```
references/security-checklist.md
```
进行三级分类
代码引入可测量的性能回归——当差异涉及数据获取、渲染、图片或依赖项时，加载
```
references/performance-checklist.md
```
查看常见瓶颈模式
变更行为明显缺失必要的回归或验证测试，包括：新组件或Hook未附带同目录测试文件，或现有测试中所有断言仅为渲染存在检查（
```
expect(getByText(...)).toBeInTheDocument()
```
），无用户交互或分支覆盖
修复Bug但未先编写可复现该Bug的失败测试（Prove-It Pattern：若修复正确，针对该Bug的测试应在修复前失败、修复后通过）
测试代码过度抽象共享设置，导致单个测试需追踪辅助代码才能理解（测试代码优先使用DAMP——描述性且有意义的表述——而非DRY原则）
变更导致lint、类型检查或测试失败（与步骤2中捕获的预先存在的失败区分开）
明确违反说明文件规则（引用规则，验证范围）
违反YAGNI原则：代码添加了当前需求未证明合理的抽象、配置系统或扩展点（三行相似代码优于过早抽象）
违反KISS原则：实现复杂度超出问题需求——存在可达成相同结果的更简单方案

绝不标记以下情况：

风格、质量或主观偏好问题
与变更无关的预先存在的问题
依赖未知输入的潜在问题
可能被自动捕获的仅lint类问题
被明确忽略的违规项

Output format

输出格式

Read

references/comment-examples.md

before producing the report if you need a formatting refresher.

Default local output:

markdown

undefined

若需要格式参考，请在生成报告前阅读

references/comment-examples.md

。

默认本地输出：

markdown

undefined

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>

[<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>

[<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>


If the user explicitly points at an existing PR, adapt the same validated findings into a concise handoff summary:
```markdown

<brief readiness summary>


若用户明确指向现有PR，将经验证的问题调整为简洁的移交总结：
```markdown

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>


**Summary** (if no issues):

[<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.

None.

Should fix soon

None.

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.

undefined

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

undefined

Anti-patterns

反模式

Starting by asking for a PR number when local changes are available -> review the local diff first
Teaching inline review comments as the default output -> keep the main path local-first
"This might cause issues" -> "Variable
```
x
```
is undefined at
```
src/foo.ts:45
```
, causing
```
ReferenceError
```
at runtime."
"Consider refactoring" -> "Violates instruction-file rule '<quoted rule>' in scoped file
```
src/foo.ts
```
."
Multiple comments for the same root cause -> one comment linking all affected locations

当存在本地变更时，先询问PR编号 -> 应优先审查本地差异
将内联审查评论作为默认输出 -> 保持本地优先的主要路径
使用模糊表述如「这可能会导致问题」 -> 应使用具体表述如「变量
```
x
```
在
```
src/foo.ts:45
```
处未定义，会在运行时引发
```
ReferenceError
```
」
使用模糊建议如「考虑重构」 -> 应明确表述如「违反了
```
src/foo.ts
```
范围内的说明文件规则'<引用规则>'」
针对同一根本原因创建多个评论 -> 应合并为一个评论并链接所有受影响位置

pr-reviewer

Original

Translation

Local Review

本地审查

Reference Files

参考文件

Scope

审查范围

Workflow

工作流

High signal only

仅保留高信号问题

Output format

输出格式

Local review

Local review

Must fix before push

Must fix before push

Should fix soon

Should fix soon

Ready for handoff

Ready for handoff

PR handoff summary

PR handoff summary

Local review

Local review

Must fix before push

Must fix before push

Should fix soon

Should fix soon

Ready for handoff

Ready for handoff

Anti-patterns

反模式

Related skills

相关技能