メニュー
基于 Martin Fowler 方法论的系统化代码重构。当用户要求重构代码、改善代码结构、减少技术债务、清理遗留代码、消除代码异味或提升可维护性时使用。本技能引导完成研究、规划和安全增量实现的分阶段流程。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
从想法和资源出发起草博客文章。当用户想要写博客文章、从研究中创建内容或草拟文章时使用。引导完成研究、头脑风暴、大纲制定和带版本控制的迭代式写作流程。
确保所有沟通内容符合品牌语调和风格指南。在创建营销文案、客户沟通、面向公众的内容时使用,或当用户提及品牌语调、语气或写作风格时触发。
按照 AI 代理接入最佳实践创建或更新 CLAUDE.md 文件
全面代码审查,涵盖安全性、性能和质量分析。当用户要求审查代码、分析代码质量、评估 Pull Request 或提及代码审查、安全分析、性能优化时使用。
从源代码生成全面、准确的 API 文档。用于创建或更新 API 文档、生成 OpenAPI 规范,或当用户提及 API 文档、接口端点、文档时使用。
Claude Code 教程交互式课时测验。通过 8-10 道混合概念和实践知识的问题测试对特定课程(01-10)的理解。可在课前用于预测试、课中用于进度检查或课后用于验证掌握程度。当用户说"quiz me on hooks"(给我出道钩子的测验)、"test my knowledge of lesson 3"(测试我对第3课的知识)、"lesson quiz"(课时测验)、"practice quiz for MCP"(MCP 练习测验)或 "do I understand skills"(我理解技能了吗)时使用。
| name | code-refactor |
| description | 基于 Martin Fowler 方法论的系统化代码重构。当用户要求重构代码、改善代码结构、减少技术债务、清理遗留代码、消除代码异味或提升可维护性时使用。本技能引导完成研究、规划和安全增量实现的分阶段流程。 |
基于 Martin Fowler 的《重构:改善既有代码的设计》(第2版)的系统化重构方法。本技能强调安全的、有测试保障的增量式变更。
"重构是在不改变代码外部行为的前提下,改进其内部结构的过程。" -- Martin Fowler
第一阶段:调研与分析
↓
第二阶段:测试覆盖率评估
↓
第三阶段:代码异味识别
↓
第四阶段:重构计划制定
↓
第五阶段:增量实施
↓
第六阶段:审查与迭代
开始前,请明确:
向用户展示:
"没有测试的重构就像不系安全带开车。" -- Martin Fowler
测试是安全重构的关键使能器。没有测试,你面临引入 Bug 的风险。
检查是否有现有测试
# 查找测试文件
find . -name "*test*" -o -name "*spec*" | head -20
运行现有测试
# JavaScript/TypeScript
npm test
# Python
pytest -v
# Java
mvn test
检查覆盖率(如果可用)
# JavaScript
npm run test:coverage
# Python
pytest --cov=.
如果有测试且通过:
如果测试缺失或不完整: 提供选项:
如果测试失败:
更深层次问题的症状。它们不是 Bug,但表明代码可以改进。
详见 references/code-smells.md 获取完整目录。
| 异味 | 表征 | 影响 |
|---|---|---|
| 过长方法 | 方法超过 30-50 行 | 难以理解、测试和维护 |
| 重复代码 | 相同逻辑出现在多处 | Bug 修复需要在多处进行 |
| 过大类 | 类承担了过多职责 | 违反单一职责原则 |
| 特性依恋 | 方法过度使用另一个类的数据 | 封装不良 |
| 基本类型偏执 | 过度使用基本类型而非对象 | 缺少领域概念 |
| 过长参数列表 | 方法参数超过 4 个 | 难以正确调用 |
| 数据泥团 | 相同数据项总是成组出现 | 缺少抽象 |
| Switch 语句 | 复杂的 switch/if-else 链 | 难以扩展 |
| ** speculative Generality** | "以防万一"的代码 | 不必要的复杂性 |
| 死代码 | 未使用的代码 | 困惑和维护负担 |
向用户展示:
对每个异味,从目录中选择合适的重构技术。
详见 references/refactoring-catalog.md 获取完整列表。
| 代码异味 | 推荐的重构手法 |
|---|---|
| 过长方法 | 提取方法、以查询取代临时变量 |
| 重复代码 | 提取方法、上移方法、形成模板方法 |
| 过大类 | 提取类、提取子类 |
| 特性依恋 | 移动方法、移动字段 |
| 基本类型偏执 | 以对象取代基本值、以类取代类型码 |
| 过长参数列表 | 引入参数对象、保持对象完整 |
| 数据泥团 | 提取类、引入参数对象 |
| Switch 语句 | 以多态取代条件表达式 |
| 投机性泛化 | 折叠继承体系、内联类、移除死代码 |
| 死代码 | 移除死代码 |
重要:采用分阶段的渐进方式引入重构。
A 阶段:快速见效(低风险、高价值)
B 阶段:结构性改进(中等风险)
C 阶段:架构变更(较高风险)
"修改 → 测试 → 通过?→ 提交 → 下一步"
对每个重构步骤:
预检
做一个小改动
验证
如果测试通过(绿色)
如果测试失败(红色)
每次提交应该是:
提交消息示例:
refactor: 从 processOrder() 中提取 calculateTotal()
refactor: 将 'x' 重命名为 'customerCount' 以提高清晰度
refactor: 移除未使用的 validateOldFormat() 方法
遇到以下情况时始终暂停并征求用户意见: