review-frontend

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Frontend Code Review

前端代码评审

Arguments

参数

```
--parallel
```
: Spawn specialized subagents per technology area
Path: Target directory (default: current working directory)

```
--parallel
```
: 生成针对各技术领域的专业子Agent
Path: 目标目录（默认：当前工作目录）

Step 1: Identify Changed Files

步骤1：识别变更文件

bash

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.(tsx?|css)$'

bash

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.(tsx?|css)$'

Step 2: Detect Technologies

步骤2：检测技术栈

bash

undefined

bash

undefined

Detect React Flow

检测React Flow

grep -r "@xyflow/react|ReactFlow|useNodesState" --include="*.tsx" -l | head -3

Detect Zustand

检测Zustand

grep -r "from 'zustand'|create((" --include=".ts" --include=".tsx" -l | head -3

Detect Tailwind v4

检测Tailwind v4

grep -r "@theme|@layer theme" --include="*.css" -l | head -3

Check for test files

检查测试文件

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '.test.tsx?$'

undefined

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '.test.tsx?$'

undefined

Step 3: Load Verification Protocol

步骤3：加载验证协议

Load

beagle-react:review-verification-protocol

skill and keep its checklist in mind throughout the review.

加载

beagle-react:review-verification-protocol

Skill，并在整个评审过程中牢记其检查清单。

Step 4: Load Skills

步骤4：加载技能

Use the

Skill

tool to load each applicable skill (e.g.,

Skill(skill: "beagle-react:react-router-code-review")

Always load:

```
beagle-react:react-router-code-review
```
```
beagle-react:shadcn-code-review
```

Conditionally load based on detection:

Condition	Skill
@xyflow/react detected	`beagle-react:react-flow-code-review`
Zustand detected	`beagle-react:zustand-state`
Tailwind v4 detected	`beagle-react:tailwind-v4`
Test files changed	`beagle-react:vitest-testing`

使用

Skill

工具加载每个适用的技能（例如：

Skill(skill: "beagle-react:react-router-code-review")

）。

必须加载：

```
beagle-react:react-router-code-review
```
```
beagle-react:shadcn-code-review
```

根据检测结果选择性加载：

条件	技能
检测到@xyflow/react	`beagle-react:react-flow-code-review`
检测到Zustand	`beagle-react:zustand-state`
检测到Tailwind v4	`beagle-react:tailwind-v4`
测试文件发生变更	`beagle-react:vitest-testing`

Step 5: Review

步骤5：执行评审

Sequential (default):

Load applicable skills
Review React Router patterns first
Review shadcn/ui patterns
Review detected technology areas
Consolidate findings

Parallel (--parallel flag):

Detect all technologies upfront
Spawn one subagent per technology area with
```
Task
```
tool
Each agent loads its skill and reviews its domain
Wait for all agents
Consolidate findings

顺序模式（默认）：

加载所有适用技能
优先评审React Router模式
评审shadcn/ui模式
评审检测到的技术领域
整合评审结果

并行模式（--parallel 参数）：

预先检测所有技术栈
使用
```
Task
```
工具为每个技术领域生成一个子Agent
每个Agent加载对应技能并评审其负责领域
等待所有Agent完成评审
整合评审结果

Step 6: Verify Findings

步骤6：验证评审发现

Before reporting any issue:

Re-read the actual code (not just diff context)
For "unused" claims - did you search all references?
For "missing" claims - did you check framework/parent handling?
For syntax issues - did you verify against current version docs?
Remove any findings that are style preferences, not actual issues

在报告任何问题前：

重新阅读实际代码（而非仅差异上下文）
对于“未使用”的判断 - 是否搜索了所有引用？
对于“缺失”的判断 - 是否检查了框架/父组件的处理逻辑？
对于语法问题 - 是否对照当前版本的文档进行了验证？
删除所有属于风格偏好而非实际问题的评审发现

Step 7: Review Convergence

步骤7：评审收敛规则

Single-Pass Completeness

单次评审完整性

You MUST report ALL issues across ALL categories (style, logic, types, tests, security, performance) in a single review pass. Do not hold back issues for later rounds.

Before submitting findings, ask yourself:

"If all my recommended fixes are applied, will I find NEW issues in the fixed code?"
"Am I requesting new code (tests, types, modules) that will itself need review?"

If yes to either: include those anticipated downstream issues NOW, in this review, so the author can address everything at once.

你必须在单次评审中报告所有类别（风格、逻辑、类型、测试、安全、性能）的所有问题，不得将问题留到后续轮次。

提交评审结果前，请自问：

“如果所有建议的修复都已应用，我在修复后的代码中还会发现新问题吗？”
“我是否要求新增需要评审的代码（测试、类型、模块）？”

如果任一问题答案为是：请在本次评审中一并包含这些预期的下游问题，以便作者一次性处理所有内容。

Scope Rules

范围规则

Review ONLY the code in the diff and directly related existing code
Do NOT request new features, test infrastructure, or architectural changes that didn't exist before the diff
If test coverage is missing, flag it as ONE Minor issue ("Missing test coverage for X, Y, Z") — do NOT specify implementation details like mock libraries, behaviour extraction, or dependency injection patterns that would introduce substantial new code
Typespecs, documentation, and naming issues are Minor unless they affect public API contracts
Do NOT request adding new dependencies (e.g. Mox, testing libraries, linter plugins)

仅评审差异中的代码及直接相关的现有代码
不得要求新增功能、测试基础设施或变更之前不存在的架构
如果测试覆盖率缺失，将其标记为一个次要问题（“X、Y、Z缺失测试覆盖”）——不得指定实现细节，如模拟库、行为提取或依赖注入模式等会引入大量新代码的内容
类型规范、文档和命名问题除非影响公共API契约，否则均为次要问题
不得要求新增依赖（如Mox、测试库、检查器插件）

Fix Complexity Budget

修复复杂度预算

Fixes to existing code should be flagged at their real severity regardless of size.

However, requests for net-new code that didn't exist before the diff must be classified as Informational:

Adding a new dependency (e.g. Mox, a linter plugin)
Creating entirely new modules, files, or test suites
Extracting new behaviours, protocols, or abstractions

These are improvement suggestions for the author to consider in future work, not review blockers.

现有代码的修复应根据实际严重程度标记。

然而，对于差异中不存在的全新代码的请求必须归类为信息性建议：

新增依赖（如Mox、检查器插件）
创建全新模块、文件或测试套件
提取新的行为、协议或抽象

这些是供作者在未来工作中考虑的改进建议，而非评审阻塞项。

Iteration Policy

迭代规则

If this is a re-review after fixes were applied:

ONLY verify that previously flagged issues were addressed correctly
Do NOT introduce new findings unrelated to the previous review's issues
Accept Minor/Nice-to-Have issues that weren't fixed — do not re-flag them
The goal of re-review is VERIFICATION, not discovery

如果这是修复后的重新评审：

仅验证之前标记的问题是否已正确解决
不得引入与之前评审问题无关的新发现
接受未修复的次要/锦上添花问题——不得重新标记
重新评审的目标是验证，而非发现新问题

Output Format

输出格式

markdown

undefined

markdown

undefined

Review Summary

评审总结

[1-2 sentence overview of findings]

[1-2句话概述评审发现]

Issues

问题列表

Critical (Blocking)

严重（阻塞）

[FILE:LINE] ISSUE_TITLE
- Issue: Description of what's wrong
- Why: Why this matters (bug, a11y, perf, security)
- Fix: Specific recommended fix

[文件:行号] 问题标题
- 问题：错误内容描述
- 影响：说明问题的严重性（Bug、无障碍、性能、安全）
- 修复建议：具体的修复方案

Major (Should Fix)

主要（应修复）

[FILE:LINE] ISSUE_TITLE
- Issue: ...
- Why: ...
- Fix: ...

[文件:行号] 问题标题
- 问题：...
- 影响：...
- 修复建议：...

Minor (Nice to Have)

次要（锦上添花）

N. [FILE:LINE] ISSUE_TITLE

Issue: ...
Why: ...
Fix: ...

N. [文件:行号] 问题标题

问题：...
影响：...
修复建议：...

Informational (For Awareness)

信息性（仅供参考）

N. [FILE:LINE] SUGGESTION_TITLE

Suggestion: ...
Rationale: ...

N. [文件:行号] 建议标题

建议：...
理由：...

Good Patterns

优秀实践

[FILE:LINE] Pattern description (preserve this)

[文件:行号] 实践描述（保留此项）

Verdict

评审结论

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable) Rationale: [1-2 sentences]

