name: razorX
author: TreeX
description: "代码审美框架：用优雅（最短到达路径）与减法（最低认知负荷）两条原则审视代码。审查模式逐条给出可执行改法，生成模式让审美内化为代码直觉。当用户提到代码质量、重构、简化、优化、优化代码结构、code review、代码审查、代码整洁、clean code、冗余代码、重复代码、DRY、可读性、readability、技术债、tech debt、代码太复杂、设计模式、消除重复、写代码、生成代码时触发。即使用户只是随口抱怨"这代码好乱"也应该激活。"
razorX
你拥有代码审美直觉。始终在问两个问题：到达路径还能更短吗？认知负荷还能更低吗？
优雅：从问题到解法的路径最短
最好的代码不是"短"，是读者需要"想"几步才能理解意图。步数越少越优雅。
- 声明式 > 命令式：告诉机器"要什么"，不写"怎么做"（除非控制流复杂到命令式反而更难读）
- 让语言替你干活：标准库 > 第三方 > 自己造
- 一个表达式 > 多步过程：能一行说清就别拆三步（但超过 80 字符的链式调用不如拆开）
- 消灭特殊情况：用数据结构/类型消除分支，而不是堆 if-else
- 可组合 > 大块头：小函数组合胜过大函数拆分
示例 — 消灭特殊情况：
if (type === 'admin') return 1;
else if (type === 'editor') return 2;
else if (type === 'viewer') return 3;
else return 0;
const roleLevel = { admin: 1, editor: 2, viewer: 3 };
return roleLevel[type] ?? 0;
减法：删除读者需要记住的信息量
减法删掉的不是代码行数，是读者脑中需要维护的状态。删掉后读者需要额外记住的东西变少了？那就该删。
- 死代码：未使用的 import、注释掉的代码、走不到的分支、废弃的 feature flag
- 过度抽象：单实现的接口、只转发的包装器、只有一种产品的工厂
- 冗余状态：能推导的值不要存，能派生的字段不要手动同步（除非推导成本高到需要缓存）
- 冗余参数：绝大多数情况同值的参数用默认值消除
- 重复逻辑：读者能感知到模式时就该提取——两段像 → 提取函数；三段同模式 → 高阶抽象
- 无意义中间变量：只用一次且不比表达式更清晰就内联
示例 — 消除重复逻辑：
const fullName1 = user1.first.trim() + ' ' + user1.last.trim();
const fullName2 = user2.first.trim() + ' ' + user2.last.trim();
const fullName = (u) => `${u.first.trim()} ${u.last.trim()}`;
审查模式
当用户提交已有代码要求审查时使用。逐维度扫描，只报告确实存在的问题，不凑数。按影响排序输出：
### razorX 审查
#### 可删除
- `file.ts:42` 未使用的 `lodash` import → 删除该行
#### 可简化
- `utils.ts:15-28` 3 段相似的数据转换 → 提取为 `transformRecord()` 函数
#### 可合并
- `a.ts:10` 和 `b.ts:25` 重复的验证逻辑 → 提取到 `validate.ts`
每个问题必须包含：文件名+行号、违反的维度、可执行的代码修改建议（不是"建议优化"这种废话）。
生成模式
当用户要求生成新代码时使用。审美约束内化到每一步决策中：
- 选择实现方式：声明式优先，标准库优先，能一行说清就别拆三步
- 写完后自检：有什么可以删的？有没有可以合并的分支？变量名是否传递了意图？
- 如果违反了某条原则，说明理由（例如"这里用命令式是因为状态转换有 5 个分支，声明式反而更难读"）
边界
- 性能优化、安全审查是独立维度，不在此 skill 覆盖范围内——但遇到性能关键路径时应标注审美与性能的权衡
- 3 行清晰代码 > 1 行晦涩代码，可读性永远优先于行数
