NestJS

Enforce module-per-feature structure and dependency injection in NestJS projects.

1|Updated May 2, 2026
One-click install
npx skills add https://github.com/Levironexe/architect --skill nestjs-levironexe
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: NestJS
Source: https://github.com/Levironexe/architect/tree/main/skills/stacks/nestjs
Command: npx skills add https://github.com/Levironexe/architect --skill nestjs-levironexe

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps fix a drifting or messy NestJS codebase by enforcing a clear, enterprise-friendly module-per-feature structure that reduces risky refactors and architectural inconsistency.

Core Features & Use Cases

  • Module-per-feature organization: Keeps controllers, services, and the module definition co-located per feature to preserve NestJS module boundaries.
  • Clean separation of NestJS primitives vs shared code: Places guards/pipes/interceptors/filters in src/common while keeping plain DTOs/utilities in src/shared.
  • Safe refactoring via DI rules: Prevents critical anti-patterns like direct instantiation with new and business logic living in controllers.

Quick Start

Ask your agent to reorganize the project into the required NestJS folders and adjust controllers/services to use constructor dependency injection while moving guards/pipes into src/common and environment/config validation into src/config.

Frequently Asked Questions about NestJS

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor a NestJS project into a module-per-feature structure?

To refactor a NestJS project into a module-per-feature structure, you reorganize your codebase by co-locating controllers, services, and module definitions within src/modules for each specific feature to preserve strict architectural boundaries.

How do I organize guards, pipes, and shared utilities in a NestJS architecture?

In NestJS architecture, you organize guards, pipes, interceptors, and filters inside src/common, while keeping plain DTOs and utilities in src/shared to maintain a clean separation between framework primitives and reusable code.

How do I prevent dependency injection anti-patterns when refactoring NestJS controllers?

You prevent NestJS dependency injection anti-patterns by enforcing constructor injection, avoiding the direct instantiation of services using the new keyword, and moving any business logic out of controllers into dedicated service classes.

Where should environment validation and configuration live in a NestJS project?

Environment validation and configuration should live in the src/config directory in a NestJS project, which prevents direct process.env reads and centralizes application configuration management across the entire codebase.

Can I apply this NestJS restructuring to a codebase with business logic in controllers?

Yes, you can apply this restructuring to a NestJS codebase with business logic in controllers by migrating that logic into dedicated services and updating the controllers to rely strictly on dependency injection for method execution.