undefined

可通过：是 | 否 | 需修复1-N项（仅严重/主要问题；次要问题可接受）理由：[1-2句话]

undefined

Post-Fix Verification

修复后验证

After fixes are applied, run:

bash

npm run lint
npm run typecheck
npm run test

All checks must pass before approval.

修复完成后，运行：

bash

npm run lint
npm run typecheck
npm run test

所有检查必须通过才能批准。

Rules

规则

Load skills BEFORE reviewing (not after)
Number every issue sequentially (1, 2, 3...)
Include FILE:LINE for each issue
Separate Issue/Why/Fix clearly
Categorize by actual severity
Don't assume Next.js patterns (no "use client")
Run verification after fixes
Report ALL issues in a single pass — do not hold back findings for later iterations
Re-reviews verify previous fixes ONLY — no new discovery
Requests for net-new code (new modules, dependencies, test suites) are Informational, not blocking
The Verdict ignores Minor and Informational items — only Critical and Major block approval

评审前先加载技能（而非之后）
所有问题按顺序编号（1、2、3...）
每个问题需包含文件:行号
清晰区分问题/影响/修复建议
根据实际严重程度分类
不要假设使用Next.js模式（如“use client”）
修复后执行验证
单次评审报告所有问题——不得将发现留到后续迭代
重新评审仅验证之前的修复——不进行新发现
新增代码（新模块、依赖、测试套件）的请求属于信息性建议，而非阻塞项
评审结论忽略次要和信息性项——仅严重和主要问题会阻塞批准