用途
Refactor 是一个系统化重构 skill，用于对现有代码执行结构性重构或技术债改造，并验证重构前后行为保持一致。它强调重构过程安全、可追溯、符合质量标准。一般代码规范审查建议使用 code-quality。
触发条件
- 用户需要重构现有代码
- 用户要求优化代码质量
- 用户提到技术债、代码改造
- 用户要求审查并改进现有实现
核心原则
重构安全原则分为三个阶段：
重构前必须满足：有明确的重构范围；有足够的测试覆盖（≥80%）；所有测试通过。
重构过程中：小步重构，每步可验证；每步后运行测试；不添加新功能。
重构后必须满足：所有测试通过；覆盖率不降低；生成重构报告。
与其他 Skills 的协作
- 代码无法测试：使用 /retrofit 建立基线记录现状与外部约束，再与用户确认目标行为后重写
- UI 重构：使用 /ui-orchestrator 应用 UI 约束规范
- 代码质量检查：使用 /code-quality 应用 MTE 原则
- 需要文档化：走 keel 流程生成规范文档
- 编写/补充测试：使用 /testing-guide 测试质量约束（断言、Mock、变异测试）
- 重构后更新描述：使用 /code-self-describe 更新模块自描述（--update）
工作流程
- 确定重构范围：用户指定范围则进入 Step 2；未指定则系统审查、发现问题、用户确认范围
- 评估测试状态：有测试且覆盖 ≥80% 进入 Step 4；有测试但覆盖 <80% 进入 Step 3 补充测试；无测试进入 Step 3 新建测试
- 补充/新建测试：可测试则编写测试并确保覆盖率 ≥80% 后进入 Step 4；不可测试则标记为“需要重写”进入 Step 5
- 执行重构：普通代码应用 /code-quality；UI 代码应用 /ui-orchestrator
- 重写流程（如需要）：/retrofit 建基线 → 与用户确认目标行为 → 正常 keel 流程 → 重新实现
- 验证与报告：运行所有测试、检查覆盖率、生成重构报告
Step 1：确定重构范围
用户明确指定范围时直接使用，例如“重构 src/services/user.ts”“重构用户认证模块”“优化 UserService 类”。
未指定范围时使用 Code Smells 检查清单审查代码，阈值摘录自 /code-quality 核心阈值表，变更需同 commit 同步；P0/P1 为本 skill 的修复优先级映射：
- 过长函数：行数 > 50，P0 如果 > 100，P1 如果 > 50
- 过多参数：参数 > 5，P1
- 过深嵌套：嵌套 > 3 层，P1
- 重复代码：相似代码块 > 3 处，P0
- 上帝类：行数 > 500 或职责 > 3，P0
- 特性依恋：频繁访问其他类数据，P2
- 数据泥团：多参数总是一起出现，P2
审查报告包含审查范围、发现的问题（按 P0/P1/P2 分级）、建议重构顺序和预计影响。随后使用 AskUserQuestion 让用户确认重构范围，选项包括全部重构、仅 P0、指定范围、暂不重构。
Step 2：评估测试状态
检测测试框架（Jest / Vitest / Mocha / pytest 等），运行覆盖率报告并检查目标文件覆盖率。覆盖率阈值摘录自 /testing-guide 核心阈值表，变更需同 commit 同步。
测试状态分类：
- 充分：行覆盖 ≥80%，分支覆盖 ≥80%，进入 Step 4
- 不足：有测试但覆盖率 <80%，进入 Step 3 补充测试
- 无测试：目标范围无测试文件，进入 Step 3 新建测试
- 不可测试：代码结构导致无法编写有效测试，进入 Step 5 重写流程
不可测试的代码特征包括：硬编码外部依赖（数据库、API、文件系统）；无法注入依赖（构造函数中 new 具体类）；业务逻辑与 IO 混合，无法分离；全局状态依赖；无法 Mock 的第三方库深度耦合。满足 2 个以上条件即标记为“不可测试”。
Step 3：补充/新建测试
编写测试时必须遵循 /testing-guide 的质量约束。测试质量要求从基础到高级：Level 1 覆盖率（行/分支 ≥ 80%）；Level 2 断言质量（禁止弱断言，验证具体值）；Level 3 测试有效性（变异得分 ≥ 80%，推荐）。
测试编写规范：测试依据来自需求，不是代码；每个测试必须有具体断言（禁止 toBeDefined、toBeTruthy 等弱断言）；测试名称描述预期行为，格式为 [方法] 应该 [行为] 当 [条件]；Mock 只用于外部依赖，不 Mock 内部实现。
覆盖率验证命令示例：npm run test:coverage -- --collectCoverageFrom='<target-path>'，确保行覆盖率 ≥ 80%、分支覆盖率 ≥ 80%。变异测试验证（推荐）：npx stryker run --mutate '<target-path>'，目标变异得分 ≥ 80%。
Step 4：执行重构
重构前检查：测试全部通过；已创建 Git 分支或可回滚。
普通代码重构应用 /code-quality MTE 原则：过长函数用提取函数，每个函数 ≤50 行；过多参数用参数对象，参数 ≤5 个；过深嵌套用早返回、提取函数，嵌套 ≤3 层；重复代码提取公共函数，无重复块；上帝类拆分职责，每类单一职责。
UI 代码重构走 /ui-orchestrator 路由到对应的 UI skill 执行。布局 / token / 交互状态 / 空状态等审查判据见 dev-workflow 的 ui-quality-checklist。重构特有、上述两处都不覆盖的三条：动画只使用 transform / opacity（其余属性触发重排，重构中最易引入性能回归）；遵循 prefers-reduced-motion；优先使用组件库已有的可访问原语，不自己实现交互控件。
小步重构原则：每次执行一个重构操作，运行测试，测试通过则继续下一步，测试失败则回滚并重新分析，提交可选但推荐频繁提交。使用 TodoWrite 追踪重构进度。
Step 5：重写流程
当代码被判定为“不可测试”时进入重写流程，详见 references/rewrite-flow.md。
Step 6：验证与报告
验证清单包括无新增 lint 警告、功能行为不变。重构报告模板详见 references/report-template.md。
输出文件
输出到 docs/devdocs/ 目录：
- 05-refactor-audit.md：代码审查报告（Step 1）
- 05-refactor-plan.md：重构计划（Step 1 确认后）
- 05-refactor-report.md：重构报告（Step 6）
- 05-refactor-rewrite.md：重写报告（如适用）
文件命名规则：普通重构为 05-refactor-.md；针对特定模块为 05-refactor-<module>-.md。
约束
范围约束：未指定范围时必须先进行代码审查；用户必须确认重构范围。
测试约束：无测试或覆盖不足时必须先补充测试；代码不可测试时必须进入重写流程；重构后覆盖率不得降低。
过程约束：每步重构后必须运行测试；不得在重构中添加新功能。
协作约束：UI 重构必须应用 /ui-orchestrator 约束；代码重构必须应用 /code-quality MTE 原则；重写前必须用 /retrofit 建立基线，并与用户确认目标行为后才能定需求。
文档约束：必须生成重构报告；重写时必须生成 keel 文档；报告必须包含前后对比。
错误处理与集成
错误处理详见 references/error-handling.md（测试失败、覆盖率不足、代码不可测试）。与 keel 的集成详见 references/devdocs-integration.md（流程位置图、调用关系图）。
语言
接受中英文提问，始终用中文回复，所有文档用中文生成。