AI Skills
frontend-code-review

frontend-code-review

热门

审查 Dify 前端代码的正确性、可访问性、组件设计、dify-ui 使用、数据/查询边界、性能和测试。触发条件为 `.tsx`、`.ts`、`.js`、UI、React、Next.js、待变更或聚焦前端审查请求。

15万Star
2.3万Fork
更新于 2026/7/14
获取 Skill源代码

相关 Skills

nextjs-supabase-auth4.3万folder-structure-blueprint-generator3.6万app-store-screenshots6024
SKILL.md
readonly只读
name
frontend-code-review
description

审查 Dify 前端代码的正确性、可访问性、组件设计、dify-ui 使用、数据/查询边界、性能和测试。触发条件为 `.tsx`、`.ts`、`.js`、UI、React、Next.js、待变更或聚焦前端审查请求。

前端代码审查

何时使用

当用户要求审查、审计、分析或检查 web/、packages/dify-ui/ 或前端相关的 TypeScript 文件中的前端代码时，使用此技能。

支持的模式：

  • 待变更审查：检查暂存区和工作区中的更改。
  • 文件聚焦审查：检查明确指定的文件或路径。
  • 差异/片段审查：使用尽力而为的引用审查粘贴的差异或片段。

不要将此技能用于 api/ 下的纯后端代码；请改用 backend-code-review。

所需上下文

在审查之前，请阅读相关的本地约定：

  • web/AGENTS.md 了解 Dify 前端工作流、覆盖层、设计令牌、状态和测试。
  • packages/dify-ui/README.md 和 packages/dify-ui/AGENTS.md 当代码使用或更改 @langgenius/dify-ui/* 时。
  • web/docs/overlay.md 当审查对话框、抽屉、弹出框、工具提示、菜单、选择框、组合框或其他浮动 UI 时。
  • web/docs/test.md 和 frontend-testing 技能当审查测试或可测试性时。
  • karpathy-guidelines 用于范围控制和聚焦、可验证的更改。
  • how-to-write-component 当审查 React 组件结构、所有权、副作用、查询/变更约定或记忆化时。

对于任何 UI、UX 或可访问性审查，在最终确定发现之前，请获取最新的 Web 界面指南。将其视为必需的基线，而不是可访问性真相的完整来源：

https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md

如果审查依赖于当前的框架、SDK、浏览器 API 或可访问性行为，并且本地代码未解决，请先检查当前的官方文档。对于浏览器兼容性、弃用或行为敏感的前端 API，请验证 MDN 或相关标准。

规则包

应用每个相关的规则包：

审查流程

  1. 确定审查范围。对于待变更，检查 git diff --stat、git diff 以及相关的暂存区差异。对于文件聚焦审查，保持在指定文件内，除非必须读取引用的所有者/约定。
  2. 阅读更改行周围的代码以及所属模块。不要通过孤立的片段进行审查，当附近的所有权、标签、查询输入或覆盖层结构决定正确性时。
  3. 首先检查用户可见的回归：可访问性、交互中断、认证/权限泄露、查询/水合错误、数据丢失、导航错误和不可能状态。
  4. 然后检查可维护性和性能：所有权、副作用、包装器、记忆化、捆绑/瀑布风险、测试和设计系统漂移。
  5. 仅报告可操作的发现。不要列出推测性风险、样式偏好或广泛的重构，除非它们直接与范围内可重现的问题相关。

严重级别

  • P0：安全/隐私/认证泄露、数据丢失、生产崩溃、关键流程不可访问或主要工作流中断。
  • P1：用户可见的回归、水合/SSR 失败、无效的 API/查询约定、键盘/焦点行为中断或严重的设计系统/a11y 违规。
  • P2：可能导致错误、重复状态、错误所有权、缺少对风险行为的测试或非关键 a11y 问题的可维护性或性能问题。
  • P3：具有明确价值的次要清理。除非用户要求彻底审计，否则省略。

输出格式

以发现项开头，按严重级别排序。使用此结构：

## 发现项

- [P1] 简短问题标题
  文件：`path/to/file.tsx:123`
  为什么重要以及如何重现或推理。
  建议修复：具体的修复方向。

## 开放问题

- 问题或假设（如果有）。

## 总结

简要的次要上下文。提及未运行的测试或剩余风险。

规则：

  • 如果没有发现项，则说 No issues found. 并提及任何测试缺口或剩余风险。
  • 始终包含文件和行号（如果可用）。
  • 保持发现项具体且可重现。
  • 默认不包含赞扬部分。
  • 除非用户明确要求审查加实现，否则不要要求应用修复。