用途
该技能用于降低理解和修改软件的成本，依据是 Ousterhout 的《软件设计哲学》第二版，并以 Brooks 的“概念完整性”作为第二锚点。最终需要返回一个命名过的设计或修复方案、其理由，以及下一步动作。
主要能力
技能提供三条方法路线：
- 新增模块或有重大影响的 API/接口形态：加载
references/design-mode.md。 - 在降低复杂度的前提下修改既有代码：加载
references/improve-mode.md。 - 评估 diff、设计、PR 或设计门禁输入：加载
references/review-mode.md。
若只是局部命名或结构调整、不涉及边界决策，可用 clean-code；若需要测试先行执行，可用 tdd。选择合适方法本身不构成新的审批门禁。
共享设计规则
技能用以下关键词解释实际设计决策：
- strategic：现在投入一点设计，让下一次变更更便宜；其反面是 tactical（“先跑起来再说”）以及 tactical tornado（靠留下烂摊子最快交付的人）。
- deep module：简单接口隐藏大量功能。成本是接口，收益是其所隐藏的部分；浅模块的学习成本与内联相当。
- information leakage：一个设计决策反映在两个或多个模块中，属于变更归属失败，应让该决策有唯一归属。
- design it twice：对任何有重大影响的接口，在编码前画出两到三种实质不同的形态。
- stay strategic：修改既有代码时，不要附加让设计变差的特殊情况；要么适配变更，要么改进设计。
- decide what matters：命名当前情况依赖的少数几件事，最小化该集合，并只强调它们。
- reader, not writer：复杂度由下一个修改代码的人评判；如果只有你觉得简单，那它就是复杂的。
- conceptual integrity / smallest coherent shape：一个模型，且不超出问题本身。
示例表述：“这是战术性的——在浅模块上加一个特殊情况。Design it twice 保持概念完整性；成本是现在多花一小时，而不是以后的信息泄漏。”另一示例取自官方摘录：“backspace(cursor) 是一种虚假抽象——UI 仍须知道哪些字符会消失。一个有杠杆的 delete(start, end) 足矣；那些特殊方法则没有。”
使用方式与证据
应检查足够的实时代码或已陈述设计，以识别抽象、非正式接口（调用方必须知道的一切）以及相关的红旗或原则。只有当进一步阅读可能改变决策时才继续读。若没有仓库，则使用给定约束并标注假设。
要以读者而非写者视角发问：下一位开发者是否需要接口中不存在的事实？若是，即泄漏或晦涩的证据。复用已定选择；替代方案属于有重大影响的未决设计决策，而非每次局部编辑。
review 及所有设计门禁调用均为只读：只输出发现，不做编辑或测试运行。design 与 improve 可在用户请求范围内编辑，但不授权无关重构。
验收契约
使用所选模式的输出字段。为每条发现说明其背后的官方红旗或原则。报告真实被否决的替代方案，或说明无需新的设计选择。对于编辑，需指出改动文件、保持行为的工作或确切行为变化、已运行或不可用的检查。
在设计门禁下，返回 verdict（proceed | revise）、conceptual_integrity_check、blocking_findings、advisory_findings 和 required_changes。泄漏的决策、浅的新公开接口或战术性特殊情况在承重时可阻塞；纯命名美观问题为建议性。
注意事项
- 不要把一行 bug 修复变成设计练习，投入应与风险匹配。
- 当被破坏的模型正是请求本身时，不要保留既有模式。
- 不要将一致性与概念完整性混为一谈——一致地重复错误仍是缺陷。
- 不要为了填充类别而编造发现；clean 是有效结论。
- 不要引用或重构本技能所提炼书籍的原文。
- 深度先于长度（第 9.8 章）：函数在几十行之后，继续缩短很少有助于系统；更多小函数意味着更多接口和拼接方法。不要用十个词的方法名替代一条来之不易的注释。泄漏一种格式的小类通常过多，应合并。
- 不要把设计决策藏在提交信息里，注释应属于代码。
- private 加 getter 不是信息隐藏；如果调用方必须知道字段存在，它就在接口中。
- 大量文档往往是难以描述的信号，而非优点；应简化设计。
章节查找
所选模式会链接到其需要的原则、红旗和方法。仅当某个问题不适配这些路线时，才加载 references/chapter-map.md 进行定位。
限制
该技能的具体平台支持、收费方式、版本号与安装步骤暂未提供。