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.
In this repository73 other files it gives its agents.
- AGENTS.mdAGENTS.md
- bigquery-analyticsSkill
- cache-invalidationSkill
- mongo-aggregationSkill
- mongo-modelingSkill
- postgres-aggregationSkill
- postgres-indexingSkill
- redis-coordinationSkill
- redis-patternsSkill
- review-querySkill
- code-migrationSkill
- cut-releaseSkill
- data-migrationSkill
- deploy-serviceSkill
- hotfixSkill
- rollbackSkill
- design-endpointSkill
- design-eventSkill
- design-schemaSkill
- evolve-contractSkill
- scaffold-projectSkill
- incident-responseSkill
- investigate-bugSkill
- on-callSkill
- postmortemSkill
- audit-skillsSkill
- distill-review-styleSkill
- write-skillSkill
- debug-with-tracesSkill
- define-alertsSkill
- instrument-serviceSkill
- evaluate-dependencySkill
- grillSkill
- handoffSkill
- orientSkill
- phased-deliverySkill
- spikeSkill
- to-questionnaireSkill
- write-adrSkill
- write-prdSkill
- devops-pr-reviewSkill
- go-backend-pr-reviewSkill
- nestjs-backend-pr-reviewSkill
- python-backend-pr-reviewSkill
- react-frontend-pr-reviewSkill
- bisectSkill
- break-couplingSkill
- dead-code-sweepSkill
- deslopifySkill
- extract-moduleSkill
- rebase-cleanSkill
- resolve-merge-conflictsSkill
- split-commitSkill
- tddSkill
- wait-whatSkill
- wide-renameSkill
- bullmqSkill
- kafkaSkill
- sqs-consumerSkill
- audit-dependenciesSkill
- The first 60 shown.
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
- Very specific: line 50
Test: add a <module>.controller.spec.ts / <module>.service.spec.ts with a small table-driven test that also guards the new signature.
- Very specific: line 58
Add constants.ts even if it starts with one value.
- Distinctive: line 59
Add the spec file.
- Very specific: line 60
Commit feat(<module>): scaffold module on a feature/<module> branch.
≈ “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.
Files
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.tsRules
- Version from day one — endpoints live under
v1/. A breaking change becomesv2/, 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.tsholds 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 newforwardReftriads — question the cross-import first. - Logging:
logger.lognotlogger.debugfor 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.tswith a small table-driven test that also guards the new signature.
Process
- Confirm the module name, the persistence layer (Postgres entity vs Mongo schema), and the endpoints needed.
- Generate the folder tree above; wire the module into its parent.
- Add
constants.tseven if it starts with one value. - Add the spec file.
- Commit
feat(<module>): scaffold moduleon afeature/<module>branch.
Anti-patterns
- ❌ Flat
src/<module>/<module>.controller.tswith nov1/. - ❌ New DTOs when the entity would serialize directly.
- ❌ Adding to a global
constants.ts. - ❌
logger.debugon request paths. - ❌ camelCase leaking into wire/DB payloads.
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
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.

