agentsclimarketplace
Sign in

Nestjs architecture

Skill FilippoDeSilva/skills/skills/nestjs/nestjs-architecture

Design NestJS module boundaries, provider scope, and request pipeline choices. Use when structuring modules, placing guards/pipes/interceptors, or reviewing provider lifetime in NestJS.From its SKILL.md

Install
npx -y skills add FilippoDeSilva/skills --skill nestjs-architecture

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.8 KB, 479 tokens by cl100k_base, as published. Nobody here has run it

NestJS Architecture Expert

Priority: P0 (CRITICAL)

Design feature modules with singleton-first providers and explicit request-pipeline choices.

Decision Map

  • Module role: Feature Modules (Auth) vs Core (Config/DB) vs Shared (Utils). Feature owns its controllers, application services, and adapters. Shared exports stateless helpers only.
  • Provider scope: default singleton. Use request scope only for tenant context, request-local caching, or request tracking. Treat request scope as a measured exception.
  • Pipeline choice: middleware for raw HTTP concerns, guard for access decisions, pipe for validation/transforms, interceptor for cross-cutting request/response behavior, filter for error translation.

Recipe

  1. Create bounded feature: module + controller + application service + persistence adapter.
  2. Keep controller thin: Thin controllers, fat services. No business in Controller. Move logic to Service.
  3. Register dependencies once: imports for modules, providers for services, exports only for true consumers. @InjectRepository() dependencies need TypeOrmModule.forFeature([...]).
  4. Validate at edges: DTO validation pipes for incoming data; never trust raw payloads in services.
  5. Check circular imports: check circular dependencies with madge; refactor contracts first and use forwardRef() only as last resort.

Verify

  • Feature module owns one business capability, not a mixed grab bag.
  • Providers are singleton unless request scope has a written reason.
  • Guard/pipe/interceptor/filter placement matches the request lifecycle.
  • Config uses @nestjs/config or a typed config layer, not scattered process.env.
  • Dependency Integrity: DB repositories, queues, and clients are registered in the module graph, not manually instantiated.

Anti-Patterns

  • No request scope by default: Singleton first; justify heavier scope.
  • No business logic in controllers: Delegate orchestration to services/use cases.
  • No entity leakage: Don't return ORM entities; return DTOs or response models.
  • No manual instantiation: Use DI; never new Service() inside Nest code.

References

What ships with it: 4 files

4.3 KB alongside SKILL.md

evals/

references/

Gives 0 of the 12 instructions most architecture codebase skills give in 479 tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

  • design feature modules with singleton-first providers
  • use request scope only for tenant context or request caching
  • use middleware for raw HTTP concerns
  • use guards for access decisions
  • use pipes for validation or transforms
  • use interceptors for cross-cutting behavior

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,764. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.