用途：该技能是一种工作点视角，在软件设计、实现、重构、评审或验收生成代码时应用“编程即理论构建”理念，把理解视为主要产物、代码视为理解的表达，目标是让变更强化系统的共享理论，而非只添加局部能通过的代码。仅当用户显式调用时使用，例如“使用 theory-building 技能”或在某变更上应用该技能；不适合大范围仓库审计、周期回顾或功能完成后的漂移检查，后者应使用 theory-building-review。
主要能力：将代码库视为三层——现实世界（用户、业务规则、约束、边界情况）、程序（代码、数据结构、API、测试、UI、基础设施）和理论（解释程序为何如此的人类理解）；提供 5 分钟检查、设计遍历、评审遍历、实现支持等模式。要求在重大变更前明确领域问题、世界与程序的映射、不变量、现有约定与取舍；实现时保持命名、边界和测试与理论一致；评审时关注变更是否属于模型自然延伸；验收 AI 代码时先审视其假设、词汇、抽象与遗漏的失败状态。
使用方式：默认只在对话中返回输出，不创建或修改 CONTEXT.md、ADR、issue、计划、任务列表、源码注释等任何文件，除非用户明确说明写入目标与格式。理论遍历输出可包含理论、世界到程序映射、不变量、概念契合点与行动项；5 分钟检查用更短结构；设计规划用理论、映射、决策、取舍、行动项；代码评审优先给出具体缺陷与风险，再补充影响可维护性的理论契合问题。实现后可用简短说明记录文件、关键设计选择、原因与验证方式。
适用场景：设计功能、实现变更、评审 PR 或 diff、验收 AI 生成代码、修复 theory-building-review 发现的漂移问题。限制：需显式调用；默认不写任何文件；对高风险变更（安全、鉴权、计费、路由、状态机、生命周期、迁移、外部集成）应先确认理论、补充回归测试再实现；避免无必要的大规模重构；结论应基于可观察的结构、行为和测试，避免无依据的优劣评价。其他未提供。