Frontend Code Review（前端代码审查）

何时使用本 Skill

当用户要求审查、分析或改进前端代码（例如 .tsx、.ts、.js 文件）时使用本 skill。常见场景包括：

• 待提交变更审查：在提交前检查当前变更中涉及的前端文件。
• 代码片段审查：用户粘贴某个组件/页面/Hook 片段，请求审查。
• 按文件/模块审查：用户点名一到数个前端文件或某个路由/组件目录。

以下情况不要使用本 skill：

• 审查目标是后端代码（如 .py、服务层、数据库访问等）——此时应使用后端 Code Review Skill。
• 仅讨论架构文档或后端接口设计，而非前端实现。

如何使用本 Skill

1. 明确审查范围与模式：根据用户输入，限定在指定的组件、页面或目录内，不要「全仓库漫扫」。
2. 按 Checklist 中的规则执行审查；对每条命中的规则，找到具体代码位置并给出可执行建议。
3. 若某段代码未被 Checklist 覆盖，可参考 General Review Rules 做尽力审查。
4. 输出时必须严格遵循「Required Output」中的模板之一。

注意：

• 优先给出具体、可落地的改进建议（包括何处拆分组件、如何组织状态、如何统一样式等）。
• 若能提供简短代码示例，可帮助后续自动修复。

项目前端结构（审查范围参考）

以典型的 Next.js App Router + React + TypeScript + Tailwind 项目为例，常见分层与职责如下（实际路径以当前仓库为准，可根据项目实际结构类比到对应目录）：

• 路由与页面入口目录（例如 app/ 或 frontend/app/）：
  • 路由与页面入口（如 app/xxx/page.tsx、app/[id]/page.tsx 等）。
  • 顶层布局（如 layout.tsx），通常挂载全局布局组件（主框架、侧边栏、头部），不要在此堆积业务逻辑。
• 通用与领域组件目录（例如 components/ 或 frontend/components/）：
  • 复用的布局组件（如页面头部、布局容器）、表格/卡片/表单等 UI 组件。
  • 领域组件（如知识库列表、文档分段列表、业务向导步骤组件等），负责组合 UI 与轻量交互。
• lib/ 或 services/：
  • HTTP 客户端与前端 API 封装（如 axios 实例、领域 API 模块）。
  • 通用工具函数与 Hook（如复用的数据加载 Hook、格式化工具等）。 -- 样式配置：
  • 全局样式（如 app/globals.css）用于基础样式、滚动条、字体等。
  • Tailwind 配置（如 tailwind.config.js）可扩展主题颜色、间距、阴影等设计令牌，避免散落魔法值。

在进行前端 Code Review 时，优先检查：

• 页面是否复用了现有布局组件与上下文（例如统一的页面头部组件、侧边栏折叠状态的上下文），而不是各自实现一套布局。
• 新增页面是否放在合理的路由目录（与现有路由结构保持一致），新增组件是否放在组件目录下的合适子目录，而不是全部堆在页面文件中。
• 数据请求是否统一走封装好的 API 层或服务模块，而不是在组件内重复配置 axios/fetch。

Checklist

根据审查范围，优先按以下规则文件进行检查：

• 代码质量与组件设计：若涉及组件/Hook/页面结构、TypeScript 类型、可维护性，参考 references/code-quality-rule.md。
• 布局、样式与 UI 一致性：若涉及布局框架、全局样式、颜色与风格统一、响应式表现，参考 references/layout-style-rule.md。
• 状态管理与数据流：若涉及本地/全局状态、表单状态、异步数据加载、API 错误处理，参考 references/state-data-rule.md。
• 性能与交互体验：若涉及渲染性能、大列表、客户端/服务端边界、懒加载、交互反馈，参考 references/performance-rule.md。

若 Checklist 中的规则均不适用，可退回到下文的 General Review Rules 做尽力审查。

General Review Rules

从以下四个维度给出审查意见：

1. 结构与可维护性

   • 组件/页面是否职责单一，可读性良好，便于拆分与复用。
   • 是否存在重复代码（卡片、按钮、列表等模式），可以抽成复用组件。
   • 类型是否清晰（尽量避免 any），关键数据结构是否有统一的接口/类型定义。

2. 布局、样式与一致性

   • 是否复用统一的布局组件（主布局、页面头部、侧边栏等）。
   • Tailwind 类名是否过度堆叠、包含大量魔法色值（如随意使用类似但不一致的灰色/紫色）。
   • 是否存在同一业务模块内风格不统一的问题（按钮样式、圆角、间距等）。

3. 状态与数据

   • 异步请求是否有完整的 loading / error / empty 状态反馈。
   • 状态是否放在合适的层级（避免过度提升或不必要的全局状态）。
   • 是否存在可以用派生值计算的状态被重复存储的问题。

4. 性能与用户体验

   • 是否有不必要的重新渲染（例如在 .map 中频繁创建匿名函数或对象、缺少 key 或 key 不稳定）。
   • 大列表/复杂视图是否考虑了懒加载、分页或虚拟列表。
   • 交互是否有明确反馈（按钮禁用/加载中的样式、错误提示等）。

Required Output

当调用本 skill 时，输出必须严格遵循下列两种模板之一。

Template A（存在问题或改进建议时）

# Code review
Found <N> urgent issues need to be fixed:

## 1 <brief description of bug>
FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix
<brief description of suggested fix>

---
... (repeat for each urgent issue) ...

Found <M> suggestions for improvement:

## 1 <brief description of suggestion>
FilePath: <path> line <line>
<relevant code snippet or pointer>


### Suggested fix
<brief description of suggested fix>

---

... (repeat for each suggestion) ...

要求：

• 若没有「紧急问题」，可以省略 urgent issues 段落。
• 若没有「建议」，可以省略 suggestions for improvement 段落。
• 若问题数量超过 10 条，可汇总为 "10+ urgent issues" / "10+ suggestions"，并仅输出前 10 条。
• 保持模板中的空行与分隔线格式，以便后续自动解析。
• 若使用 Template A，且至少有一条需要改代码的项，最后追加一句简短追问，例如：
  • Would you like me to use the Suggested fix section to address these issues?

Template B（未发现问题时）

## Code review
No issues found.