技能介绍

它解决什么问题

NestJS 的模块、控制器、Provider 三层看起来规整，但代码一多，工程层面的坏味道会集中出现在几个地方：入参校验散落在 Service 里，@Body() 拿到什么就用什么；守卫、拦截器到处复制，全局规则和路由级规则混在一起，最后没人说得清哪条链路生效了；异常被 controller 里的 try/catch 就地吞掉，前端只能收到 500；模块边界随业务膨胀，Provider 依赖变得隐式，forRoot / forFeature 越用越乱。

这个技能把上述问题收敛成一套可执行的工作流，让 Agent 按 NestJS 的惯用法生成可维护的 TS 后端，而不是一段能跑就完事的示例代码。

核心能力

它围绕 NestJS 的 DI、Guard、Pipe、Interceptor、Exception Filter 这些原生机制工作，主要包括：

模块设计：规划 module 边界、Controller 与 Service 的归属，以及 Provider 的可见性，避免把全部逻辑塞进 AppModule。
入参校验：用 class-validator 装饰器生成 DTO，配合 ValidationPipe({ transform: true, whitelist: true }) 做全局校验和白名单过滤，而不是在业务方法里逐字段写 if。
横切逻辑：产出 Guard、Interceptor、Pipe，并明确注册在全局还是路由级，减少重复代码和规则不一致。
接口设计：支持 REST 与 GraphQL 两种服务形态，先确认传输协议、鉴权方式和验证库，再进入实现。

关键步骤

Step 1 确认需求：判断是 REST 还是 GraphQL，鉴权方式是 JWT、Session 还是网关侧处理，验证库用 class-validator 还是 Zod。这一步决定后续模块边界。

Step 2 模块设计：规划 module 的边界、provider 列表和 DTO，明确 Controller 只做协议转换，Service 承载业务规则。

Step 3 实现：产出带 class-validator 的 DTO、Guard 和 Service，依赖注入通过构造函数显式声明，不手动 new。

Step 4 自检：核对依赖注入是否正确、全局 Guard 和路由级 Guard 的执行顺序、Exception Filter 是否覆盖预期错误，以及 DTO 是否真的被 ValidationPipe 拦截。

Step 5 输出工件：返回 NestModuleSpec，其中包含 module、controllers、dto、guards、notes，便于下游工具继续处理。

输出形式

最终输出分两部分：一是完整的 NestModuleSpec 结构化工件，二是自然语言摘要和改进建议，指出质量自检结果以及最值得修改的 2 到 3 个点。完整模板包含工作流要点、质量自检清单、工件示例和常见陷阱，写在 references/template.md 中。

适用边界

它只处理 NestJS，不会把 Express、Fastify 原生写法或其它 Node 框架改写成 NestJS 风格。如果只是一两个路由的轻量 API，用 Express 或 FastAPI 更直接，不必引入 module 和 DI 的抽象成本。安全相关的深度评审也不宜完全依赖它，产出的 NestModuleSpec 更适合交给 secure-code-guardian 做后续安全检查。