nestjs-patterns — скилл для Claude Code: что делает и как установить
Скилл задаёт архитектурные правила для бэкендов на NestJS и TypeScript: от структуры каталогов до валидации DTO и тестов.
npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-codeЧто делает nestjs-patterns
Скилл содержит набор шаблонов проектирования для NestJS-приложений. Он регламентирует разделение кода на функциональные модули, вынос общей логики в директорию common/ и хранение DTO рядом с сервисами. Контроллеры остаются тонкими: они лишь принимают HTTP-запросы и передают управление провайдерам, а бизнес-логика изолируется в сервисах.
Внутри собраны правила настройки глобального пайпа валидации через class-validator, централизованные фильтры исключений, гарды доступа и перехватчики сериализации. Для работы с базами через Prisma или TypeORM скилл требует выносить транзакции в сервисы, а переменные окружения валидировать сразу при запуске через ConfigModule.
Ставить его нужно, если вы создаёте или ревьюите серверный TypeScript-код и хотите единую дисциплину слоёв без каши в контроллерах.
Какие задачи решает
- организовать структуру каталогов и модулей в проекте NestJS
- настроить сквозную валидацию входящих запросов через DTO и class-validator
- унифицировать формат ответов об ошибках через HttpExceptionFilter
- изолировать транзакции Prisma или TypeORM внутри доменных сервисов
Примеры запросов агенту
- «Спроектируй модуль users для NestJS с контроллером, сервисом и DTO валидацией по правилам nestjs-patterns»
- «Проверь мой main.ts и настрой глобальный ValidationPipe с белым списком полей»
- «Напиши юнит-тест для UsersController с изоляцией зависимостей через Test.createTestingModule»
Как установить nestjs-patterns
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-code2Вручную: положить файлы
~/.claude/skills/nestjs-patterns/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/nestjs-patterns/
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a codex2Вручную: положить файлы
.agents/skills/nestjs-patterns/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a cursor2Вручную: положить файлы
.cursor/skills/nestjs-patterns/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC nestjs-patterns2Вручную: положить файлы
.github/skills/nestjs-patterns/SKILL.md1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a gemini-cli2Командой платформы
gemini skills install https://github.com/affaan-m/ECC --path skills/nestjs-patternsВручную: положить файлы
.devin/skills/nestjs-patterns/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill nestjs-patterns -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
Из того же набора146
Весь набор →Похожие
Вопросы о nestjs-patterns
Как установить nestjs-patterns в Claude Code?
Выполните команду npx skills add affaan-m/ECC --skill nestjs-patterns -a claude-code в терминале. Файл сохранится в каталоге ~/.claude/skills/nestjs-patterns/SKILL.md.
Что делает скилл nestjs-patterns?
Он задаёт стандарты архитектуры NestJS: тонкие контроллеры, строгая валидация входящих DTO, модульные гарды и безопасная работа с конфигурацией при старте.
Как по этим правилам обрабатываются ошибки API?
Все исключения перехватываются фильтром HttpExceptionFilter, который возвращает клиенту единый формат ответа со статусом, путём запроса и телом ошибки.
Исходный текст
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