{"owner":"brocoders","repo":"nestjs-boilerplate","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":2146,"categories":["anthropic-skill","claude-rule","project-spec"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/generate/SKILL.md","CLAUDE.md","docs/architecture.md"],"skills":{".claude/skills/generate/SKILL.md":"---\nname: generate\ndescription: Add entities/schemas and properties to existing entities via this project's CLI generators (npm run generate:resource:*, npm run add:property:to-*). Use when adding a new entity, a new schema, or a new property to an existing entity/schema in this NestJS boilerplate.\n---\n\n# Generate Entities and Properties\n\n## Detect the database variant\n\nBefore running any command, grep `package.json` `scripts` to determine `{db}`:\n\n- `generate:resource:all-db` present → `{db}` = `all-db` (PostgreSQL + MongoDB).\n- `generate:resource:relational` present (and no `all-db`) → `{db}` = `relational` (PostgreSQL/TypeORM).\n- `generate:resource:document` present (and no `all-db`) → `{db}` = `document` (MongoDB).\n\nDo not ask the user — whichever `generate:resource:*` and `add:property:to-*` scripts remain in `package.json` are exactly the right ones to run.\n\n## Add an entity/schema\n\n**Rules:**\n- **Never generate `User` or `File` entities** — they already exist. You can reference them in relationships.\n- Entity names must be PascalCase and singular (e.g., `Post`, `Category`, `BlogComment`).\n\n**Command:**\n\n```bash\nnpm run generate:resource:{db} -- --name {EntityName}\n```\n\n`{db}` comes from the detection section above.\n\nRun sequentially, one entity at a time.\n\n## Add a property to an entity/schema\n\n**Rules:**\n- **Never add `id`, `createdAt`, or `updatedAt`** — these are predefined for all entities.\n- Property names must be camelCase (e.g., `firstName`, `isActive`).\n\n**Property kinds:**\n- `primitive` — basic types: `string`, `number`, `boolean`, `Date`\n- `reference` — relationship to another entity\n- `denormalized` — denormalized copy of another entity's data (stored inline instead of referenced)\n\n**Relationship rules:**\n- When creating a property with `referenceType: \"oneToMany\"`, **do NOT** create the corresponding `manyToOne` in the referenced entity — the generator creates it automatically.\n- **Do NOT create `oneToMany`** if the `propertyInReference` could have many items. Instead, create a `manyToOne` on the child entity only.\n- For **File** relations, use only `oneToOne` or `manyToMany`.\n- `propertyInReference` is only required when `referenceType` is `oneToMany`.\n\n**Command:**\n\n```bash\nnpm run add:property:to-{db} -- --name {EntityName} --property {propertyName} --kind {kind} --type {type} --referenceType {referenceType} --propertyInReference {propertyInReference} --isAddToDto {isAddToDto} --isOptional {isOptional} --isNullable {isNullable} --shouldAutoLoad {shouldAutoLoad}\n```\n\n**Argument rules:**\n- `--name` (required): Entity name, PascalCase\n- `--property` (required): Property name, camelCase\n- `--kind` (required): `primitive` | `reference` | `denormalized`\n- `--type` (required): For primitive: `string` | `number` | `boolean` | `Date`. For reference/denormalized: the referenced entity name (e.g., `User`, `File`, `Category`)\n- `--referenceType`: Only for reference/denormalized kind. Values: `oneToOne` | `oneToMany` | `manyToOne` | `manyToMany`\n- `--propertyInReference`: Only when `referenceType` is `oneToMany`. The property name on the referenced entity.\n- `--isAddToDto`: `true` | `false` — whether the property can be set via HTTP request\n- `--isOptional`: `true` | `false`\n- `--isNullable`: `true` | `false` — only meaningful when `isOptional` is `true`\n- `--shouldAutoLoad`: `true` (default) | `false`. Only meaningful for `kind=reference`. `true` emits `eager: true` (TypeORM) and `autopopulate: true` (Mongoose). `false` stores only the related entity's id (Mongoose: `string` field + ObjectId; TypeORM: `eager: false`). No effect for `primitive`/`denormalized`.\n\n**Omit arguments that don't apply** (e.g., omit `--referenceType` for primitive properties, omit `--propertyInReference` unless `referenceType` is `oneToMany`).\n\nRun sequentially, one property at a time.\n","CLAUDE.md":"# Project instructions\n\nNestJS boilerplate supporting both relational (TypeORM/PostgreSQL) and document (Mongoose/MongoDB) persistence.\n\n## When adding entities, schemas, or properties\n\nUse the `generate` skill (auto-loaded from [.claude/skills/generate/SKILL.md](.claude/skills/generate/SKILL.md)). It documents the project's CLI generators (`npm run generate:resource:*`, `npm run add:property:to-*`) which keep both database variants, DTOs, modules, and migrations in sync. Do not hand-write entity files.\n","docs/architecture.md":"# Architecture\n\n---\n\n## Table of Contents <!-- omit in toc -->\n\n- [Hexagonal Architecture](#hexagonal-architecture)\n- [Motivation](#motivation)\n- [Description of the module structure](#description-of-the-module-structure)\n- [Recommendations](#recommendations)\n  - [Repository](#repository)\n- [FAQ](#faq)\n  - [Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?](#is-there-a-way-to-generate-a-new-resource-controller-service-dtos-etc-with-hexagonal-architecture)\n- [Links](#links)\n\n---\n\n## Hexagonal Architecture\n\nNestJS Boilerplate is based on [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)). This architecture is also known as Ports and Adapters.\n\n![Hexagonal Architecture Diagram](https://github.com/brocoders/nestjs-boilerplate/assets/6001723/6a6a763e-d1c9-43cc-910a-617cda3a71db)\n\n## Motivation\n\nThe main reason for using Hexagonal Architecture is to separate the business logic from the infrastructure. This separation allows us to easily change the database, the way of uploading files, or any other infrastructure without changing the business logic.\n\n## Description of the module structure\n\n```txt\n.\n├── domain\n│   └── [DOMAIN_ENTITY].ts\n├── dto\n│   ├── create.dto.ts\n│   ├── find-all.dto.ts\n│   └── update.dto.ts\n├── infrastructure\n│   └── persistence\n│       ├── document\n│       │   ├── document-persistence.module.ts\n│       │   ├── entities\n│       │   │   └── [SCHEMA].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       ├── relational\n│       │   ├── entities\n│       │   │   └── [ENTITY].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   ├── relational-persistence.module.ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       └── [PORT].repository.ts\n├── controller.ts\n├── module.ts\n└── service.ts\n```\n\n`[DOMAIN ENTITY].ts` represents an entity used in the business logic. Domain entity has no dependencies on the database or any other infrastructure.\n\n`[SCHEMA].ts` represents the **database structure**. It is used in the document-oriented database (MongoDB).\n\n`[ENTITY].ts` represents the **database structure**. It is used in the relational database (PostgreSQL).\n\n`[MAPPER].ts` is a mapper that converts **database entity** to **domain entity** and vice versa.\n\n`[PORT].repository.ts` is a repository **port** that defines the methods for interacting with the database.\n\n`[ADAPTER].repository.ts` is a repository that implements the `[PORT].repository.ts`. It is used to interact with the database.\n\n`infrastructure` folder - contains all the infrastructure-related components such as `persistence`, `uploader`, `senders`, etc.\n\nEach component has `port` and `adapters`. `Port` is interface that define the methods for interacting with the infrastructure. `Adapters` are implementations of the `port`.\n\n## Recommendations\n\n### Repository\n\nDon't try to create universal methods in the repository because they are difficult to extend during the project's life. Instead of this create methods with a single responsibility.\n\n```typescript\n// ❌\nexport class UsersRelationalRepository implements UserRepository {\n  async find(condition: UniversalConditionInterface): Promise<User> {\n    // ...\n  }\n}\n\n// ✅\nexport class UsersRelationalRepository implements UserRepository {\n  async findByEmail(email: string): Promise<User> {\n    // ...\n  }\n  \n  async findByRoles(roles: string[]): Promise<User> {\n    // ...\n  }\n  \n  async findByIds(ids: string[]): Promise<User> {\n    // ...\n  }\n}\n```\n\n---\n\n## FAQ\n\n### Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?\n\nYes, you can use the [CLI](cli.md) to generate a new resource with Hexagonal Architecture.\n\n---\n\n## Links\n\n- [Dependency Inversion Principle](https://trilon.io/blog/dependency-inversion-principle) with NestJS.\n\n---\n\nPrevious: [Installing and Running](installing-and-running.md)\n\nNext: [Command Line Interface](cli.md)\n"},"files":{".claude/skills/generate/SKILL.md":"---\nname: generate\ndescription: Add entities/schemas and properties to existing entities via this project's CLI generators (npm run generate:resource:*, npm run add:property:to-*). Use when adding a new entity, a new schema, or a new property to an existing entity/schema in this NestJS boilerplate.\n---\n\n# Generate Entities and Properties\n\n## Detect the database variant\n\nBefore running any command, grep `package.json` `scripts` to determine `{db}`:\n\n- `generate:resource:all-db` present → `{db}` = `all-db` (PostgreSQL + MongoDB).\n- `generate:resource:relational` present (and no `all-db`) → `{db}` = `relational` (PostgreSQL/TypeORM).\n- `generate:resource:document` present (and no `all-db`) → `{db}` = `document` (MongoDB).\n\nDo not ask the user — whichever `generate:resource:*` and `add:property:to-*` scripts remain in `package.json` are exactly the right ones to run.\n\n## Add an entity/schema\n\n**Rules:**\n- **Never generate `User` or `File` entities** — they already exist. You can reference them in relationships.\n- Entity names must be PascalCase and singular (e.g., `Post`, `Category`, `BlogComment`).\n\n**Command:**\n\n```bash\nnpm run generate:resource:{db} -- --name {EntityName}\n```\n\n`{db}` comes from the detection section above.\n\nRun sequentially, one entity at a time.\n\n## Add a property to an entity/schema\n\n**Rules:**\n- **Never add `id`, `createdAt`, or `updatedAt`** — these are predefined for all entities.\n- Property names must be camelCase (e.g., `firstName`, `isActive`).\n\n**Property kinds:**\n- `primitive` — basic types: `string`, `number`, `boolean`, `Date`\n- `reference` — relationship to another entity\n- `denormalized` — denormalized copy of another entity's data (stored inline instead of referenced)\n\n**Relationship rules:**\n- When creating a property with `referenceType: \"oneToMany\"`, **do NOT** create the corresponding `manyToOne` in the referenced entity — the generator creates it automatically.\n- **Do NOT create `oneToMany`** if the `propertyInReference` could have many items. Instead, create a `manyToOne` on the child entity only.\n- For **File** relations, use only `oneToOne` or `manyToMany`.\n- `propertyInReference` is only required when `referenceType` is `oneToMany`.\n\n**Command:**\n\n```bash\nnpm run add:property:to-{db} -- --name {EntityName} --property {propertyName} --kind {kind} --type {type} --referenceType {referenceType} --propertyInReference {propertyInReference} --isAddToDto {isAddToDto} --isOptional {isOptional} --isNullable {isNullable} --shouldAutoLoad {shouldAutoLoad}\n```\n\n**Argument rules:**\n- `--name` (required): Entity name, PascalCase\n- `--property` (required): Property name, camelCase\n- `--kind` (required): `primitive` | `reference` | `denormalized`\n- `--type` (required): For primitive: `string` | `number` | `boolean` | `Date`. For reference/denormalized: the referenced entity name (e.g., `User`, `File`, `Category`)\n- `--referenceType`: Only for reference/denormalized kind. Values: `oneToOne` | `oneToMany` | `manyToOne` | `manyToMany`\n- `--propertyInReference`: Only when `referenceType` is `oneToMany`. The property name on the referenced entity.\n- `--isAddToDto`: `true` | `false` — whether the property can be set via HTTP request\n- `--isOptional`: `true` | `false`\n- `--isNullable`: `true` | `false` — only meaningful when `isOptional` is `true`\n- `--shouldAutoLoad`: `true` (default) | `false`. Only meaningful for `kind=reference`. `true` emits `eager: true` (TypeORM) and `autopopulate: true` (Mongoose). `false` stores only the related entity's id (Mongoose: `string` field + ObjectId; TypeORM: `eager: false`). No effect for `primitive`/`denormalized`.\n\n**Omit arguments that don't apply** (e.g., omit `--referenceType` for primitive properties, omit `--propertyInReference` unless `referenceType` is `oneToMany`).\n\nRun sequentially, one property at a time.\n","CLAUDE.md":"# Project instructions\n\nNestJS boilerplate supporting both relational (TypeORM/PostgreSQL) and document (Mongoose/MongoDB) persistence.\n\n## When adding entities, schemas, or properties\n\nUse the `generate` skill (auto-loaded from [.claude/skills/generate/SKILL.md](.claude/skills/generate/SKILL.md)). It documents the project's CLI generators (`npm run generate:resource:*`, `npm run add:property:to-*`) which keep both database variants, DTOs, modules, and migrations in sync. Do not hand-write entity files.\n","docs/architecture.md":"# Architecture\n\n---\n\n## Table of Contents <!-- omit in toc -->\n\n- [Hexagonal Architecture](#hexagonal-architecture)\n- [Motivation](#motivation)\n- [Description of the module structure](#description-of-the-module-structure)\n- [Recommendations](#recommendations)\n  - [Repository](#repository)\n- [FAQ](#faq)\n  - [Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?](#is-there-a-way-to-generate-a-new-resource-controller-service-dtos-etc-with-hexagonal-architecture)\n- [Links](#links)\n\n---\n\n## Hexagonal Architecture\n\nNestJS Boilerplate is based on [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)). This architecture is also known as Ports and Adapters.\n\n![Hexagonal Architecture Diagram](https://github.com/brocoders/nestjs-boilerplate/assets/6001723/6a6a763e-d1c9-43cc-910a-617cda3a71db)\n\n## Motivation\n\nThe main reason for using Hexagonal Architecture is to separate the business logic from the infrastructure. This separation allows us to easily change the database, the way of uploading files, or any other infrastructure without changing the business logic.\n\n## Description of the module structure\n\n```txt\n.\n├── domain\n│   └── [DOMAIN_ENTITY].ts\n├── dto\n│   ├── create.dto.ts\n│   ├── find-all.dto.ts\n│   └── update.dto.ts\n├── infrastructure\n│   └── persistence\n│       ├── document\n│       │   ├── document-persistence.module.ts\n│       │   ├── entities\n│       │   │   └── [SCHEMA].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       ├── relational\n│       │   ├── entities\n│       │   │   └── [ENTITY].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   ├── relational-persistence.module.ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       └── [PORT].repository.ts\n├── controller.ts\n├── module.ts\n└── service.ts\n```\n\n`[DOMAIN ENTITY].ts` represents an entity used in the business logic. Domain entity has no dependencies on the database or any other infrastructure.\n\n`[SCHEMA].ts` represents the **database structure**. It is used in the document-oriented database (MongoDB).\n\n`[ENTITY].ts` represents the **database structure**. It is used in the relational database (PostgreSQL).\n\n`[MAPPER].ts` is a mapper that converts **database entity** to **domain entity** and vice versa.\n\n`[PORT].repository.ts` is a repository **port** that defines the methods for interacting with the database.\n\n`[ADAPTER].repository.ts` is a repository that implements the `[PORT].repository.ts`. It is used to interact with the database.\n\n`infrastructure` folder - contains all the infrastructure-related components such as `persistence`, `uploader`, `senders`, etc.\n\nEach component has `port` and `adapters`. `Port` is interface that define the methods for interacting with the infrastructure. `Adapters` are implementations of the `port`.\n\n## Recommendations\n\n### Repository\n\nDon't try to create universal methods in the repository because they are difficult to extend during the project's life. Instead of this create methods with a single responsibility.\n\n```typescript\n// ❌\nexport class UsersRelationalRepository implements UserRepository {\n  async find(condition: UniversalConditionInterface): Promise<User> {\n    // ...\n  }\n}\n\n// ✅\nexport class UsersRelationalRepository implements UserRepository {\n  async findByEmail(email: string): Promise<User> {\n    // ...\n  }\n  \n  async findByRoles(roles: string[]): Promise<User> {\n    // ...\n  }\n  \n  async findByIds(ids: string[]): Promise<User> {\n    // ...\n  }\n}\n```\n\n---\n\n## FAQ\n\n### Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?\n\nYes, you can use the [CLI](cli.md) to generate a new resource with Hexagonal Architecture.\n\n---\n\n## Links\n\n- [Dependency Inversion Principle](https://trilon.io/blog/dependency-inversion-principle) with NestJS.\n\n---\n\nPrevious: [Installing and Running](installing-and-running.md)\n\nNext: [Command Line Interface](cli.md)\n"},"items":[{"name":"architecture.md","path":"docs/architecture.md","rawUrl":"https://raw.githubusercontent.com/brocoders/nestjs-boilerplate/HEAD/docs/architecture.md","title":"docs - System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# Architecture\n\n---\n\n## Table of Contents <!-- omit in toc -->\n\n- [Hexagonal Architecture](#hexagonal-architecture)\n- [Motivation](#motivation)\n- [Description of the module structure](#description-of-the-module-structure)\n- [Recommendations](#recommendations)\n  - [Repository](#repository)\n- [FAQ](#faq)\n  - [Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?](#is-there-a-way-to-generate-a-new-resource-controller-service-dtos-etc-with-hexagonal-architecture)\n- [Links](#links)\n\n---\n\n## Hexagonal Architecture\n\nNestJS Boilerplate is based on [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)). This architecture is also known as Ports and Adapters.\n\n![Hexagonal Architecture Diagram](https://github.com/brocoders/nestjs-boilerplate/assets/6001723/6a6a763e-d1c9-43cc-910a-617cda3a71db)\n\n## Motivation\n\nThe main reason for using Hexagonal Architecture is to separate the business logic from the infrastructure. This separation allows us to easily change the database, the way of uploading files, or any other infrastructure without changing the business logic.\n\n## Description of the module structure\n\n```txt\n.\n├── domain\n│   └── [DOMAIN_ENTITY].ts\n├── dto\n│   ├── create.dto.ts\n│   ├── find-all.dto.ts\n│   └── update.dto.ts\n├── infrastructure\n│   └── persistence\n│       ├── document\n│       │   ├── document-persistence.module.ts\n│       │   ├── entities\n│       │   │   └── [SCHEMA].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       ├── relational\n│       │   ├── entities\n│       │   │   └── [ENTITY].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   ├── relational-persistence.module.ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       └── [PORT].repository.ts\n├── controller.ts\n├── module.ts\n└── service.ts\n```\n\n`[DOMAIN ENTITY].ts` represents an entity used in the business logic. Domain entity has no dependencies on the database or any other infrastructure.\n\n`[SCHEMA].ts` represents the **database structure**. It is used in the document-oriented database (MongoDB).\n\n`[ENTITY].ts` represents the **database structure**. It is used in the relational database (PostgreSQL).\n\n`[MAPPER].ts` is a mapper that converts **database entity** to **domain entity** and vice versa.\n\n`[PORT].repository.ts` is a repository **port** that defines the methods for interacting with the database.\n\n`[ADAPTER].repository.ts` is a repository that implements the `[PORT].repository.ts`. It is used to interact with the database.\n\n`infrastructure` folder - contains all the infrastructure-related components such as `persistence`, `uploader`, `senders`, etc.\n\nEach component has `port` and `adapters`. `Port` is interface that define the methods for interacting with the infrastructure. `Adapters` are implementations of the `port`.\n\n## Recommendations\n\n### Repository\n\nDon't try to create universal methods in the repository because they are difficult to extend during the project's life. Instead of this create methods with a single responsibility.\n\n```typescript\n// ❌\nexport class UsersRelationalRepository implements UserRepository {\n  async find(condition: UniversalConditionInterface): Promise<User> {\n    // ...\n  }\n}\n\n// ✅\nexport class UsersRelationalRepository implements UserRepository {\n  async findByEmail(email: string): Promise<User> {\n    // ...\n  }\n  \n  async findByRoles(roles: string[]): Promise<User> {\n    // ...\n  }\n  \n  async findByIds(ids: string[]): Promise<User> {\n    // ...\n  }\n}\n```\n\n---\n\n## FAQ\n\n### Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?\n\nYes, you can use the [CLI](cli.md) to generate a new resource with Hexagonal Architecture.\n\n---\n\n## Links\n\n- [Dependency Inversion Principle](https://trilon.io/blog/dependency-inversion-principle) with NestJS.\n\n---\n\nPrevious: [Installing and Running](installing-and-running.md)\n\nNext: [Command Line Interface](cli.md)\n","isInternal":false,"tokens":1009,"sizeBytes":4327},{"name":"SKILL.md","path":".claude/skills/generate/SKILL.md","rawUrl":"https://raw.githubusercontent.com/brocoders/nestjs-boilerplate/HEAD/.claude/skills/generate/SKILL.md","title":"generate","category":"anthropic-skill","format":"markdown","content":"---\nname: generate\ndescription: Add entities/schemas and properties to existing entities via this project's CLI generators (npm run generate:resource:*, npm run add:property:to-*). Use when adding a new entity, a new schema, or a new property to an existing entity/schema in this NestJS boilerplate.\n---\n\n# Generate Entities and Properties\n\n## Detect the database variant\n\nBefore running any command, grep `package.json` `scripts` to determine `{db}`:\n\n- `generate:resource:all-db` present → `{db}` = `all-db` (PostgreSQL + MongoDB).\n- `generate:resource:relational` present (and no `all-db`) → `{db}` = `relational` (PostgreSQL/TypeORM).\n- `generate:resource:document` present (and no `all-db`) → `{db}` = `document` (MongoDB).\n\nDo not ask the user — whichever `generate:resource:*` and `add:property:to-*` scripts remain in `package.json` are exactly the right ones to run.\n\n## Add an entity/schema\n\n**Rules:**\n- **Never generate `User` or `File` entities** — they already exist. You can reference them in relationships.\n- Entity names must be PascalCase and singular (e.g., `Post`, `Category`, `BlogComment`).\n\n**Command:**\n\n```bash\nnpm run generate:resource:{db} -- --name {EntityName}\n```\n\n`{db}` comes from the detection section above.\n\nRun sequentially, one entity at a time.\n\n## Add a property to an entity/schema\n\n**Rules:**\n- **Never add `id`, `createdAt`, or `updatedAt`** — these are predefined for all entities.\n- Property names must be camelCase (e.g., `firstName`, `isActive`).\n\n**Property kinds:**\n- `primitive` — basic types: `string`, `number`, `boolean`, `Date`\n- `reference` — relationship to another entity\n- `denormalized` — denormalized copy of another entity's data (stored inline instead of referenced)\n\n**Relationship rules:**\n- When creating a property with `referenceType: \"oneToMany\"`, **do NOT** create the corresponding `manyToOne` in the referenced entity — the generator creates it automatically.\n- **Do NOT create `oneToMany`** if the `propertyInReference` could have many items. Instead, create a `manyToOne` on the child entity only.\n- For **File** relations, use only `oneToOne` or `manyToMany`.\n- `propertyInReference` is only required when `referenceType` is `oneToMany`.\n\n**Command:**\n\n```bash\nnpm run add:property:to-{db} -- --name {EntityName} --property {propertyName} --kind {kind} --type {type} --referenceType {referenceType} --propertyInReference {propertyInReference} --isAddToDto {isAddToDto} --isOptional {isOptional} --isNullable {isNullable} --shouldAutoLoad {shouldAutoLoad}\n```\n\n**Argument rules:**\n- `--name` (required): Entity name, PascalCase\n- `--property` (required): Property name, camelCase\n- `--kind` (required): `primitive` | `reference` | `denormalized`\n- `--type` (required): For primitive: `string` | `number` | `boolean` | `Date`. For reference/denormalized: the referenced entity name (e.g., `User`, `File`, `Category`)\n- `--referenceType`: Only for reference/denormalized kind. Values: `oneToOne` | `oneToMany` | `manyToOne` | `manyToMany`\n- `--propertyInReference`: Only when `referenceType` is `oneToMany`. The property name on the referenced entity.\n- `--isAddToDto`: `true` | `false` — whether the property can be set via HTTP request\n- `--isOptional`: `true` | `false`\n- `--isNullable`: `true` | `false` — only meaningful when `isOptional` is `true`\n- `--shouldAutoLoad`: `true` (default) | `false`. Only meaningful for `kind=reference`. `true` emits `eager: true` (TypeORM) and `autopopulate: true` (Mongoose). `false` stores only the related entity's id (Mongoose: `string` field + ObjectId; TypeORM: `eager: false`). No effect for `primitive`/`denormalized`.\n\n**Omit arguments that don't apply** (e.g., omit `--referenceType` for primitive properties, omit `--propertyInReference` unless `referenceType` is `oneToMany`).\n\nRun sequentially, one property at a time.\n","frontmatter":{"name":"generate","description":"Add entities/schemas and properties to existing entities via this project's CLI generators (npm run generate:resource:*, npm run add:property:to-*). Use when adding a new entity, a new schema, or a new property to an existing entity/schema in this NestJS boilerplate."},"isInternal":false,"tokens":1015,"sizeBytes":3865},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/brocoders/nestjs-boilerplate/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Project instructions\n\nNestJS boilerplate supporting both relational (TypeORM/PostgreSQL) and document (Mongoose/MongoDB) persistence.\n\n## When adding entities, schemas, or properties\n\nUse the `generate` skill (auto-loaded from [.claude/skills/generate/SKILL.md](.claude/skills/generate/SKILL.md)). It documents the project's CLI generators (`npm run generate:resource:*`, `npm run add:property:to-*`) which keep both database variants, DTOs, modules, and migrations in sync. Do not hand-write entity files.\n","isInternal":false,"tokens":122,"sizeBytes":509}],"systemPromptSnippet":"<yakaai_skills repo=\"brocoders/nestjs-boilerplate\">\n<!-- File: docs/architecture.md (Tokens: ~1009 | Category: project-spec) -->\n# Architecture\n\n---\n\n## Table of Contents <!-- omit in toc -->\n\n- [Hexagonal Architecture](#hexagonal-architecture)\n- [Motivation](#motivation)\n- [Description of the module structure](#description-of-the-module-structure)\n- [Recommendations](#recommendations)\n  - [Repository](#repository)\n- [FAQ](#faq)\n  - [Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?](#is-there-a-way-to-generate-a-new-resource-controller-service-dtos-etc-with-hexagonal-architecture)\n- [Links](#links)\n\n---\n\n## Hexagonal Architecture\n\nNestJS Boilerplate is based on [Hexagonal Architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)). This architecture is also known as Ports and Adapters.\n\n![Hexagonal Architecture Diagram](https://github.com/brocoders/nestjs-boilerplate/assets/6001723/6a6a763e-d1c9-43cc-910a-617cda3a71db)\n\n## Motivation\n\nThe main reason for using Hexagonal Architecture is to separate the business logic from the infrastructure. This separation allows us to easily change the database, the way of uploading files, or any other infrastructure without changing the business logic.\n\n## Description of the module structure\n\n```txt\n.\n├── domain\n│   └── [DOMAIN_ENTITY].ts\n├── dto\n│   ├── create.dto.ts\n│   ├── find-all.dto.ts\n│   └── update.dto.ts\n├── infrastructure\n│   └── persistence\n│       ├── document\n│       │   ├── document-persistence.module.ts\n│       │   ├── entities\n│       │   │   └── [SCHEMA].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       ├── relational\n│       │   ├── entities\n│       │   │   └── [ENTITY].ts\n│       │   ├── mappers\n│       │   │   └── [MAPPER].ts\n│       │   ├── relational-persistence.module.ts\n│       │   └── repositories\n│       │       └── [ADAPTER].repository.ts\n│       └── [PORT].repository.ts\n├── controller.ts\n├── module.ts\n└── service.ts\n```\n\n`[DOMAIN ENTITY].ts` represents an entity used in the business logic. Domain entity has no dependencies on the database or any other infrastructure.\n\n`[SCHEMA].ts` represents the **database structure**. It is used in the document-oriented database (MongoDB).\n\n`[ENTITY].ts` represents the **database structure**. It is used in the relational database (PostgreSQL).\n\n`[MAPPER].ts` is a mapper that converts **database entity** to **domain entity** and vice versa.\n\n`[PORT].repository.ts` is a repository **port** that defines the methods for interacting with the database.\n\n`[ADAPTER].repository.ts` is a repository that implements the `[PORT].repository.ts`. It is used to interact with the database.\n\n`infrastructure` folder - contains all the infrastructure-related components such as `persistence`, `uploader`, `senders`, etc.\n\nEach component has `port` and `adapters`. `Port` is interface that define the methods for interacting with the infrastructure. `Adapters` are implementations of the `port`.\n\n## Recommendations\n\n### Repository\n\nDon't try to create universal methods in the repository because they are difficult to extend during the project's life. Instead of this create methods with a single responsibility.\n\n```typescript\n// ❌\nexport class UsersRelationalRepository implements UserRepository {\n  async find(condition: UniversalConditionInterface): Promise<User> {\n    // ...\n  }\n}\n\n// ✅\nexport class UsersRelationalRepository implements UserRepository {\n  async findByEmail(email: string): Promise<User> {\n    // ...\n  }\n  \n  async findByRoles(roles: string[]): Promise<User> {\n    // ...\n  }\n  \n  async findByIds(ids: string[]): Promise<User> {\n    // ...\n  }\n}\n```\n\n---\n\n## FAQ\n\n### Is there a way to generate a new resource (controller, service, DTOs, etc) with Hexagonal Architecture?\n\nYes, you can use the [CLI](cli.md) to generate a new resource with Hexagonal Architecture.\n\n---\n\n## Links\n\n- [Dependency Inversion Principle](https://trilon.io/blog/dependency-inversion-principle) with NestJS.\n\n---\n\nPrevious: [Installing and Running](installing-and-running.md)\n\nNext: [Command Line Interface](cli.md)\n\n<!-- File: .claude/skills/generate/SKILL.md (Tokens: ~1015 | Category: anthropic-skill) -->\n---\nname: generate\ndescription: Add entities/schemas and properties to existing entities via this project's CLI generators (npm run generate:resource:*, npm run add:property:to-*). Use when adding a new entity, a new schema, or a new property to an existing entity/schema in this NestJS boilerplate.\n---\n\n# Generate Entities and Properties\n\n## Detect the database variant\n\nBefore running any command, grep `package.json` `scripts` to determine `{db}`:\n\n- `generate:resource:all-db` present → `{db}` = `all-db` (PostgreSQL + MongoDB).\n- `generate:resource:relational` present (and no `all-db`) → `{db}` = `relational` (PostgreSQL/TypeORM).\n- `generate:resource:document` present (and no `all-db`) → `{db}` = `document` (MongoDB).\n\nDo not ask the user — whichever `generate:resource:*` and `add:property:to-*` scripts remain in `package.json` are exactly the right ones to run.\n\n## Add an entity/schema\n\n**Rules:**\n- **Never generate `User` or `File` entities** — they already exist. You can reference them in relationships.\n- Entity names must be PascalCase and singular (e.g., `Post`, `Category`, `BlogComment`).\n\n**Command:**\n\n```bash\nnpm run generate:resource:{db} -- --name {EntityName}\n```\n\n`{db}` comes from the detection section above.\n\nRun sequentially, one entity at a time.\n\n## Add a property to an entity/schema\n\n**Rules:**\n- **Never add `id`, `createdAt`, or `updatedAt`** — these are predefined for all entities.\n- Property names must be camelCase (e.g., `firstName`, `isActive`).\n\n**Property kinds:**\n- `primitive` — basic types: `string`, `number`, `boolean`, `Date`\n- `reference` — relationship to another entity\n- `denormalized` — denormalized copy of another entity's data (stored inline instead of referenced)\n\n**Relationship rules:**\n- When creating a property with `referenceType: \"oneToMany\"`, **do NOT** create the corresponding `manyToOne` in the referenced entity — the generator creates it automatically.\n- **Do NOT create `oneToMany`** if the `propertyInReference` could have many items. Instead, create a `manyToOne` on the child entity only.\n- For **File** relations, use only `oneToOne` or `manyToMany`.\n- `propertyInReference` is only required when `referenceType` is `oneToMany`.\n\n**Command:**\n\n```bash\nnpm run add:property:to-{db} -- --name {EntityName} --property {propertyName} --kind {kind} --type {type} --referenceType {referenceType} --propertyInReference {propertyInReference} --isAddToDto {isAddToDto} --isOptional {isOptional} --isNullable {isNullable} --shouldAutoLoad {shouldAutoLoad}\n```\n\n**Argument rules:**\n- `--name` (required): Entity name, PascalCase\n- `--property` (required): Property name, camelCase\n- `--kind` (required): `primitive` | `reference` | `denormalized`\n- `--type` (required): For primitive: `string` | `number` | `boolean` | `Date`. For reference/denormalized: the referenced entity name (e.g., `User`, `File`, `Category`)\n- `--referenceType`: Only for reference/denormalized kind. Values: `oneToOne` | `oneToMany` | `manyToOne` | `manyToMany`\n- `--propertyInReference`: Only when `referenceType` is `oneToMany`. The property name on the referenced entity.\n- `--isAddToDto`: `true` | `false` — whether the property can be set via HTTP request\n- `--isOptional`: `true` | `false`\n- `--isNullable`: `true` | `false` — only meaningful when `isOptional` is `true`\n- `--shouldAutoLoad`: `true` (default) | `false`. Only meaningful for `kind=reference`. `true` emits `eager: true` (TypeORM) and `autopopulate: true` (Mongoose). `false` stores only the related entity's id (Mongoose: `string` field + ObjectId; TypeORM: `eager: false`). No effect for `primitive`/`denormalized`.\n\n**Omit arguments that don't apply** (e.g., omit `--referenceType` for primitive properties, omit `--propertyInReference` unless `referenceType` is `oneToMany`).\n\nRun sequentially, one property at a time.\n\n<!-- File: CLAUDE.md (Tokens: ~122 | Category: claude-rule) -->\n# Project instructions\n\nNestJS boilerplate supporting both relational (TypeORM/PostgreSQL) and document (Mongoose/MongoDB) persistence.\n\n## When adding entities, schemas, or properties\n\nUse the `generate` skill (auto-loaded from [.claude/skills/generate/SKILL.md](.claude/skills/generate/SKILL.md)). It documents the project's CLI generators (`npm run generate:resource:*`, `npm run add:property:to-*`) which keep both database variants, DTOs, modules, and migrations in sync. Do not hand-write entity files.\n</yakaai_skills>"}