关于 code-style
面向 Agent 的编码规范技能，指导代码保持一致、结构清晰并控制公开接口范围。它还要求在提交或总结前进行简化和自我审查。
主要功能
- 01代码组织模式指导
- 02简洁注释规范
- 03控制公开接口范围
- 04审慎处理 lint 诊断
- 05完成后审查与简化
适用场景
- 01遵循项目代码规范
- 02整理复杂分支逻辑
- 03判断是否采纳 lint 诊断
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/code-style确认已加载。
附带文件languages/js-ts.mdlanguages/rust.md
详细介绍
按需加载 $precise-minor-adjustment 技能，该技能用于告知 Agent 如何编写简洁且与代码库其他部分风格一致的代码。
完成任务后、提交或总结之前，还要根据 $precise-minor-adjustment 进行一轮简化。
代码风格
按需阅读以下对应文件：
| 语言 | 参考文件 |
|---|---|
| JavaScript / TypeScript | languages/js-ts.md |
| Rust | languages/rust.md |
我的代码风格中最重要的一条规则是：始终从不规则的逻辑中找出规律。你可以调整代码的组织方式，并通过注释实现这一目标。
组织代码
编写代码时要实现的目标之一，是让代码结构更清晰、更可预测。这样人们就能更轻松地掌控和审查代码。
例如，可以使用大的 match（Rust），并用简洁的代码处理不同分支和情况。
一千行结构清晰、可预测且有规律的代码，胜过五百行杂乱的代码。
注释
复杂逻辑必须添加注释。 除非 linter / checker 要求，否则不要把一句注释拆成多行。
注释应简单简短。如果下一位读者能在三秒内从代码中推断出来，就没有必要添加注释。
保留代码本身无法表达的内容：
- 不明显的限制或外部要求
- 拒绝某种看似更好的方案的原因
- 仅存在于代码库之外的背景信息（规范、上游服务的特性或合规规则）
这些注释应解释原因，而不是说明做了什么。
切勿编写仅仅复述函数名称的文档注释——这种注释毫无价值，还会逐渐与代码不同步。
复杂函数的另一种可接受的注释形式是流程注释。对于包含多个阶段的复杂逻辑，可以添加类似 // 1. Check environment // 2. Read config 的注释，帮助人们将代码划分为不同部分。
如果一段逻辑可以清晰地划分为多个阶段，且超过 50 行，就需要添加流程注释。
完成整个实现后，检查代码差异；如果差异超过 50 行却没有添加注释，就说明存在问题。
可见性
从不对外暴露任何内容开始。只有其他模块需要时才增加可见性。
每个导出项或公开项都是一份契约：它的名称必须保持稳定，其接口必须保持兼容。尽可能缩小这部分接口。
诊断处理
我的项目有一套严格的 lint 规则。遇到诊断信息很正常。
遇到诊断信息时，首先要思考，而不是修改代码。应检查该诊断的目的是否符合当前代码的用途和行为目标。还应考虑遵循该诊断是否会让代码变得更复杂、更难理解或更简单。
应拒绝不合理的诊断，并采纳合理的诊断。遵循代码风格。
拒绝不合理的诊断时，优先使用注释（// oxlint-disable-...、#[allow(...)]）禁用，而不是全局禁用并修改配置文件。你也可以检查代码库，了解是否有其他地方禁用了相同规则。如果某条规则被禁用的次数过多，可以在回复中建议我调整配置文件。但除非我要求，否则不要自行修改配置文件。
编写完成后
完成目标后，需要审查自己的代码，尤其要关注代码组织。