最小化代码规范 是做什么的？
使用本技能在规划和编写代码变更时应用最小化代码（YAGNI阶梯）规范。它能确保生成的diff既小又明显正确，同时不牺牲保障用户安全的关键检查。
本技能与 ai-slop-cleaner 互补：那个技能在冗余代码落地后进行清理；而本技能则从一开始就防止冗余代码被写出。
何时使用
请在以下情况使用本技能：
- 用户要求实现最小化、精简、YAGNI 或尽可能小的 diff
- 一个计划或正在进行的变更超出了所陈述的需求范围
- 编写可能发生范围蔓延、重复造轮子或投机性通用性的新代码时
- 在实现前审查提议的 diff 大小时
何时不使用
在以下情况下不要使用本技能：
- 用户明确要求构建一个广泛、功能丰富或面向未来的系统（用户明确的范围优先）
- 任务是用户标记为“可丢弃”的探索性脚手架
- 最小化的压力会触及受保护的行为（见不可妥协项）
规范
存在优先。 先问变更是否真的需要存在；跳过仅为推测的未来需求而做的工作。
复用优先。 在编写任何新代码之前，先搜索代码库中已有的辅助函数、类型或模式。永远不要复制一个已经在几个文件之外存在的辅助函数——要么复用它，要么将其提取到一个共享位置。
依赖阶梯。 优先使用标准库，然后是平台原生能力，再是已安装的依赖项。手写代码是最后的选择。不要因为几行代码就引入新的依赖项，除非用户明确要求或批准。
理解优先。 先阅读受影响的代码并追踪其执行路径。一旦理解了问题，就编写最短的正确 diff——从未写出的代码永远不会出错。
笨但正确优先。 优先选择笨但明显正确的代码，而不是巧妙的代码。
标记上限。 用简短的注释记录故意的简化，命名所接受的上限以及什么情况下需要替换它。
根因优先。 修复所有调用者共享的根本原因，而不是为每个报告的症状打单独的补丁。
不可妥协项
永远不能简化或省略以下内容：
- 跨信任边界进行的验证
- 防止数据丢失的错误处理
- 安全控制
- 无障碍基础功能
- 用户明确要求的范围
验证
在报告完成之前，请确认：
- 每一行添加的代码都有其存在的价值（没有投机性通用性，没有重复的辅助函数）
- diff 是解决所述问题的最短方案
- 不可妥协项完好无损
- 测试仍然通过，行为除了按要求变更外没有变化