frontend-checklist

name	frontend-checklist
description	按前端开发检查清单对照当前代码变更、PR diff、指定文件或代码片段，给出命中问题清单和修复建议。仅在用户显式要求按 checklist / 检查清单 review 前端代码时触发，例如 /frontend-checklist、按前端清单检查、前端自检、检查前端改动、review 这个 PR 的前端问题，或英文 "frontend checklist review"、"review this PR against the frontend checklist"、"check frontend changes against checklist"。

Frontend Checklist Review

何时使用

仅当用户显式请求时调用，例如：

• "/frontend-checklist"、"按前端清单检查这段代码"、"前端 PR 自检"
• "用这份清单 review 一下 xxx.tsx"
• "按 checklist review 这个 PR"、"检查前端改动有没有清单里的问题"

不要在用户只是写代码、改 bug、回答问题时主动触发。

工作流程

1. 确认检查范围

   • 若用户指定文件/目录：只检查指定范围。
   • 若用户说 "review PR / 检查改动"：用 git diff 或 git status 确定变更文件；报告位置必须落在 diff 新增或修改行，但可以读取上下文判断问题。
   • 若未指定且无 git 变更：向用户确认要检查哪些文件，不要盲目扫整个仓库。

2. 读取代码：读取目标文件，并用全文搜索定位相关代码；必要时补充读取上下文（被调用的 hook、类型定义、父组件等）。

3. 读取检查清单：执行 review 前根据用户语言选择清单：

   • 用户用中文提问 → 读 references/checklist.md，review 输出也用中文
   • 用户用英文提问 → 读 references/checklist.en.md，review 输出用英文
   • 用户明确指定语言时以用户指定为准 按清单分组逐类核对。

4. 只输出命中的问题，通过/不适用的条目一律不提。

输出格式

若无命中，一句话说明 "未发现清单命中的问题"，并说明检查范围和已对照分组数量；只有用户要求完整记录时才列出全部分组名。

若有命中，按如下格式输出（中文问 → 中文字段名；英文问 → 用下面英文字段名）：

中文：

## 命中问题（共 N 项）

### [分组名]
- **[清单条目原文]**
  - 位置：`path/to/file.tsx:行号`
  - 现状：<一句话描述当前代码怎么违反的>
  - 建议：<具体修改方向，必要时给 1-3 行示例代码>

English:

## Issues found (N total)

### [Group name]
- **[Checklist item verbatim]**
  - Location: `path/to/file.tsx:line`
  - Problem: <one sentence describing how the code violates this>
  - Suggestion: <concrete fix direction; 1-3 lines of example code when useful>

约束：

• 引用清单条目时用原文，便于用户在清单文件里定位
• 每个问题必须给出文件路径和行号
• 现状和建议各用一句话，不展开长篇解释
• 按严重度排序：安全、数据丢失、竞态、内存泄漏、错误处理等硬问题优先，其次是可维护性、性能、风格问题
• 不要输出 "通过" / "不适用" 的条目
• 末尾不写总结性套话（如 "希望对你有帮助"）

判断原则

• 仅报告能从代码中看出的问题。无法判定的（如 "是否覆盖移动端尺寸"、"是否有埋点"）不要猜测，跳过即可。
• 区分硬错误和风格偏好：XSS 风险、竞态、内存泄漏是硬错误，优先报告；命名、解构等风格问题次之。
• 不强推某种框架偏好，例如不把 React 规则套到 Vue 代码上。
• 违反清单但可能有合理理由时，在建议里注明 "若刻意为之请在 PR 描述中说明原因"。

---

检查清单

中文清单在 references/checklist.md，英文清单在 references/checklist.en.md。按用户语言选择对应的清单文件，只有在执行本 skill 的 review 流程时读取；不要在普通问答或改代码任务中主动加载。