| 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、回答问题时主动触发。
工作流程
-
确认检查范围
- 若用户指定文件/目录：只检查指定范围。
- 若用户说 "review PR / 检查改动"：用
git diff 或 git status 确定变更文件；报告位置必须落在 diff 新增或修改行，但可以读取上下文判断问题。
- 若未指定且无 git 变更：向用户确认要检查哪些文件，不要盲目扫整个仓库。
-
读取代码：读取目标文件，并用全文搜索定位相关代码；必要时补充读取上下文（被调用的 hook、类型定义、父组件等）。
-
读取检查清单：执行 review 前根据用户语言选择清单：
-
只输出命中的问题，通过/不适用的条目一律不提。
输出格式
若无命中，一句话说明 "未发现清单命中的问题"，并说明检查范围和已对照分组数量；只有用户要求完整记录时才列出全部分组名。
若有命中，按如下格式输出（中文问 → 中文字段名；英文问 → 用下面英文字段名）：
中文：
## 命中问题（共 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 流程时读取；不要在普通问答或改代码任务中主动加载。
