agentleFS
tejastn10tejastn10/workbench/skills/design/scaffold-nestjs-module/SKILL.md

scaffold-nestjs-module

Skill1 starsChanged 2 months agoMITView on GitHub

Add a new feature module to an existing NestJS service following Tejas's layout — versioned `v1/` folders for controllers/services/dto, module-local `constants.ts`, `.controller.options.ts` for route metadata, entity or schema folder, snake_case at the wire/DB layer. Use when asked to "add a module", "scaffold a new endpoint/resource", or "create the X module" in a Nest service.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Test: add a <module>.controller.spec.ts / <module>.service.spec.ts with a small table-driven test that also guards the new signature.

    line 50
  2. Very specific:

    Add constants.ts even if it starts with one value.

    line 58
  3. Distinctive:

    Add the spec file.

    line 59
  4. Very specific:

    Commit feat(<module>): scaffold module on a feature/<module> branch.

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Scaffold a NestJS module

Matches the layout in hearth / ember (and the review conventions in pr-review/nestjs-backend-pr-review).

Layout

src/<module>/
├── <module>.module.ts
├── constants.ts                       # module-local constants — NOT a global file
├── entities/<module>.entity.ts        # (Postgres)   ── or ──
├── schema/<module>.schema.ts          # (Mongo)
└── v1/
    ├── controllers/
    │   ├── <module>.controller.ts
    │   └── <module>.controller.options.ts   # route metadata / swagger options
    ├── dto/
    │   ├── create-<module>.dto.ts
    │   ├── find-<module>.dto.ts
    │   └── update-<module>.dto.ts
    └── services/
        └── <module>.service.ts

Rules

  • Version from day one — endpoints live under v1/. A breaking change becomes v2/, not an edit.
  • Constants stay in the module folder (src/<module>/constants.ts). Never add to a global constants file. If a value is shared cross-service, it belongs in the shared SDK, not here.
  • Reuse before creating — before adding a DTO or response class, check whether the entity / schema / an existing repo method already covers it. The Nest review bias is toward deleting abstractions.
  • snake_case at the wire and DB layer, camelCase in TS internals. Don't mix within a layer.
  • .controller.options.ts holds route decorators' metadata / swagger config so the controller file stays thin.
  • DI: single shared connection modules are global: true, not re-imported per feature. Avoid new forwardRef triads — question the cross-import first.
  • Logging: logger.log not logger.debug for anything meant to be seen in prod. No manual [module] prefixes (Nest adds them).
  • Register the module in app.module.ts (or the parent feature module).
  • Test: add a <module>.controller.spec.ts / <module>.service.spec.ts with a small table-driven test that also guards the new signature.

Process

  1. Confirm the module name, the persistence layer (Postgres entity vs Mongo schema), and the endpoints needed.
  2. Generate the folder tree above; wire the module into its parent.
  3. Add constants.ts even if it starts with one value.
  4. Add the spec file.
  5. Commit feat(<module>): scaffold module on a feature/<module> branch.

Anti-patterns

  • ❌ Flat src/<module>/<module>.controller.ts with no v1/.
  • ❌ New DTOs when the entity would serialize directly.
  • ❌ Adding to a global constants.ts.
  • ❌ logger.debug on request paths.
  • ❌ camelCase leaking into wire/DB payloads.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.