Review Frontend — 审查前端

前端代码审查参数 --parallel：根据技术领域生成专用子代理 路径：目标目录（默认：当前工作目录）

步骤 1：识别更改的文件 git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.(tsx?|css)$'

步骤 2：检测技术 # 检测 React Flow grep -r "@xyflow/react\|ReactFlow\|useNodesState" --include=".tsx" -l | head -3 # 检测 Zustand grep -r "from 'zustand'\|create\(\(" --include=".ts" --include=".tsx" -l | head -3 # 检测 Tailwind v4 grep -r "@theme\|@layer theme" --include=".css" -l | head -3 # 检查测试文件 git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.test\.tsx?$'

步骤 3：加载验证协议 在进行任何实质性判断之前，加载 beagle-react:review-verification-protocol。

步骤 4：加载技能 使用 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

步骤 5：审查 顺序（默认）：加载适用的技能 审查 React Router 模式 审查 shadcn/ui 模式 审查检测到的技术领域 整合发现结果 并行（--parallel 标志）：预先检测所有技术 为每个技术领域生成一个子代理，使用 Task 工具 每个代理加载其技能并审查其领域 等待所有代理 整合发现结果

步骤 6：验证发现结果 在报告任何问题之前： 重新阅读实际代码（不仅仅是 diff 上下文） 对于“未使用”的声明 - 您是否搜索了所有引用？ 对于“缺失”的声明 - 您是否检查了框架/父级处理？ 对于语法问题 - 您是否验证了当前版本的文档？ 删除任何仅仅是风格偏好的发现结果，而不是实际问题 在升级到 Critical/Major 之前，请通过以下步骤： 对于该项，（2）-（4）都需要有一个具体的工件 - 例如，打开文件在 FILE:LINE，grep/search 输出的引用，或者引用父级/框架代码 - 不仅仅是 diff 上下文。

步骤 7：审查收敛 单次审查的完整性 您必须在单次审查中报告所有问题，涵盖所有类别（风格、逻辑、类型、测试、安全、性能）。 在提交发现结果之前，问问自己： “如果我推荐的所有修复都被应用，我会在修复后的代码中找到新的问题吗？” “是否需要新的代码（测试、类型、模块），这些代码本身需要审查？” 如果以上任意一个问题的答案是“是”，请在本次审查中包含这些预期的下游问题，这样作者可以一次性解决所有问题。

审查范围规则 仅审查 diff 中的代码和直接相关的现有代码 不要请求新功能、测试基础设施或架构更改，这些更改在 diff 之前不存在 如果测试覆盖率缺失，请将其标记为一个 Minor 问题（“缺失 X、Y、Z 的测试覆盖率”）- 不要指定实现细节，如 mock 库、行为提取或依赖注入模式，这些模式会引入大量新代码 类型规范、文档和命名问题是 Minor 问题，除非它们影响公共 API 合同 不要请求添加新依赖项（例如 Mox、测试库、linter 插件）

修复复杂度预算 现有代码的修复应根据其实际严重性进行标记，而不考虑其大小。 但是，对于 diff 之前不存在的新代码，必须将其标记为 Informational： 添加新依赖项（例如 Mox、linter 插件） 创建全新的模块、文件或测试套件 提取新的行为、协议或抽象 这些是改进建议，供作者在未来的工作中考虑，而不是审查阻塞器。

迭代政策 如果这是一个重新审查，修复已经应用： 仅验证以前标记的问题是否被正确解决 不要引入与以前审查问题无关的新发现结果 接受 Minor/Nice-to-Have 问题，这些问题没有被修复 - 不要重新标记它们 重新审查的目标是验证，而不是发现

输出格式

审查摘要

问题

Critical（阻塞）

• [FILE:LINE] 问题标题 - 问题：问题描述 - 为什么：为什么这个问题很重要（bug、a11y、perf、security）- 修复：具体推荐修复

Major（应该修复）

• [FILE:LINE] 问题标题 - 问题：... - 为什么：... - 修复：...

Minor（Nice to Have）

Informational（用于意识）

良好模式

• [FILE:LINE]