技能介绍

解决什么问题

在 TypeScript 项目里，类型校验通常是两套体系：编译期靠 type / interface 保证类型安全，运行期却要手写 if 分支或依赖第三方校验库。更麻烦的是，数据来源往往是 JSON 样本、Swagger 文档或既有的接口定义，没人愿意手动把这些描述抄成 Zod schema——抄错了运行期才发现，维护成本也高。

核心能力

这个技能把三类常见输入直接转成 Zod 校验模式：

JSON 样本：从实际响应或配置文件反推字段类型与结构
TypeScript interface / type：解析源码，而不是靠正则匹配文本
OpenAPI 规范：把文档里的 schema 对象映射为等价的 Zod 定义

依赖两个关键库：

ts-morph：基于 TypeScript 编译器的 AST 做结构化解析，能正确处理嵌套类型、字面量联合、可选字段等语法
zod-to-json-schema：负责 Zod 模式与 JSON Schema 之间的双向转换，保证转换不是单向的

工作流程大致是：读取输入 → 解析为结构化表示 → 生成 Zod 节点 → 输出可直接引用的 schema 代码。

适用边界与注意点

复杂约束可能丢失：JSON Schema 和 Zod 并非能力完全对等，比如 allOf 的合并语义、自定义 refine 逻辑，转换后需要人工确认
自动推断的类型不一定符合业务预期：JSON 样本里某个字段恰好全是字符串，不代表它不该是数字
SKILL.md 未提供经过验证的安装与使用流程，接入敏感流程前建议先在小范围项目里验证输出

截图预览

使用场景

后端工程师拿到团队的 OpenAPI 规范，需要为每个接口生成对应的 Zod 校验模式，减少手写校验逻辑。
前端开发者有一批 JSON 响应样本，希望反推出字段类型和可选性，直接生成可复用的 Zod schema。
技术负责人维护一个 TypeScript 库，接口定义改了之后要同步更新 Zod 校验层，避免类型和运行时校验不一致。
团队在做 JSON Schema 与 Zod 双向迁移，需要把现有规范转成 Zod 代码，或把已有 Zod schema 导出为 JSON Schema 供其他服务使用。