code-refine

代码精炼

范围以用户要求精炼的内容为准；如果用户没有指定，则使用当前已暂存和未暂存的差异，包括未跟踪的源文件。如果没有可精炼的代码，请说明并停止。若范围指明了更改（待处理的更改、分支、拉取请求），则按其指明的差异进行精炼；其他情况均视为一个区域。

加载 code-refinements 技能，并确保每项更改都遵循其规则和三个视角：约束、简洁性和参数性。如果尚未安装，请使用以下命令安装：

npx skills add https://github.com/alexandru/skills --skill code-refinements

工作流

1. 确定范围、契约和验证方式。 阅读项目的 Agent 指令、约定和相关规范。确定需要保留的行为和 API、范围内的关键路径，以及所需的验证方式。如果规范没有定义某种行为，请调查现有契约和调用方；报告尚未解决的歧义，不要擅自设定要求。
2. 识别并应用有充分依据的精炼。 从三个视角进行审查，并追踪调用方以核实行为方面的判断。每项更改都必须说明消除了哪种复杂性，并遵守下方契约。使用相关测试验证编辑内容；发现可观察的行为时，添加特征测试。报告需要通过更改行为才能修复的现有缺陷，并请求批准；获准修复时，须先通过失败测试证明问题，再进行修复。
3. 重复上述步骤，直到不再有值得进行的改进。 重新评估更改后的代码及其核心模型，在范围内寻找更多有充分依据的精炼。不要局限于局部清理：不同的表示方式可以消除无效状态、一次遍历，甚至整个模块。
4. 审查、验证并报告。 审查汇总后的差异，检查回归问题和更改之间的相互影响。修复或回退回归问题，在所有受支持的配置下运行项目要求的验证，并在修复后重新运行。关键路径发生变化时，检查性能。报告消除的复杂性、获准修复的缺陷及其测试、验证结果和限制，以及留给用户决定的事项。

不变量

• 精炼就是重构：未经用户明确授权，最终用户行为 MUST NOT 改变，包括修复现有缺陷。只有在保留可观察行为的前提下，内部结构、数据类型、调用顺序和中间表示才可以改变。功能必须保留，关键路径不得变慢。
• 以前能被代码接受的输入，之后仍必须被接受：曾经能解析的值、曾经成功的请求、已经存储的数据。收紧输入规则属于行为更改，必须经过授权。
• 公共 API 就是行为——包括用户编译所依据的签名及其说明契约的文档注释——除非用户或项目指令明确允许更改 API。若更改导致某条文档说明不再成立，就必须更新该说明。
• 测试必须在之前运行过的所有环境中继续运行：不得缩小到 CI 恰好运行的配置，也不得在尚未覆盖其测试用例时删除测试。
• 对于差异范围，只精炼差异新增或更改的内容；只有当差异中的更改确有需要时，才处理周边代码。