How do I install the Nestjs Modules Di skill?

Run npx skillmds@latest add dkmqflx/nestjs-modules-di in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Nestjs Modules Di safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Nestjs Modules Di?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Nestjs Modules Di free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Nestjs Modules Di?

dkmqflx (@dkmqflx) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Nestjs Modules Di by dkmqflx — Agent Skill

Name: Nestjs Modules Di
Author: dkmqflx

Nestjs Modules Di

NestJS module organization and dependency injection best practices. Use when writing or reviewing NestJS modules, providers, or DI wiring. Triggers on @Module, @Injectable, provider registration, injection scopes, dynamic modules, or circular dependencies.

dkmqflx a068817 9 files · 11.5 KB Updated Sep 17, 2026

File contents

NestJS Modules & Dependency Injection

Best-practices reference for organizing NestJS applications into encapsulated feature modules and wiring providers through the IoC container correctly. Covers module boundaries, provider visibility, dynamic modules, injection scopes, custom provider tokens, and circular dependencies.

When to Apply

Designing or reviewing @Module structure and feature boundaries
Registering providers and deciding what to export
Building configurable libraries with forRoot/forRootAsync
Choosing an injection scope (singleton vs REQUEST vs TRANSIENT)
Wiring custom providers (useClass/useValue/useFactory) and injection tokens
Resolving or avoiding circular dependencies
Deciding whether a module should be @Global()

Rules

feature-module-boundaries - one module per feature/domain; keep providers encapsulated
export-shared-providers - only providers listed in exports are visible to importing modules
dynamic-modules-forroot - configure reusable modules via forRoot/forRootAsync returning DynamicModule
injection-scopes-default-singleton - prefer default singleton scope; REQUEST scope bubbles up and hurts performance
custom-provider-tokens - use useClass/useValue/useFactory with injection tokens and interfaces
constructor-injection - prefer constructor injection over property injection
avoid-circular-dependencies - restructure first; use forwardRef only as a last resort
global-module-sparingly - reserve @Global() for truly cross-cutting modules (config, logger)

How to Use

Read individual rule files in rules/ for explanation + incorrect/correct examples.

---name: nestjs-modules-didescription: NestJS module organization and dependency injection best practices. Use when writing or reviewing NestJS modules, providers, or DI wiring. Triggers on @Module, @Injectable, provider registration, injection scopes, dynamic modules, or circular dependencies.license: MIT---# NestJS Modules & Dependency InjectionBest-practices reference for organizing NestJS applications into encapsulated feature modules and wiring providers through the IoC container correctly. Covers module boundaries, provider visibility, dynamic modules, injection scopes, custom provider tokens, and circular dependencies.## When to Apply- Designing or reviewing `@Module` structure and feature boundaries- Registering providers and deciding what to `export`- Building configurable libraries with `forRoot`/`forRootAsync`- Choosing an injection scope (singleton vs REQUEST vs TRANSIENT)- Wiring custom providers (`useClass`/`useValue`/`useFactory`) and injection tokens- Resolving or avoiding circular dependencies- Deciding whether a module should be `@Global()`## Rules- `feature-module-boundaries` - one module per feature/domain; keep providers encapsulated- `export-shared-providers` - only providers listed in `exports` are visible to importing modules- `dynamic-modules-forroot` - configure reusable modules via `forRoot`/`forRootAsync` returning `DynamicModule`- `injection-scopes-default-singleton` - prefer default singleton scope; REQUEST scope bubbles up and hurts performance- `custom-provider-tokens` - use `useClass`/`useValue`/`useFactory` with injection tokens and interfaces- `constructor-injection` - prefer constructor injection over property injection- `avoid-circular-dependencies` - restructure first; use `forwardRef` only as a last resort- `global-module-sparingly` - reserve `@Global()` for truly cross-cutting modules (config, logger)## How to UseRead individual rule files in `rules/` for explanation + incorrect/correct examples.

Frequently asked questions