| name | code-review-refactor |
| description | 对现有 Nuxt 4 + Vue3 + Vuetify3 代码进行 Code Review，并给出“可落地”的重构/复用方案（逻辑抽取、CSS 去重、页面 JSON 驱动复用）。 |
Code Review & Refactor 规范 Skill
当用户提出“代码很乱 / 需要 Code Review / 重构不够规范 / 提取可复用逻辑 / CSS 太多 / 页面重复应该 JSON 驱动”等诉求时，使用本 Skill。
0. 使用范围（When to Use）
- 用户明确说要 Code Review
- 或用户反馈：组件/页面冗长、CSS 重复、相似页面太多、缺少抽取到
utils/composables/services、缺少可复用结构
- 或发现你在修改时重复造轮子（应优先提取/复用）
1. 重构总原则（必须遵守）
- 行为优先（Behavior First）：重构仅做结构优化，不改变既有功能、接口与用户交互语义。
- 小步可验证：每次改动都应能局部验证；先提取再替换，避免“一次大改导致难排查”。
- 优先抽取可复用逻辑：
- 纯函数与可复用算法：
app/utils/
- 与组件生命周期/状态联动的逻辑：
app/composables/
- API 请求/数据转换：
app/services/
- 优先组件化重复 UI：
- 动作按钮组、筛选条、分页条、表格工具栏等重复结构 -> 公共组件
- 相似页面 -> 用“配置/JSON + 事件绑定”做驱动，而不是拷贝复制页面
- CSS 去重：
- 多处重复的 CSS -> 提取为组件内共用 class，或提取公共样式（同风格、同作用域规则）
- 只为“一个小变量”复制 CSS 的 -> 合并成同一个 class + 参数化/状态类
2. Code Review 检查清单（Checklists）
2.1 逻辑抽取（Logic Extraction）
在 review 时，逐段检查是否存在以下情况：
- 一个组件里出现多次相同的处理逻辑（如 parse/safeParse/格式化/渲染拼装）。
- 多个页面存在相同的业务流程（如同一类 SSE 流式组装、同一类 markdown/eCharts 渲染触发）。
- 与页面无关的纯逻辑没有被移到
utils 或 composables。
输出要求：
- 指出“重复点”与“提取位置建议”（utils/composables/services 哪个更合适）
- 给出新的接口/函数签名建议（至少用参数名与返回类型描述）
2.2 组件拆分（Componentization）
- 组件文件是否超过合理规模（建议阈值：500 行内易维护，复杂组件建议拆子组件）
- 是否存在“混杂多职责”（例如：渲染 + 请求 + 状态 + 事件处理全部写在一个组件）
输出要求：
- 提出“拆分方案”：哪些子组件/哪些 composables
- 标明拆分后组件仍保持同样的 Props/事件语义
2.3 CSS 去重（CSS De-duplication）
检查：
- 不同组件/页面有大量相同 CSS（尤其是
markdown-body、code block、card spacing、按钮样式等）。
- 相同选择器重复定义或只差少量颜色/间距。
输出要求：
- 优先给出“提取成一个 class”方案
- 或建议做“公共样式组件/公共 wrapper 组件”（如果是 UI 结构层面的重复）
2.4 JSON 驱动的页面复用（Config-Driven Pages）
当你发现多个管理页面“按钮数量不同、内容通过 JSON 稍有差异”，建议使用 JSON 驱动：
- 页面结构拆为通用骨架：
- 顶部标题区
- 操作按钮组（来自配置）
- 表格/列表区（列定义来自配置）
- 弹窗/抽屉（表单字段来自配置）
- 事件由页面注入（例如：
onAction(actionKey, payload) 或通过映射表）
输出要求：
- 提出一个“最小通用配置 schema”（字段列表 + 示例）
- 指出每个页面需要补充的差异化配置项
2.5 TypeScript 与安全护栏
检查是否存在：
arr[i] 取值后未做 TS 收窄导致 T | undefined 警告- SSE/流式数据拼接在 TS 层面不安全
输出要求：
- 给出 TS 收窄的推荐写法（局部变量 + if 守卫 / type guard）
3. 推荐的输出格式（必须用）
当用户说开始 Code Review 时，你的回答应使用以下结构（按序）：
## 最关键问题（按严重度从高到低）
- 每条用一句话概括 + 标明影响范围（渲染/性能/可维护性/正确性）
## 重构/复用建议（可落地）
- 对每条建议写：提取目标（utils/composables/services/组件/CSS）、原因、预计收益
## JSON 驱动复用方案（如果存在重复页面）
- 给出配置 schema（字段列表）+ 示例（可以是伪 JSON）
## 验证与回归（Test Plan）
- 给出最少的手动验证清单（UI 是否一致、功能是否不变、关键交互是否回归）
4. 允许与禁止
允许：
- 提取公共逻辑、拆子组件、创建新 util/composable/services
- CSS 合并、抽取公共 class、增加必要 wrapper 组件
禁止：
- 仅为“看起来更漂亮”而改变现有交互语义或数据结构
- 大而全的重写（除非用户明确要求并且能接受高风险）
