用途：在编写、重构、评审或架构设计代码时，按 Robert C. Martin 的整洁代码、整洁架构与整洁工艺原则行事。目标不是背诵规则，而是让后来者（往往是半年后的自己）能读懂、敢修改、可信任代码。
主要能力：提供 L1 日常规则（有意义的命名、小函数、无副作用、DRY、无魔法数字、快速失败、童子军规则）；函数规则（约 20 行内、只做一件事、单一抽象层级、不用标志参数、参数尽量少、命令查询分离）；命名清单；Kent Beck 四条简单设计规则（通过测试、揭示意图、消除重复、最少元素）；评审报告格式；依赖设计决策树；架构评审检查；代码坏味道到修复的对照表。更深入内容放在 references/ 中：principles.md（SOLID、命名、函数、类、注释、错误处理、格式）、testing.md（TDD 三定律、FIRST、整洁测试、边界与学习测试）、component-design.md（组件内聚与耦合）、concurrency.md（并发难点与测试）、architecture.md（整洁架构分层、依赖规则、用例、实体、尖叫架构、Humble Object、组合根）、craftsmanship.md（职业纪律）、smells-and-heuristics.md（完整坏味道目录）、glossary.md。
使用方式：先按任务选择模式——编写/重构、评审、架构设计。重构仅在测试为绿时进行：先跑测试套件，绿则重构，红则先修复或报告失败；每次只做一处结构性改动，行为不应改变；再跑测试，仍绿才继续。若某段代码无测试覆盖，应说明，并先补测试或只做可人工核验的改动。评审时按给定结构输出，锚定原则或坏味道并给出具体修复。架构设计先读 architecture.md。
适用场景：写代码、重构、代码评审、模块或系统边界设计、处理并发、评估技术债与排期等。
限制与注意：整洁不等于复杂，应让方案与问题复杂度匹配，避免过度构建；架构分层只留给确有分歧变化原因的系统。超出该资料范围的具体收费、平台支持、安装命令等暂未提供。