minimal-code-discipline

最小代码原则

使用此技能，在规划和编写代码变更时遵循最小代码（YAGNI 阶梯）原则。这样既能让差异集保持精简且显然正确，又不会牺牲保障用户安全所需的检查。

此技能与 ai-slop-cleaner 互为补充：该技能会在劣质代码落地后清理它；此技能则避免写出这些代码。

何时使用

在以下情况下使用此技能：

• 用户要求实现精简、简洁、遵循 YAGNI 原则或尽可能缩小差异集
• 计划或进行中的变更逐渐超出用户提出的要求
• 编写新代码时，可能出现范围蔓延、重复造轮子或推测性泛化
• 在实施前审查拟议差异集的规模

何时不使用

在以下情况下不要使用此技能：

• 用户明确要求构建范围广泛、功能丰富或面向未来的方案（以用户明确提出的范围为准）
• 任务是用户明确标记为临时的探索性脚手架
• 最小化会触及受保护的行为（见“不可妥协项”）

原则

先问是否必要。 先判断这项变更是否真的有必要；跳过那些只为推测性未来需求服务的工作。

先复用，再编写。 编写新内容前，先在代码库中查找已有的辅助函数、类型或模式。绝不要复制几份文件之外已经存在的辅助函数——应复用它，或将其提取到一个共享位置。

依赖阶梯。 优先使用标准库，其次是平台原生能力，再次是已安装的依赖。手写代码是最后的选择。只需几行代码就能解决时，不要引入新依赖，除非用户明确要求或批准。

先理解，再精简。 先阅读受影响的代码并追踪其执行路径。理解问题后，再提交最精简的正确差异集——不写出来的代码就不会出错。

朴实胜过巧妙。 与其采用巧妙的代码，不如选择朴实且显然正确的代码。

明确精简的边界。 用简短注释记录有意采用的简化方案，说明接受的限制，以及在什么情况下应替换该方案。

修复根因，而非症状。 在所有调用方共享的根因处修复错误，不要针对每个报告的症状分别打补丁。

不可妥协项

绝不要为了精简而省略：

• 跨越信任边界时的验证
• 防止数据丢失的错误处理
• 安全控制
• 无障碍基础要求
• 用户明确要求的范围

验证

报告完成前，请确认：

• 每一行新增代码都有存在的理由（没有推测性泛化，也没有重复的辅助函数）
• 差异集已精简到足以正确解决所述问题的最小程度
• 不可妥协项均得到保留
• 测试仍然通过，除所要求的变更外，行为保持不变