Engineering 是一个面向技术决策与工程思维的技能文档，主要用于回答“这个功能该怎么搭建”“两个技术方案怎么选”“系统结构如何设计”这类问题。它的定位是教方法，而不仅仅是给答案：在做出任何技术选择前，先追问正在解决的真实问题，而不是直接进入“用哪个技术”的方案式提问。例如面对“该用 MongoDB 还是 PostgreSQL”，文档主张先了解数据形态和查询方式，再让选择从问题中推导出来。
主要能力围绕技术决策展开。文档建议先澄清目标、影响与用户需求，再识别时间、团队知识、现有技术栈和规模等约束，然后评估决策的可逆性：库选择、配置变更等容易回退的决定应快速拍板，数据库、语言、架构等难以逆转的决定则应投入更多思考。最终要给出明确推荐，并说明理由与取舍，而不是只罗列选项。
在架构方面，文档强调结构即“有哪些部件、如何连接”，主张把常变的部分放在一起、少变的部分可以耦合更紧，对容易出错的地方多投入思考，能推迟的设计不要提前做。它提醒避免过度工程，例如创业公司不必上微服务、副项目不必用 Kubernetes，同时也反对完全无结构的欠工程。文档给出一个渐进路径：从简单脚本或单体开始，代码纠缠时划清模块边界，模块需要独立扩展时再抽取服务，遇到具体瓶颈后再采用专门方案，不建议跳步。
实现层面，文档强调清晰优先于技巧，代码被阅读的次数多于被编写；遵循三次法则，同一模式出现三次再考虑抽象，过早抽象比重复更糟；并提倡快速失败，在边界校验输入、用异常代替返回 null、让非法状态无法表示。它还说明该技能本身只教思考方式，具体知识放在参考文件中，例如技术选型、架构模式、模块边界、数据流、实现最佳实践、设计模式、重构、API 设计、性能与 CI/CD 架构，应按需查阅而非全部通读。
适用场景包括技术方案讨论、系统与 API 设计、重构规划、性能改进决策和 CI/CD 架构思考。限制在于：该技能明确不负责日常清理（如删除未使用导入）、不负责验证测试是否通过，也不直接承担编码实现；它引导工作，具体工作由其他技能或人完成。文档还说明，工程决策不必追求完美，而应做出理由清晰、可随上下文变化重新审视的足够好的决定。