用途：在编写新代码、命名模块/文件/函数/类/变量、评审或重构以提升可读性、评估与降低复杂度时使用，目标是让代码便于人阅读、修改和删除。
主要能力：四项检查——①设计面向人类心智模型，倾向具体方案直到同一需求独立出现至少三次才抽象，从根源修复缺陷而非加特例分支，按仓库→服务→模块→函数的包含边界保持局部可理解，跨切面关注点（可观测性、可恢复性、可访问性、安全等）路径要易于查找，领域固有复杂度不要强行压平；②命名要求自解释意图，依次检查意图揭示、避免易混名、去除 data/info/manager/object/Impl 等噪音词、避免缩写（id/url/html 等更标准缩写除外并统一大小写）、可搜索（如 MAX_RETRY_COUNT 而非 5）、词性（类用名词短语，函数用动词短语）、全库同一概念只用一词；③圈复杂度预算：人工编写代码每函数 ≤4，AI 生成代码 ≤6，从 1 起 if/else if/case/for/while/catch/条件中 &&、||/三元各加 1，超预算需先重构；④注释不求多，优先自解释代码，注释用于说明原因（取舍、外部约束绕过、有意偏离），删除复述代码与过期注释，有信息量的 TODO 可留。
使用方式：行为保持的重构读取 refactoring/SKILL.md，其中提供坏味道目录、技术选择器与护栏；行为变更用 tcrdd，跨文件依赖解耦用 mikado-method。用户要求 CUPID 框架或宽泛设计质量评审时，先确认语言、用途、本地约定与范围，再按 Composable、Unix philosophy、Predictable、Idiomatic、Domain-based 逐项给出评级、具体代码证据与改进方向。
限制与注意：不要把 AI 代码的复杂度预算（6）套用到主要由人维护的文件，应按文件后续归属判断；命名与复杂度相互影响，先尝试重命名再抽取；去噪音词不要造成歧义；一词一概念是代码库级检查；领域带来的复杂度应显式化并可验证，而非强行消除；CUPID 评分是评审视角，不能作为无具体设计收益就拆分代码的理由。资料另给出若干基准数据与运行记录，未提供更多安装与价格信息。