parallel-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Parallel Code Review Skill

并行代码审查Skill

Operator Context

运行上下文

This skill operates as an orchestrator for parallel code review, configuring Claude's behavior to launch three specialized review agents simultaneously and aggregate their findings into a unified report. It implements the Fan-Out/Fan-In architectural pattern -- dispatch independent reviewers in parallel, collect results, merge by severity -- with Domain Intelligence embedded in each reviewer's focus area.

本技能作为并行代码审查的编排器，配置Claude的行为以同时启动三个专业审查Agent，并将他们的审查结果汇总为一份统一报告。它实现了Fan-Out/Fan-In架构模式——并行调度独立审查员、收集结果、按严重程度合并——每个审查员的关注领域都嵌入了Domain Intelligence（领域智能）。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before dispatching reviewers
True Parallelism: All 3 Task calls MUST be dispatched in a SINGLE message
No Skipping Reviewers: All 3 reviewers run even for "simple" changes
READ-ONLY: Reviewers never modify code; this is observation only
Severity Aggregation: Combine findings by severity before reporting
Always Produce Verdict: Every review ends with BLOCK, FIX, or APPROVE

遵循CLAUDE.md规范：在调度审查员前读取并遵循仓库的CLAUDE.md
真正的并行性：所有3个任务调用必须在单条消息中调度
不得跳过任何审查员：即使是“简单”变更，也必须运行全部3位审查员
READ-ONLY：审查员绝不会修改代码；仅进行观察
严重程度汇总：报告前按严重程度合并审查结果
始终生成裁决：每次审查都必须以BLOCK、FIX或APPROVE结尾

Default Behaviors (ON unless disabled)

默认行为（除非禁用否则开启）

Re-run on Critical: If CRITICAL issues found, re-run all reviewers after fixes
Severity Summary Table: Include reviewer-by-severity matrix in output
File-Line References: All findings must include
```
file:line
```
references
Domain-Specific Agent Selection: Use language-appropriate agent for architecture reviewer

发现严重问题时重新运行：若发现CRITICAL问题，修复后重新运行所有审查员
严重程度汇总表：输出中包含按审查员分类的严重程度矩阵
文件-行号引用：所有审查结果必须包含
```
file:line
```
引用
特定领域Agent选择：为架构审查员选择适合编程语言的Agent

Optional Behaviors (OFF unless enabled)

可选行为（除非启用否则关闭）

Threat Model: Enable with "include threat model" for security reviewer
Git Bisect: Enable with "find breaking commit" for regression tracking
Performance Profiling: Enable with "benchmark" for architecture reviewer

威胁建模：用户要求“include threat model”时为安全审查员启用
Git Bisect：用户要求“find breaking commit”时启用以追踪回归问题
性能分析：用户要求“benchmark”时为架构审查员启用

What This Skill CAN Do

本技能可实现的功能

Dispatch 3 specialized reviewers in true parallel (single message)
Aggregate findings across reviewers into unified severity classification
Select domain-appropriate agents for architecture review (Go, Python, TS)
Produce a structured report with BLOCK/FIX/APPROVE verdict
Re-run all reviewers after critical fixes to verify resolution

在单条消息中真正并行调度3位专业审查员
跨审查员汇总结果并统一分类严重程度
为架构审查选择适合领域的Agent（Go、Python、TS）
生成包含BLOCK/FIX/APPROVE裁决的结构化报告
严重问题修复后重新运行所有审查员以验证解决情况

What This Skill CANNOT Do

本技能无法实现的功能

Modify code or apply fixes (read-only review only)
Run fewer than 3 reviewers to save time
Skip aggregation and report individual reviewer results separately
Replace systematic-code-review for simple sequential reviews
Approve without all 3 reviewers completing

修改代码或应用修复（仅支持只读审查）
为节省时间只运行少于3位审查员
跳过汇总步骤，单独报告每位审查员的结果
替代systematic-code-review用于简单的顺序审查
未等所有3位审查员完成就批准

Instructions

操作说明

Phase 1: IDENTIFY SCOPE

阶段1：确定范围

Goal: Determine changed files and select appropriate agents before dispatching.

