| name | frontend-code-review |
| description | 指导在项目中对前端代码（Next.js/React/TypeScript/Tailwind 等）进行结构、可维护性、性能与一致性审查，基于既定规则清单。适用于用户请求审查 .tsx/.ts/.js/.jsx 等前端文件或前端目录下的页面与组件。不用于后端代码（如 .py）。 |
Frontend Code Review（前端代码审查）
何时使用本 Skill
当用户要求审查、分析或改进前端代码（例如 .tsx、.ts、.js 文件）时使用本 skill。常见场景包括：
- 待提交变更审查：在提交前检查当前变更中涉及的前端文件。
- 代码片段审查：用户粘贴某个组件/页面/Hook 片段，请求审查。
- 按文件/模块审查：用户点名一到数个前端文件或某个路由/组件目录。
以下情况不要使用本 skill：
- 审查目标是后端代码（如
.py、服务层、数据库访问等）——此时应使用后端 Code Review Skill。
- 仅讨论架构文档或后端接口设计，而非前端实现。
如何使用本 Skill
- 明确审查范围与模式：根据用户输入，限定在指定的组件、页面或目录内，不要「全仓库漫扫」。
- 按 Checklist 中的规则执行审查；对每条命中的规则，找到具体代码位置并给出可执行建议。
- 若某段代码未被 Checklist 覆盖，可参考 General Review Rules 做尽力审查。
- 输出时必须严格遵循「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
根据审查范围，优先按以下规则文件进行检查：
若 Checklist 中的规则均不适用，可退回到下文的 General Review Rules 做尽力审查。
General Review Rules
从以下四个维度给出审查意见：
-
结构与可维护性
- 组件/页面是否职责单一，可读性良好，便于拆分与复用。
- 是否存在重复代码（卡片、按钮、列表等模式），可以抽成复用组件。
- 类型是否清晰（尽量避免
any），关键数据结构是否有统一的接口/类型定义。
-
布局、样式与一致性
- 是否复用统一的布局组件（主布局、页面头部、侧边栏等）。
- Tailwind 类名是否过度堆叠、包含大量魔法色值（如随意使用类似但不一致的灰色/紫色）。
- 是否存在同一业务模块内风格不统一的问题（按钮样式、圆角、间距等）。
-
状态与数据
- 异步请求是否有完整的 loading / error / empty 状态反馈。
- 状态是否放在合适的层级（避免过度提升或不必要的全局状态）。
- 是否存在可以用派生值计算的状态被重复存储的问题。
-
性能与用户体验
- 是否有不必要的重新渲染（例如在
.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.
