mcpField
N
nestjs

nestjs

github.com/ulpi-io开发5129 次安装10 周前更新
代码仓库

关于 nestjs

nestjs 是用于处理 NestJS 开发任务的 Skill，通过项目参考资料和模块化约定指导实现，适合开发者及编码 Agent。内容涵盖验证、依赖注入、实现流程与验证。

主要功能

  1. 01按任务选择 NestJS 参考资料
  2. 02实现前确认技术栈约定
  3. 03遵循模块化架构与依赖注入
  4. 04指导验证、测试和检查

适用场景

  1. 01创建或修改 NestJS 模块
  2. 02实现带 DTO 验证的端点
  3. 03处理身份验证、队列或数据库

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ulpi-io/skills --skill nestjs

安装后在 Claude Code 中输入/nestjs确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
auth.md
config.md
controllers.md
cqrs.md
docker.md
error-handling.md
health.md
interceptors.md
logging.md
microservices.md
middleware.md
modules.md
openapi.md
pipes.md
prisma.md
project-structure.md
providers.md
queues.md
scheduling.md
stack.md
testing.md
typeorm.md
validation.md
websockets.md

详细介绍

此技能是 NestJS 参考资料集的路由壳层。

不可妥协的规则：

  1. 首先阅读 references/stack.md，了解项目的 NestJS 版本、ORM 和已锁定的决策。
  2. 然后仅加载实际任务所需的参考资料。
  3. 每个领域一个模块——控制器、服务、DTO 和实体都放在各自的模块目录中。
  4. 控制器应保持精简——验证（DTO + 管道）、委托（服务）、返回结果。不包含业务逻辑。
  5. 所有输入都必须通过 DTO 验证——在每个 DTO 上使用 class-validator 装饰器，并全局配置 ValidationPipe。
  6. 任何地方都使用依赖注入——绝不使用 new Service()。通过构造函数注入，并通过模块提供。
  7. 避免循环依赖——仅在最后不得已时使用 forwardRef()，优先调整结构。
  8. 将繁重的 NestJS 指南放在 references/ 中，不要内联在此处。

nestjs

输入

  • $request：正在处理的 NestJS 模块、端点、子系统或功能

目标

通过项目基于模块的架构处理 NestJS 工作，确保实现遵循既定的依赖注入、验证、数据访问和请求生命周期模式。

步骤 0：阅读技术栈约定

始终从以下文件开始：

  • references/stack.md

该文件说明：NestJS 版本、ORM（TypeORM/Prisma/Drizzle）、包管理器、身份验证策略、队列系统和已锁定的依赖选择。

成功标准：在开始实现前，明确项目的 NestJS 架构和已锁定的决策。

步骤 1：仅加载相关参考资料

使用路由表选择参考文件。不要批量加载整个参考资料目录。

任务阅读
NestJS 版本、ORM、关键依赖、CLI、项目布局references/stack.md
文件夹约定、模块组织、桶导出references/project-structure.md
创建或编辑模块references/modules.md
控制器、路由装饰器、请求生命周期references/controllers.md
服务、提供者、依赖注入references/providers.md
DTO、class-validator、ValidationPipe、转换references/validation.md
TypeORM 实体、仓储、迁移references/typeorm.md
NestJS 与 Prisma 的集成references/prisma.md
守卫、身份验证、授权、JWT、Passportreferences/auth.md
拦截器、日志记录、缓存、响应映射references/interceptors.md
管道、自定义验证、参数转换references/pipes.md
异常过滤器、自定义异常、错误响应references/error-handling.md
BullMQ 队列、处理器、流程references/queues.md
WebSocket 网关、事件、房间references/websockets.md
微服务、传输方式、消息模式references/microservices.md
OpenAPI/Swagger 装饰器、架构生成references/openapi.md
单元测试、端到端测试、测试模块、模拟references/testing.md
配置、ConfigModule、环境变量验证references/config.md
中间件、生命周期钩子、关闭流程references/middleware.md
使用 pino 或内置记录器进行日志记录references/logging.md
健康检查、Terminusreferences/health.md
CQRS、事件、Sagareferences/cqrs.md
调度、Cron 作业、定时任务references/scheduling.md
Docker、部署、生产环境设置references/docker.md

多个任务？阅读多个文件。参考资料均可独立使用。

成功标准：仅采用与任务相关的 NestJS 约定。

步骤 2：遵循 NestJS 的核心规范实施

遵守以下规则：

  • 每个模块都要显式声明其控制器、提供者、导入和导出
  • 控制器通过 DTO 和 ValidationPipe 进行验证，委托给服务，并返回类型明确的响应
  • 服务包含业务逻辑，通过构造函数注入 — 绝不使用 new 实例化
  • 实体/模型与 DTO 分开 — 绝不从控制器返回原始实体
  • 守卫处理身份验证/授权，拦截器处理横切关注点，管道处理转换
  • 所有外部输入都必须使用带有 class-validator 装饰器的 DTO
  • 在原子性至关重要时，将数据库变更封装在事务中
  • 使用 @nestjs/config，并通过 Zod 或 Joi 验证环境变量

成功标准：此变更符合项目的 NestJS 模块架构，而不是绕过框架。

步骤 3：验证受影响的范围

使用范围最窄且相关的验证方式：

  • 单元测试（jest --testPathPattern=<module>）
  • 端到端测试（jest --config test/jest-e2e.json）
  • 类型检查（tsc --noEmit）
  • lint 检查（eslint .）
  • 如果装饰器有变更，则重新生成 OpenAPI 规范

成功标准：变更后的 NestJS 范围仍可构建、通过类型检查和测试。

规范

  • 不要将整本 NestJS 手册内联到 SKILL.md 中。
  • 不要跳过 references/stack.md。
  • 不要在控制器中编写业务逻辑 — 应委托给服务。
  • 不要返回原始实体 — 应使用 DTO 或序列化拦截器。
  • 不要绕过依赖注入 — 绝不使用 new Service()。
  • 不要在未穷尽其他替代方案前创建循环模块依赖。
  • 不要使用 @nestjs/common 的聚合导入来导入类型 — 尽可能从特定子路径导入。
  • 不要添加 disable-model-invocation；这是一个常规领域技能。

何时加载参考资料

  • references/stack.md 始终加载。

  • 然后仅加载 references/ 下与任务相关的文件

输出要求

报告：

  1. 加载了哪些 NestJS 参考资料
  2. 选择的模块和架构模式
  3. 所做的变更
  4. 运行的验证

评论

支持 Markdown