NestJS Monorepo Architecture Assistant

An AI coding assistant specialized for NestJS monorepo projects using TypeORM, GraphQL, RabbitMQ, and microservices architecture. This skill helps you navigate the codebase, understand architectural patterns, execute developer workflows, and maintain code quality standards.

What This Skill Does

This skill provides expert assistance for working with NestJS monorepo projects by:

Instructions

1. Understand the Monorepo Architecture

**BEFORE making any code changes or creating documentation:**

**Key integrations to be aware of:**

2. Use Path Aliases Correctly

**Always use the established path alias patterns:**

3. Developer Workflows

**Provide correct commands for common tasks:**

```bash

Development

npm install # Install dependencies

npm run start:dev # Local development with watch mode

Production

npm run build # Build for production

npm run start:prod # Run production build

Docker

docker compose up -d # Start services

Database Operations

npm run migration:generate -- <Name> # Generate TypeORM migration

npm run migration:run # Run migrations (dev)

npm run migration:run:prod # Run migrations (production)

npm run seed # Run database seeds (dev)

npm run seed:prod # Run database seeds (production)

Testing

npm run test # Unit tests

npm run test:watch # Unit tests in watch mode

npm run test:e2e # End-to-end tests

Code Quality

npm run lint # Run linter

npm run format # Format code

```

4. CRITICAL: Verify Before Creating Code or Documentation

**NEVER add properties, methods, or enums that don't exist in the actual codebase.**

**Before creating any diagram, documentation, or code changes:**

1. **Read the actual source files:**

- For entities: Check `libs/database/src/entities/` for actual properties and relationships

- For enums: Check `libs/shared/src/enums/` for exact enum values

- For services: Check `apps/api-gateway/src/services/` for actual methods

- For DTOs: Check `libs/shared/src/dtos/` for actual validation rules and fields

- For resolvers: Check `apps/api-gateway/src/resolvers/` for GraphQL schema

- For controllers: Check `apps/api-gateway/src/controllers/` for REST endpoints

2. **Use ONLY what actually exists:**

- Don't invent enum values (e.g., `CourseLearningFormat.HYBRID` if only INDIVIDUAL and GROUP exist)

- Don't add non-existent entity fields (e.g., `maxCapacity` if not in the entity)

- Don't reference methods that aren't implemented in services

- Don't assume status values (e.g., check actual `EnrollmentStatus` enum values)

3. **If proposing new features:**

- Clearly mark proposed additions as "NEW - not yet in codebase"

- Distinguish between what exists and what you're proposing

- Cross-reference with actual usage in services and controllers

5. Follow Code Conventions

**Exception Handling:**

**Logging:**

**Validation:**

**GraphQL:**

**Microservices:**

6. Making Common Changes

**Adding new API endpoints or GraphQL resolvers:**

**Adding shared utilities or DTOs:**

**Database changes:**

**Configuration changes:**

**Adding new libraries to monorepo:**

7. Pre-PR Checklist

**Before submitting code changes:**

1. **Build verification:**

- Run `npm run build` to ensure TypeScript compiles

- Fix any compilation errors

2. **Testing:**

- Run `npm run test` for unit tests

- Run `npm run test:e2e` for integration tests where applicable

- Ensure new code has appropriate test coverage

3. **Database changes:**

- Include generated TypeORM migration files

- Verify `npm run migration:generate` is reproducible

- Test migration with `npm run migration:run` in development

4. **Code quality:**

- Run `npm run lint` and fix any linting issues

- Run `npm run format` to ensure consistent formatting

5. **Codebase accuracy:**

- Verify all referenced entities, enums, and methods actually exist

- Ensure imports use correct `@app/*` aliases

- Follow established patterns from existing code

Examples

Example 1: Adding a New GraphQL Resolver

**Steps:**

1. Read existing resolvers in `apps/api-gateway/src/resolvers` to understand patterns

2. Create new resolver file following established naming conventions

3. Use `@app/shared` for DTOs and `@app/database` for entities

4. Implement resolver methods with proper error handling using `CustomRpcException`

5. Register resolver in `AppModule` at `apps/api-gateway/src/app.module.ts`

6. Run `npm run test` and `npm run build` to verify

Example 2: Adding a Database Entity

**Steps:**

1. Create entity class in `libs/database/src/entities`

2. Use TypeORM decorators following patterns from existing entities

3. Read `libs/shared/src/enums` to use only existing enum values

4. Generate migration: `npm run migration:generate -- AddNewEntity`

5. Review generated migration file in `libs/database/src/migrations`

6. Test migration: `npm run migration:run`

7. Update any affected DTOs in `libs/shared/src/dtos`

Example 3: Verifying Code Accuracy

**Before creating documentation:**

1. Read actual entity file: `libs/database/src/entities/session.entity.ts`

2. Verify actual enum values: `libs/shared/src/enums/enrollment-status.enum.ts`

3. Check service implementation: `apps/api-gateway/src/services/enrollment.service.ts`

4. Use ONLY properties and methods that exist in these files

5. Mark any proposed additions clearly as "NEW - not yet in codebase"

Important Notes