| name | nestjs-project-scaffold |
| description | Use this skill whenever the user wants to create, restructure, or standardize a NestJS backend project in TypeScript, including folder layout, config, environment setup, tooling, and initial integrations (TypeORM-ready, testing-ready, and deployment-friendly). |
NestJS Project Scaffold Skill
Purpose
You are a specialized assistant for bootstrapping and reshaping NestJS projects so they follow consistent, production-ready conventions.
Use this skill to:
- Scaffold a new NestJS project (standalone or part of a monorepo)
- Restructure an existing NestJS project to match preferred folder & module layout
- Wire up base tooling:
- TypeScript strict mode
- ESLint + Prettier
- Environment/config management
- Basic logging & health check
- Make the project TypeORM-ready, testing-ready, and deployment-ready without fully implementing domain logic (other NestJS skills can do that).
Do not use this skill for:
- Implementing business logic (use modules/services/controllers skills)
- Advanced auth, caching, or microservices concerns
- Non-NestJS backend frameworks (Hono, Express-only, etc.)
If CLAUDE.md exists in the repo, treat it as authoritative for project layout, naming, and tooling preferences.
When To Apply This Skill
Trigger this skill when the user says things like:
- “Create a new NestJS API project.”
- “Set up a clean NestJS backend skeleton with TypeORM and testing.”
- “Restructure this NestJS project to follow a standard layout.”
- “Prepare this repo for NestJS with good defaults and configs.”
- “Add NestJS to this monorepo in a consistent way.”
Avoid this skill when the task is clearly about:
- Adding a specific module/feature (e.g.
users,auth) → use feature/module-oriented skills. - Only touching TypeORM entities/migrations → use TypeORM skills.
Project Assumptions
Unless the user or CLAUDE.md says otherwise, assume:
- Language: TypeScript
- Package manager preference:
pnpmifpnpm-lock.yamlexistsyarnifyarn.lockexists- otherwise
npm
- Framework: NestJS (latest stable @ the time), CLI-based
- Testing: Jest by default (can later swap or complement with other tools)
- ORM: TypeORM will be used, but concrete entities & config belong to the
nestjs-typeorm-integrationskill. - Env management:
.envfiles + NestConfigModuleor equivalent.
Target Project Structure
This skill aims to create or converge towards a structure like:
project-root/
src/
app.module.ts
main.ts
config/
app.config.ts
database.config.ts # optional, for TypeORM later
common/
filters/
guards/
interceptors/
decorators/
dto/
modules/
health/
health.module.ts
health.controller.ts
infrastructure/
# optional: cross-cutting infra, e.g. database, messaging
test/
app.e2e-spec.ts
jest-e2e.json
.env.example
nest-cli.json
tsconfig.json
tsconfig.build.json
package.json
README.md
For monorepos, adapt to a apps/api or similar convention, but maintain the same internal NestJS structure.
High-Level Workflow
When this skill is active, follow this process:
Detect or create NestJS project
- If no NestJS project exists:
- Use CLI-equivalent steps to create a new Nest project in the desired folder.
- Set language to TypeScript.
- If a NestJS project exists:
- Inspect its structure (
main.ts,app.module.ts,src/layout,nest-cli.json). - Plan restructuring to align with the target structure above.
- Inspect its structure (
- If no NestJS project exists:
Set up config & environment management
- Install and configure
@nestjs/config(or follow project’s preferences inCLAUDE.md). - Create
src/configdirectory with at leastapp.config.tsand (optionally)database.config.ts. - Wire
ConfigModule.forRoot({ isGlobal: true, ... })inapp.module.ts.
- Install and configure
Create base common infrastructure
- Create
src/commonwith subfolders for:filters(e.g.http-exception.filter.ts)guards(e.g. auth guards to be filled later)interceptors(e.g. logging/transform interceptors)decorators(custom decorators go here)dto(shared DTOs)
- Provide at least one example (like a basic logging interceptor or global exception filter) if it fits the project direction.
- Create
Add a health module
- Create
HealthModuleinsrc/modules/healthorsrc/health:health.module.tshealth.controller.tswith a simpleGET /healthendpoint.
- Optionally integrate with Nest’s health checks later (e.g. Terminus) via another skill.
- Create
Configure main bootstrap
- In
main.ts, configure:NestFactory.create(AppModule)- Global prefix if desired (e.g.
/api) - Validation pipe (can be added here or in a future validation skill)
- Basic logging
Example outline (pseudocode-level, adjusted per project):
async function bootstrap() { const app = await NestFactory.create(AppModule); app.setGlobalPrefix("api"); await app.listen(process.env.PORT ?? 3000); } bootstrap();Maintain flexibility; actual details may depend on other skills (auth, validation).
- In
Prepare TypeORM integration points (without full config)
- Ensure structure allows adding database modules later:
src/config/database.config.tsplaceholdersrc/infrastructure/databaseplaceholder directory if desired
- Do not fully wire TypeORM here; leave detailed config to
nestjs-typeorm-integrationskill.
- Ensure structure allows adding database modules later:
Tooling & quality gates
- Ensure
tsconfig.jsonandtsconfig.build.jsonare present and sane:- Strict type checking preferred (unless
CLAUDE.mdsays otherwise).
- Strict type checking preferred (unless
- Ensure ESLint is set up (via Nest CLI defaults or project conventions).
- Ensure basic
lint,build,start,start:dev,test,test:e2escripts inpackage.jsonare present or corrected.
- Ensure
Testing scaffold
- Ensure Jest config exists (default from Nest CLI).
- Make sure
test/app.e2e-spec.tsandjest-e2e.jsonexist or create them if missing. - Don’t add detailed tests here (that’s for
nestjs-testing-skill), but confirm scaffolding is ready.
Monorepo awareness (if applicable)
- If the project is part of a monorepo (e.g.
apps/api):- Respect workspace structure (PNPM/Yarn/Nx/Turbo).
- Place Nest app under correct folder (
apps/apior similar). - Ensure scripts work from root (
pnpm dev:api, etc.) if conventions exist.
- If the project is part of a monorepo (e.g.
Documentation
- Update or create
README.mdwith:- How to run the project (
install,start:dev,test) - Basic architecture overview (where modules live)
- Where to add new modules (
src/modules) - Where config and env files live
- How to run the project (
- Update or create
Safe Defaults & Conventions
When making decisions:
Use convention over configuration:
src/modules/...for feature modulessrc/common/...for shared utilities- Config modules in
src/config/...
Don’t enforce a specific hexagonal/onion architecture unless
CLAUDE.mdsays so, but do:- Separate pure domain modules from infrastructure when it’s clearly beneficial.
- Be consistent across the project.
Keep bootstrapping minimal and extensible:
- Don’t hardcode features that belong to dedicated skills (auth, caching, microservices).
- Provide hooks/placeholders so those skills can plug in cleanly.
Example Prompts That Should Use This Skill
- “Create a new NestJS API service in
apps/apiwith our usual setup.” - “Reshape this messy NestJS codebase into a clean structure with modules and common utilities.”
- “Scaffold a NestJS project that we can later plug TypeORM and auth into.”
- “Set up a standard NestJS backend with config, health check, and testing ready.”
For these prompts, this skill should:
- Either create the NestJS app from scratch or refactor the existing project.
- Leave clear, well-structured hooks for other NestJS skills (auth, TypeORM integration, testing, microservices) to extend the backend cleanly.