用途：在设计与评审类型、函数签名或编写任何静态类型语言代码时，用类型系统在编译期消除不可能状态、不匹配的基础类型和未处理的变体。资料称类型检查器是证明助手，任何被当作运行期数据放行的东西，都会变成编译器本可阻止的运行期故障。该技能适用于任何带类型的语言，并可由具体语法的技能来落地。
主要能力与模式：一、让非法状态不可表示，用和类型建模变体（TypeScript 判别联合、Rust/Swift/Kotlin 带载荷枚举、Scala 密封类、Haskell/OCaml 代数数据类型），不要用一堆可选字段让矛盾组合通过编译；资料举出 { completed: boolean; completedAt?: Date } 这类反模式，并建议从单一来源派生，或显式建模为变体。二、为语义基础类型加品牌，UserId 与 OrderId 底层都是字符串但不应互换；可用 newtype、opaque type、value class、phantom type、品牌交叉类型，创建时验证一次，下游信任类型。三、外部数据在解析前视为无类型，RPC 载荷、JSON、IPC 消息、命令行参数、配置文件、环境变量、数据库行都应在每个边界有解析函数转换为类型化模型。四、不要对类型系统撒谎，转换、不安全强制转换和绕过编译器的断言函数是等待发生的运行期崩溃；编译器无法证明的事应去证明（验证、收窄、精化模型），否则该转换就是隐患。五、穷尽匹配是编译器的职责，对和类型匹配时，新增变体未处理必须导致编译失败，使用语言惯用法实现。六、从权威模式派生类型，当 protobuf、OpenAPI、GraphQL、数据库迁移或设计令牌文件定义了形状，应从中派生而非手写平行类型。七、偏好编译期而非运行期，每个运行期断言、空值检查、instanceof 都说明类型系统未尽责，应把检查上移到类型。
资料给出的自检问题：能否写注释解释这组字段何时有效？能则类型太松，应拆成和类型；两个函数参数共享基础类型却含义不同？应加品牌；这个 any、as、assertNotNull 从哪来？应追溯到边界并在那里验证；下月新增变体时编译器会告诉下一个智能体在哪加分支吗？不会则匹配不穷尽；该类型是否在重复另一个文件拥有的形状？应改为派生。
使用方式与限制：资料未提供安装命令、调用步骤、价格或平台信息，暂未提供。技能本身是原则性指导，具体语法需结合相应语言的最佳实践技能；不涉及具体运行时实现。