用途：这是一个仅在用户明确要求时手动激活的技能，用于缩减代码库总体规模。其核心理念是“代码会催生更多代码，熵会不断累积”，因此一切决策都偏向让最终代码库尽可能小。
主要能力与核心问题：它围绕一个核心问题展开——“改造之后代码库是什么样”。目标是最终代码库中的总代码更少，而不是当下要写的代码更少。写 50 行却能删掉 200 行属于净收益；为避免写 2 行而保留 14 个函数属于净亏损。它明确表示“不产生变更”不是目标，更少的代码才是目标；衡量的是最终状态而非投入。
使用方式：技能要求在使用前先加载 references/ 目录中的至少一个 mindset。步骤为：列出参考目录中的文件，阅读 frontmatter 描述以挑选适用的项，加载至少一个，并说明加载了哪一个及其核心原则；在完成这些之前不要继续。
三项自问：一、解决该问题的最小代码库是什么（不是最小的改动，而是最小的结果；能否变成 2 个函数而非 14 个，能否变成 0 个函数即删除该功能，实施后会删掉什么）；二、拟议改动是否导致总代码更少（前后统计行数，若改后大于改前就拒绝）；三、可以删除什么（这次改动让什么变得过时、什么是因被替换之物才需要的、最多能移除多少）。
它列出的红旗包括：认为“保留现状”的现状偏见、“这增加了灵活性”（追问为谁灵活，YAGNI）、“更好的关注点分离”（更多文件/函数就是更多代码，分离并非免费）、“类型安全”（值多少行，有时更少行的运行时检查更优）、“更易理解”（14 个东西不比 2 个东西更易理解）。
不适用场景：代码库对其功能而言已是最小、处于有强约定的框架中（不要与之对抗）、监管或合规要求强制特定结构。
限制：资料未提供具体安装命令、价格、平台或效果数据；新增 mindset 的方法见 adding-reference-mindset.md，但未提供其内容。