Step 1: List changed files

bash

undefined

目标：调度前确定变更文件并选择合适的Agent。

步骤1：列出变更文件

bash

undefined

For recent commits:

For PRs:

PR场景：

gh pr view --json files -q '.files[].path'


**Step 2: Select architecture reviewer agent**

| File Types | Agent |
|-----------|-------|
| `.go` files | `golang-general-engineer` |
| `.py` files | `python-general-engineer` |
| `.ts`/`.tsx` files | `typescript-frontend-engineer` |
| Mixed or other | `Explore` |

**Gate**: Changed files listed, architecture reviewer agent selected. Proceed only when gate passes.

gh pr view --json files -q '.files[].path'


**步骤2：选择架构审查Agent**

| 文件类型 | Agent |
|-----------|-------|
| `.go`文件 | `golang-general-engineer` |
| `.py`文件 | `python-general-engineer` |
| `.ts`/`.tsx`文件 | `typescript-frontend-engineer` |
| 混合或其他类型 | `Explore` |

**检查点**：已列出变更文件，已选择架构审查Agent。仅当检查点通过后才可继续。

Phase 2: DISPATCH PARALLEL REVIEWERS

阶段2：调度并行审查员

Goal: Launch all 3 reviewers in a single message for true concurrent execution.

CRITICAL: All three Task calls MUST appear in ONE response. Sequential messages defeat parallelism.

Dispatch exactly these 3 agents:

Reviewer 1 -- Security

Focus: OWASP Top 10, authentication, authorization, input validation, secrets exposure
Output: Severity-classified findings with
```
file:line
```
references

Reviewer 2 -- Business Logic

Focus: Requirements coverage, edge cases, state transitions, data validation, failure modes
Output: Severity-classified findings with
```
file:line
```
references

Reviewer 3 -- Architecture (using agent selected in Phase 1)

Focus: Design patterns, naming, structure, performance, maintainability
Output: Severity-classified findings with
```
file:line
```
references

Gate: All 3 Task calls dispatched in a single message. Proceed only when all 3 return results.

目标：在单条消息中启动所有3位审查员以实现真正的并发执行。

关键要求：所有三个任务调用必须出现在同一条响应中。顺序发送消息会完全失去并行性的意义。

调度以下3位Agent：

审查员1 -- 安全

关注方向：OWASP Top 10、身份验证、授权、输入验证、密钥泄露
输出：带
```
file:line
```
引用的按严重程度分类的审查结果

审查员2 -- 业务逻辑

关注方向：需求覆盖、边缘情况、状态转换、数据验证、故障模式
输出：带
```
file:line
```
引用的按严重程度分类的审查结果

审查员3 -- 架构（使用阶段1选择的Agent）

关注方向：设计模式、命名规范、结构、性能、可维护性
输出：带
```
file:line
```
引用的按严重程度分类的审查结果

检查点：所有3个任务调用已在单条消息中调度。仅当所有3位审查员返回结果后才可继续。

Phase 3: AGGREGATE

阶段3：汇总结果

Goal: Merge all findings into a unified severity-classified report.

Step 1: Classify each finding by severity

Severity	Meaning	Action
CRITICAL	Security vulnerability, data loss risk	BLOCK merge
HIGH	Significant bug, logic error	Fix before merge
MEDIUM	Code quality issue, potential problem	Should fix
LOW	Minor issue, style preference	Nice to have

Step 2: Deduplicate overlapping findings

Multiple reviewers may flag the same issue. Merge duplicates, keep the highest severity.

Step 3: Build reviewer summary matrix

| Reviewer       | CRITICAL | HIGH | MEDIUM | LOW |
|----------------|----------|------|--------|-----|
| Security       | N        | N    | N      | N   |
| Business Logic | N        | N    | N      | N   |
| Architecture   | N        | N    | N      | N   |
| **Total**      | **N**    | **N**| **N**  | **N**|

Gate: All findings classified, deduplicated, and summarized. Proceed only when gate passes.

目标：将所有审查结果合并为一份统一的按严重程度分类的报告。

步骤1：按严重程度分类每个问题

