关于 code-maintainability
code-maintainability 是面向编写、重构或审查代码变更者的技能。它从命名、抽象、可读性和范围等方面检查可维护性，并在存在时遵循项目约定。
主要功能
- 01命名与代码组织指导
- 02抽象边界和内聚性审查
- 03复杂度与可读性检查
- 04控制代码变更范围
- 05遵循项目约定及对应技能
适用场景
- 01审查代码变更的可维护性
- 02重构代码并避免无关改动
- 03依据实际调用评估辅助函数与抽象
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/code-maintainability确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/abstraction-boundaries.mdcomplexity-and-readability.mdnaming-and-organization.mdscope-discipline.md详细介绍
代码可维护性
每当你编写、重构或审查变更代码时，都要使用这项能力，让代码保持易读且易于修改。以下每项关注点都从两个角度出发：编写代码时要遵循的实践，以及审查变更时要指出的问题。无论处于哪种模式，都要坚持同一标准——不能因为代码是你自己写的就降低要求。
如果项目的开发或结构约定，或项目定义的组件、路由或领域技能规定了某项规则，这项能力就应用可维护性视角，并点名交由相应约定或技能负责，而不是重复陈述规则。如果规则以“项目存在此类约定为前提”，那么它就是有条件的：对于没有此类约定的项目，应直接跳过。
指南：
- MUST 在存在负责该规则的技能时，点名并交由相应技能负责（项目的开发、结构、组件、路由或领域约定），总结其要求，而不是重复其措辞。
- MUST 将以项目特定约定为前提的关注点视为不适用，而非违规；前提是项目未采用该约定。
本文档中的关键字 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 的解释方式如 RFC 2119 所述。
命名与组织
有关以下内容，请参阅 naming-and-organization.md：
- 文件名遵循项目既定的文件命名约定（例如 kebab-case），并包含该约定要求的同目录配套文件（例如对应的样式模块文件）
- 将组件、辅助工具和数据访问模块放在正确的目录层级（路由本地优先于分组共享，分组共享优先于全局），并提供用于确定层级的决策流程图
- 遵循项目自身的路由约定（如果有定义），并将路由所需的配套文件（props/types、not-found、social-image）放在同一目录
- 标识符名称和大小写与变更文件及其周边代码的约定一致
- 对没有其他规则约束的名称，采用备用标识符词汇表；以及在项目约定、负责该规则的能力或值所传入的平台／宿主 API 存在时，如何让该词汇表服从它们
- 即使遵循既定项目约定，也要为可能产生未消歧领域特定含义的标识符命名；包括 living-project-documentation 能力中最契合的命名原则、其局部性例外，以及缺少该能力时仍适用的要求
抽象边界
有关以下内容，请参阅 abstraction-boundaries.md：
- 决定或审查一个函数、类或模块应包含哪些内容，以及内聚性等级为何并非线性关系——功能内聚远强于其他类型，而偶然内聚和逻辑内聚则远弱于中间等级
- 将新的共享逻辑放在被多个调用方使用的最低层级（路由本地优先于分组共享，分组共享优先于全局）
- 按照项目自身的组件约定划分服务端／客户端边界（如果有定义）
- 按照项目自身的领域约定，将领域特定的处理流水线（例如内容渲染链）保留在其唯一的所属模块中（如果有定义）
- 让各层级的导入方向保持正确，确保共享代码不会依赖路由本地代码
复杂度与可读性
请参阅 complexity-and-readability.md，了解以下内容：
- 如何符合项目配置的代码检查规则及复杂度或长度限制，包括评估超出限制的函数
- 如何为魔法数字和字符串指定有意义的常量名或设计令牌；只有在少数确有理由的情况下，才保留内联代码检查抑制指令（并附上说明理由的注释）
- 如何判断看似无用的代码（未使用的导入、不可达分支、已注释掉的代码块）该删除还是保留
- 为什么解释性注释和文档注释都应是最后手段，而非计划中的做法——最好的代码段无需注释；为什么若导出名称或导出集合含义不清，导致必须添加文档注释，这首先是边界缺陷，而非文档任务；以及为什么单位、可空性或边界是否包含端点，应首先体现在类型或名称中，而不是依赖注释
- 允许添加注释之前，应按顺序尝试的补救措施——先改进名称和类型，再调整接口，最后重新划分单位；在接受任何类型或名称都无法消除的注释之前，应重新审视这种划分，并参考 abstraction-boundaries.md 中关于内聚性的判断
- 为什么必须描述实现细节的边界文档注释，说明接口过于浅薄，而非文档完善
- 文档注释、重复说明性注释和注释语气的规则应遵循项目的开发约定；在静态类型语言中，应将重复的内联类型提取为具名别名
范围纪律
请参阅 scope-discipline.md，了解以下内容：
- 如何确保改动符合其声明的目标，包括评估目标未提及的文件——依照项目的开发约定，避免顺手重构
- 如何单独指出既存问题，而不是将其捆绑进本次改动
- 如何评估新增辅助函数、属性、配置选项或泛型类型参数是否属于推测性范围
- 如何使用两个或更多具体调用点证明新增抽象的合理性（YAGNI），以及仅在逻辑确实属于同一关注点时才提取或合并重复代码（遵循 DRY，但不要让无关调用方产生耦合）
评论
支持 Markdown