nestjs-patterns — Claude Code skill: what it does, how to install
Architectural guidelines for NestJS backends, covering modular directory layouts, DTO validation, and testing.
npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-codeWhat nestjs-patterns does
The skill outlines production patterns for NestJS applications. It enforces domain feature modules, places cross-cutting decorators, guards, and filters into src/common/, and keeps request DTOs scoped to their owning modules. Controllers stay thin by delegating business logic to injectable providers instead of handling domain operations directly.
It provides setup patterns for global validation pipes with class-validator, unified HttpExceptionFilter error envelopes, and startup environment validation via ConfigModule. Database logic using Prisma or TypeORM is isolated inside domain services so that controllers avoid orchestrating multi-step transactions.
Install this skill when building or auditing NestJS APIs to keep controller boundaries and configuration strict across the codebase.
What it helps with
- structure feature modules and cross-cutting components in NestJS
- enforce strict request validation using DTOs and class-validator
- standardize API error responses with a central HttpExceptionFilter
- isolate Prisma or TypeORM transactions within injectable services
Example prompts for the agent
- Generate a users module with thin controllers and validated DTOs using nestjs-patterns
- Review our main.ts bootstrap logic and apply the recommended global validation pipe
- Write an isolated unit test for UsersService with mocked repositories
How to install nestjs-patterns
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-code2Manually: put the files in place
~/.claude/skills/nestjs-patterns/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/nestjs-patterns/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a codex2Manually: put the files in place
.agents/skills/nestjs-patterns/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a cursor2Manually: put the files in place
.cursor/skills/nestjs-patterns/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC nestjs-patterns2Manually: put the files in place
.github/skills/nestjs-patterns/SKILL.md1Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a gemini-cli2Platform CLI
gemini skills install https://github.com/affaan-m/ECC --path skills/nestjs-patternsManually: put the files in place
.devin/skills/nestjs-patterns/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set146
The whole set →Similar
Questions about nestjs-patterns
How to install nestjs-patterns in Claude Code?
Run npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-code in your terminal. This saves the configuration to ~/.claude/skills/nestjs-patterns/SKILL.md.
What does nestjs-patterns do?
It instructs your agent on NestJS standards: feature module layout, strict DTO validation, thin controllers, centralized filters, and fail-fast environment loading.
How does it manage database transactions?
It requires placing Prisma or TypeORM transactional workflows inside domain services instead of letting controllers coordinate multi-step writes.
Source text
SKILL.md · MIT
---
name: nestjs-patterns
description: NestJS architecture patterns for modules, controllers, providers, DTO validation, guards, interceptors, config, and production-grade TypeScript backends. Use when building or reviewing a NestJS backend — modules, providers, DTO validation, guards, or interceptors.
metadata:
origin: ECC
---
# NestJS Development Patterns
Production-grade NestJS patterns for modular TypeScript backends.
## When to Activate
- Building NestJS APIs or services
- Structuring modules, controllers, and providers
- Adding DTO validation, guards, interceptors, or exception filters
- Configuring environment-aware settings and database integrations
- Testing NestJS units or HTTP endpoints
## Project Structure
```text
src/
├── app.module.ts
├── main.ts
├── common/
│ ├── filters/
│ ├── guards/
│ ├── interceptors/
│ └── pipes/
├── config/
│ ├── configuration.ts
│ └── validation.ts
├── modules/
│ ├── auth/
│ │ ├── auth.controller.ts
│ │ ├── auth.module.ts
│ │ ├── auth.service.ts
│ │ ├── dto/
│ │ ├── guards/
│ │ └── strategies/
│ └── users/
│ ├── dto/
│ ├── entities/
│ ├── users.controller.ts
│ ├── users.module.ts
│ └── users.service.ts
└── prisma/ or database/
```
- Keep domain code inside feature modules.
- Put cross-cutting filters, decorators, guards, and interceptors in `common/`.
- Keep DTOs close to the module that owns them.
## Bootstrap and Global Validation
```ts
async function bootstrap() {
const app = await NestFactory.create(AppModule, { bufferLogs: true });
app.useGlobalPipes(
new ValidationPipe({
whitelist: true,
forbidNonWhitelisted: true,
transform: true,
transformOptions: { enableImplicitConversion: true },
}),
);
app.useGlobalInterceptors(new ClassSerializerInterceptor(app.get(Reflector)));
app.useGlobalFilters(new HttpExceptionFilter());
await app.listen(process.env.PORT ?? 3000);
}
bootstrap();
```
- Always enable `whitelist` and `forbidNonWhitelisted` on public APIs.
- Prefer one global validation pipe instead of repeating validation config per route.
## Modules, Controllers, and Providers
```ts
@Module({
controllers: [UsersController],
providers: [UsersService],
exports: [UsersService],
})
export class UsersModule {}
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}
@Get(':id')
getById(@Param('id', ParseUUIDPipe) id: string) {
return this.usersService.getById(id);
}
@Post()
create(@Body() dto: CreateUserDto) {
return this.usersService.create(dto);
}
}
@Injectable()
export class UsersService {
constructor(private readonly usersRepo: UsersRepository) {}
async create(dto: CreateUserDto) {
return this.usersRepo.create(dto);
}
}
```
- Controllers should stay thin: parse HTTP input, call a provider, return response DTOs.
- Put business logic in injectable services, not controllers.
- Export only the providers other modules genuinely need.
## DTOs and Validation
```ts
export class CreateUserDto {
@IsEmail()
email!: string;
@IsString()
@Length(2, 80)
name!: string;
@IsOptional()
@IsEnum(UserRole)
role?: UserRole;
}
```
- Validate every request DTO with `class-validator`.
- Use dedicated response DTOs or serializers instead of returning ORM entities directly.
- Avoid leaking internal fields such as password hashes, tokens, or audit columns.
## Auth, Guards, and Request Context
```ts
@UseGuards(JwtAuthGuard, RolesGuard)
@Roles('admin')
@Get('admin/report')
getAdminReport(@Req() req: AuthenticatedRequest) {
return this.reportService.getForUser(req.user.id);
}
```
- Keep auth strategies and guards module-local unless they are truly shared.
- Encode coarse access rules in guards, then do resource-specific authorization in services.
- Prefer explicit request types for authenticated request objects.
## Exception Filters and Error Shape
```ts
@Catch()
export class HttpExceptionFilter implements ExceptionFilter {
catch(exception: unknown, host: ArgumentsHost) {
const response = host.switchToHttp().getResponse<Response>();
const request = host.switchToHttp().getRequest<Request>();
if (exception instanceof HttpException) {
return response.status(exception.getStatus()).json({
path: request.url,
error: exception.getResponse(),
});
}
return response.status(500).json({
path: request.url,
error: 'Internal server error',
});
}
}
```
- Keep one consistent error envelope across the API.
- Throw framework exceptions for expected client errors; log and wrap unexpected failures centrally.
## Config and Environment Validation
```ts
ConfigModule.forRoot({
isGlobal: true,
load: [configuration],
validate: validateEnv,
});
```
- Validate env at boot, not lazily at first request.
- Keep config access behind typed helpers or config services.
- Split dev/staging/prod concerns in config factories instead of branching throughout feature code.
## Persistence and Transactions
- Keep repository / ORM code behind providers that speak domain language.
- For Prisma or TypeORM, isolate transactional workflows in services that own the unit of work.
- Do not let controllers coordinate multi-step writes directly.
## Testing
```ts
describe('UsersController', () => {
let app: INestApplication;
beforeAll(async () => {
const moduleRef = await Test.createTestingModule({
imports: [UsersModule],
}).compile();
app = moduleRef.createNestApplication();
app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));
await app.init();
});
});
```
- Unit test providers in isolation with mocked dependencies.
- Add request-level tests for guards, validation pipes, and exception filters.
- Reuse the same global pipes/filters in tests that you use in production.
## Production Defaults
- Enable structured logging and request correlation ids.
- Terminate on invalid env/config instead of booting partially.
- Prefer async provider initialization for DB/cache clients with explicit health checks.
- Keep background jobs and event consumers in their own modules, not inside HTTP controllers.
- Make rate limiting, auth, and audit logging explicit for public endpoints.
© affaan-m · MIT · affaan-m/ECC