严重程度	含义	操作
CRITICAL	安全漏洞、数据丢失风险	BLOCK合并
HIGH	严重bug、逻辑错误	合并前修复
MEDIUM	代码质量问题、潜在风险	建议修复
LOW	minor问题、风格偏好	可选修复

步骤2：去重重叠问题

多位审查员可能标记同一问题。合并重复项，保留最高严重程度。

步骤3：构建审查员汇总矩阵

| 审查员       | CRITICAL | HIGH | MEDIUM | LOW |
|----------------|----------|------|--------|-----|
| 安全       | N        | N    | N      | N   |
| 业务逻辑 | N        | N    | N      | N   |
| 架构   | N        | N    | N      | N   |
| **总计**      | **N**    | **N**| **N**  | **N**|

检查点：所有问题已分类、去重并汇总。仅当检查点通过后才可继续。

Phase 4: VERDICT

阶段4：生成裁决

Goal: Produce final report with clear recommendation.

Step 1: Determine verdict

Condition	Verdict
Any CRITICAL findings	BLOCK
HIGH findings, no CRITICAL	FIX (fix before merge)
Only MEDIUM/LOW findings	APPROVE (with suggestions)

Step 2: Output structured report

markdown

undefined

目标：生成包含明确建议的最终报告。

步骤1：确定裁决结果

条件	裁决
存在任何CRITICAL问题	BLOCK
存在HIGH问题，无CRITICAL	FIX（合并前修复）
仅存在MEDIUM/LOW问题	APPROVE（附带建议）

步骤2：输出结构化报告

markdown

undefined

Parallel Review Complete

并行审查完成

Combined Findings

合并后的审查结果

CRITICAL (Block Merge)

CRITICAL（阻止合并）

[Reviewer] Issue description - file:line

[审查员] 问题描述 - file:line

HIGH (Fix Before Merge)

HIGH（合并前修复）

[Reviewer] Issue description - file:line

[审查员] 问题描述 - file:line

MEDIUM (Should Fix)

MEDIUM（建议修复）

[Reviewer] Issue description - file:line

[审查员] 问题描述 - file:line

LOW (Nice to Have)

LOW（可选修复）

[Reviewer] Issue description - file:line

[审查员] 问题描述 - file:line

Summary by Reviewer

审查员汇总

[Matrix from Phase 3]

[阶段3的矩阵]

Recommendation

建议

VERDICT - [1-2 sentence rationale]


**Step 3: If BLOCK verdict, initiate re-review protocol**

After user addresses CRITICAL issues, re-run ALL 3 reviewers to verify:
1. Original CRITICAL issues resolved
2. No regressions introduced
3. No new CRITICAL/HIGH issues from fixes

**Gate**: Structured report delivered with verdict. Review is complete.

---

裁决 - [1-2句理由]


**步骤3：若裁决为BLOCK，启动重新审查流程**

用户解决CRITICAL问题后，重新运行所有3位审查员以验证：
1. 原CRITICAL问题已解决
2. 未引入回归问题
3. 修复未带来新的CRITICAL/HIGH问题

**检查点**：已交付带裁决的结构化报告。审查完成。

---

Error Handling

错误处理

Error: "Reviewer Times Out"

错误：“审查员超时”

Cause: One or more Task agents exceed execution time Solution:

Report findings from completed reviewers immediately
Note which reviewer(s) timed out and on which files
Offer to re-run failed reviewer separately or proceed with partial results

原因：一个或多个任务Agent超出执行时间解决方案：

立即报告已完成审查员的结果
记录超时的审查员及涉及文件
提供单独重新运行失败审查员或使用部分结果继续的选项

Error: "All Reviewers Fail"

错误：“所有审查员失败”

Cause: Systemic issue (bad file paths, permission errors, context overflow) Solution:

Verify changed file list is correct and files are readable
Reduce scope if file count is very large (split into batches)
Fall back to systematic-code-review (sequential) as last resort

原因：系统性问题（文件路径错误、权限问题、上下文溢出）解决方案：

验证变更文件列表是否正确且文件可读
若文件数量过大，缩小范围（分批处理）
最后回退到systematic-code-review（顺序审查）

Error: "Conflicting Findings Across Reviewers"

