用途：在动手写逻辑之前先做结构性判断。资料强调，结构性决策保护的是选择权，代码级决策保护的是简洁性；过度设计往往是一个过早、关闭了可能性的决定，而正确的基础数据结构能保持选择余地。
主要能力：
- 数据结构优先。先把数据形状定对，再写逻辑；正确的形状会让下游代码变得一目了然。做法是尽早定义核心类型、追踪每一种访问模式，并选择与主路径匹配的结构。资料指出，晚改数据结构等于重写，早改往往只是一行 diff。
- 代码层面只对结构做 DRY，而不是对每一行做 DRY。类型与数据模型应当收敛；三段相似语句仍胜过一次过早抽象。宁要显式，不要取巧；测试的是行为与边界情况，而不是行数。
- 并发推论：在让多个执行者共享状态之前，问一句“如果另一个执行者同时修改它会发生什么？”如果答案不是“什么都不会发生”，就做隔离。
- 脚手架优先：如果某件事对后续每个阶段都有帮助，就先做它。判断标准是“后续每个阶段是否都因它已存在而受益”。CI、lint、测试基础设施和共享类型属于脚手架。按选择权排序：先搭好环境再写功能，先有测试再修问题；提交保持小而单一用途。
- 先做减法再搭脚手架：先移除死重，再打地基。
使用方式：资料未提供具体安装命令、调用参数或代码示例，仅给出上述思考原则，供在编写逻辑前作为判断清单使用。
适用场景：定义新模块或新系统的基础类型与数据模型时；规划功能开发顺序、搭建 CI 与测试基础设施时；设计并发/共享状态边界时。
限制：该技能是原则性指导，不包含可执行步骤或工具集成细节；资料未说明支持平台、价格、性能效果等信息，暂未提供。