用途：在严格 TypeScript 代码库中强制可读、边界清晰的类型写法，让审查者能快速读懂签名与导出 API，而非依赖复杂的行内类型组合。若仓库已有更强的本地约定，应优先遵循仓库约定。
主要能力：区分边界类型、内部辅助类型与 UI 局部状态；优先保证签名和导出 API 的语义清晰；把工具类型当作构造工具而非人类阅读的主界面；偏好可用 lint 强制执行的规则而非主观建议。
核心规则：优先使用命名类型而非行内类型运算，将 Pick、Omit、交叉、映射类型和长联合提取为命名类型或接口后再用于参数、返回值、props 或导出；类型名应表达业务含义而非实现机制。对象契约优先用 interface，联合、元组、条件类型、映射类型、工具类型组合、品牌类型和提取别名优先用 type。跨服务、UI、持久化或包边界且字段稳定时，写显式 DTO 或视图模型；仅当派生形状与源类型紧密耦合且该耦合有用时才用 Pick/Omit，派生类型开始累积例外时应改为显式对象形状。null 应视为契约而非默认值，仅当外部系统、schema、协议或领域状态明确区分“空”与“省略”时使用；内部可选性优先用 undefined、可选属性或缺失字段，并尽量在每个边界保持一种缺失模型。避免匿名结构重复，优先复用共享实体和导出的子路径契约，不要导入宽泛的根 barrel。React 类型保持朴素：复用、被编辑或非平凡的 props 与 state 使用命名契约，不要仅为类型方便把 props 镜像到 state，避免 effect 驱动的类型变通。
使用方式：按决策规则判断 Pick/Omit 的取舍，按 null 与 undefined 的适用条件选择缺失模型，并按审查清单依次检查导出类型或函数签名是否可无需展开工具类型即可理解、类型名是否传达领域含义、null 是否有真实边界契约支撑、是否已有共享契约可用、规则能否由 ESLint、TypeScript 或代码审查指南强制执行。提出仓库级规则时，应把风格指导与 lint 规则或审查启发式配对；若仓库已有不同约定，应记录例外而非静默覆盖。
适用场景：TypeScript/TSX 代码审查与编辑、定义共享契约、创建或重构类型、统一边界类型与缺失值模型。
限制：资料未提供具体安装命令、配置方式、支持的平台、收费或价格信息，也未提供可执行工具的具体实现细节；该技能以指导性规则为主，实际落地依赖仓库既有约定与 lint 配置。