smithery.ai

nestjs

Provides NestJS framework development standards and architectural patterns. Ensures domain-centric architecture, proper dependency injection, and decorator pattern utilization. Specializes in modular design, providers and services, middleware and guards, interceptors and pipes, custom decorators, and microservices architecture. Use when: developing NestJS applications, designing module structure (@Module), creating controllers (@Controller) and services (@Injectable), implementing REST or Graph…

First seen Mar 15, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,216 B
  • docs SUMMARY.md 752 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 20 installs

SKILL.md

NestJS Development Standards

Module Organization Principles

Domain-Centric Modularization

Organize modules by business domain, not by function.

  • ❌ Bad: controllers/, services/, repositories/
  • ✅ Good: users/, products/, orders/

Single Responsibility Module

Each module is responsible for only one domain.

  • Separate common functionality into common/ or shared/ modules
  • Inter-domain communication must go through Services only

Dependency Injection Rules

Constructor Injection Only

Property injection (@Inject) is forbidden.

// ✅ Good
constructor(private readonly userService: UserService) {}

// ❌ Bad
@Inject() userService: UserService;

Provider Registration Location

Providers are registered only in the module where they are used.

  • Minimize global providers
  • Use forRoot/forRootAsync only in AppModule

Decorator Usage Rules

Prioritize Custom Decorators

Abstract repeated decorator combinations into custom decorators.

// Create custom decorator when combining 3+ decorators
@Auth() // Integrates @UseGuards + @ApiBearerAuth + @CurrentUser

Decorator Order

Arrange in execution order from top to bottom.

  1. Metadata decorators (@ApiTags, @Controller, @Resolver)
  2. Guards/Interceptors (@UseGuards, @UseInterceptors)
  3. Route decorators (@Get, @Post, @Query, @Mutation)
  4. Parameter decorators (@Body, @Param, @Args)

DTO/Entity Rules

DTO is Pure Data Transfer

Business logic is forbidden; only validation is allowed.

// ✅ Good: Validation only
class CreateUserDto {
  @IsEmail()
  email: string;
}

// ❌ Bad: Contains business logic
class CreateUserDto {
  toEntity(): User {} // Forbidden
}

Separate Entity and DTO

Never return Entity directly; always convert to DTO.

  • Request: CreateInput, UpdateInput (GraphQL) / CreateDto, UpdateDto (REST)
  • Response: Type definition or plain object

Error Handling

Domain-Specific Exception Filter

Each domain has its own Exception Filter.

@Module({
  providers: [
    {
      provide: APP_FILTER,
      useClass: UserExceptionFilter,
    },
  ],
})

Explicit Error Throwing

Always throw Exception explicitly in all error situations.

  • REST: Use HttpException series
  • GraphQL: Use GraphQLError or custom error
  • Forbid implicit null/undefined returns
  • Error messages should be understandable by users