错误：“审查员结果冲突”

Cause: Two reviewers disagree on severity or interpretation of same code Solution:

Keep the higher severity classification (classify UP)
Include both perspectives in the finding description
Flag as "needs author input" if genuinely ambiguous

原因：两位审查员对同一代码的严重程度或解读存在分歧解决方案：

保留更高的严重程度分类（向上归类）
在问题描述中包含两种观点
若确实存在歧义，标记为“需要作者输入”

Anti-Patterns

反模式

Anti-Pattern 1: Sequential Dispatch

反模式1：顺序调度

What it looks like: Sending one Task call, waiting for it, then sending the next. Why wrong: Defeats the entire purpose of parallel review. Triples wall-clock time. Do instead: All 3 Task calls in a SINGLE message. This is not optional.

表现：发送一个任务调用，等待完成后再发送下一个。问题：完全违背并行审查的目的，将耗时增加三倍。 正确做法：所有3个任务调用放在单条消息中。这是强制要求。

Anti-Pattern 2: Skipping a Reviewer for "Simple" Changes

反模式2：为“简单”变更跳过审查员

What it looks like: "This is just a config change, no need for security review." Why wrong: Config changes can expose secrets, break authorization, or introduce logic errors. Simple changes cause complex bugs. Do instead: Run all 3 reviewers. Let them report "no findings" if truly clean.

表现：“这只是配置变更，不需要安全审查。” 问题：配置变更可能泄露密钥、破坏授权逻辑或引入逻辑错误。简单变更可能导致复杂bug。 正确做法：运行所有3位审查员。若确实无问题，他们会报告“无审查结果”。

Anti-Pattern 3: Reporting Without Aggregation

反模式3：不汇总直接报告

What it looks like: Dumping each reviewer's raw output as three separate sections. Why wrong: Reader must mentally merge findings. Duplicate issues appear multiple times. No unified severity picture. Do instead: Complete Phase 3 aggregation. Deduplicate, classify, build matrix.

表现：将每位审查员的原始输出作为三个独立部分直接输出。问题：读者需要手动合并结果，重复问题会多次出现，无法看到统一的严重程度全貌。 正确做法：完成阶段3的汇总步骤。去重、分类、构建矩阵。

Anti-Pattern 4: Approving With Partial Results

反模式4：基于部分结果批准

What it looks like: "2 of 3 reviewers passed, looks good to merge." Why wrong: The failed reviewer may have found the only CRITICAL issue. Partial coverage gives false confidence. Do instead: Wait for all 3 to complete, or explicitly re-run the failed reviewer before issuing verdict.

表现：“3位审查员中有2位通过，看起来可以合并了。” 问题：失败的审查员可能发现了唯一的CRITICAL问题。部分覆盖会带来虚假的信心。 正确做法：等待所有3位审查员完成，或明确重新运行失败的审查员后再发布裁决。

References

参考资料

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Anti-Rationalization (Review) - Review-specific rationalizations
Severity Classification - Issue severity definitions
Verification Checklist - Pre-completion checks

本技能使用以下共享模式：

Anti-Rationalization - 防止捷径合理化
Anti-Rationalization (Review) - 审查特定的合理化
Severity Classification - 问题严重程度定义
Verification Checklist - 完成前检查清单

Domain-Specific Anti-Rationalization

特定领域反合理化

Rationalization	Why It's Wrong	Required Action
"One reviewer is enough"	Different perspectives catch different issues	Run all three
"Security reviewer covered logic"	Specialization matters; overlap is feature not bug	Don't skip business logic
"Small PR, skip parallel"	Small PRs can harbor big bugs	Consider scope, not size
"Reviewers will just duplicate"	Each has specific focus areas	Trust the specialization

合理化理由	问题所在	要求操作
“一位审查员就够了”	不同视角发现不同问题	运行全部三位
“安全审查员已经覆盖了逻辑”	专业化很重要；重叠是特性而非bug	不得跳过业务逻辑审查
“PR很小，跳过并行审查”	小PR可能隐藏大bug	考虑范围而非大小
“审查员只会重复工作”	每位审查员都有特定关注领域	信任专业化分工