nestjs-stack
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Design
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Env read
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: nestjs-stack
description: NestJS-specific implementation patterns for DDD, Hexagonal Architecture, and CQRS. Use when writ…
category: design
runtime: no special runtime
---
# nestjs-stack output preview
## PART A: Task fit
- Use case: NestJS-specific implementation patterns for DDD, Hexagonal Architecture, and CQRS. Use when writing NestJS code, designing APIs, handling errors, structuring modules, writing TypeORM queries or migrations, adding auth guards, configuring environment variables, or adding structured logging. For language-agnostic DDD/architecture theory, use engineering-toolkit:engineering-foundations instead. This skill covers the NestJS HOW — code placement, module structure, @nestjs/cqrs, TypeORM, NestJS DI. Triggers for NestJS, TypeORM, @nestjs/cqrs, API design, auth guards, config modules, 'where should I put this code', 'how to structure this module'. DO NOT trigger for: generic DDD questions without NestJS context, Django, Next.js, or other frameworks. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Topics / Architecture Overview / Quick Decision Guide” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “NestJS-specific implementation patterns for DDD, Hexagonal Architecture, and CQRS. Use when writing NestJS code, designing APIs, handling errors, structuring modules, writing TypeORM queries or migrations, adding auth guards, configuring environment variables, or adding structured logging. For language-agnostic DDD/architecture theory, use engineering-toolkit:engineering-foundations instead. This skill covers the NestJS HOW — code placement, module structure, @nestjs/cqrs, TypeORM, NestJS DI. Triggers for NestJS, TypeORM, @nestjs/cqrs, API design, auth guards, config modules, 'where should I put this code', 'how to structure this module'. DO NOT trigger for: generic DDD questions without NestJS context, Django, Next.js, or other frameworks. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Topics / Architecture Overview / Quick Decision Guide” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, read environment variables.
Start with a small task and check whether the result follows “Topics / Architecture Overview / Quick Decision Guide”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: nestjs-stack
description: NestJS-specific implementation patterns for DDD, Hexagonal Architecture, and CQRS. Use when writ…
category: design
source: tomevault-io/skills-registry
---
# nestjs-stack
## When to use
- NestJS-specific implementation patterns for DDD, Hexagonal Architecture, and CQRS. Use when writing NestJS code, desig…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Topics / Architecture Overview / Quick Decision Guide” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "nestjs-stack" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Topics / Architecture Overview / Quick Decision Guide
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, read environment variables | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} NestJS-specific implementation of DDD + Hexagonal + CQRS patterns. For the underlying theory (aggregates, domain events, architecture layers), see engineering-toolkit:engineering-foundations. This skill covers the NestJS-specific HOW. Before applying any topic, read its reference file in reference/.
Topics
| Topic | When to Use | Reference |
|---|---|---|
| Error Handling | Exception filters, domain error -> HTTP mapping | reference/error-handling.md |
| Config | Environment variables, config modules, validation | reference/config.md |
| Auth | Guards, JWT strategies, RBAC | reference/auth.md |
| API Design | Endpoints, DTOs, Swagger, pagination | reference/api-design.md |
| Code Structure | Where to place code, resolving circular imports | reference/code-structure.md |
| Logging | Structured logging with Pino, correlation IDs | reference/logging.md |
| Domain Model (NestJS) | @nestjs/cqrs AggregateRoot, EventPublisher | reference/nestjs-domain-model.md |
| TypeORM Migrations | Creating database migrations | reference/typeorm-migrations.md |
| TypeORM Queries | Writing queries and transactions | reference/typeorm-queries.md |
Architecture Overview
+------------------------------------------------------------------+
| PRESENTATION LAYER |
| apps/ (HTTP Controllers, DTOs, Request/Response handling) |
+------------------------------------------------------------------+
| APPLICATION LAYER |
| modules/ (Commands, Queries, Handlers, Events) |
+------------------------------------------------------------------+
| DOMAIN LAYER |
| libs/common/domain/ (Entities, Value Objects, Enums) |
+------------------------------------------------------------------+
| INFRASTRUCTURE LAYER |
| libs/ (Repositories, External APIs, Database, Messaging) |
+------------------------------------------------------------------+
Quick Decision Guide
Writing an endpoint?
-> reference/api-design.md + reference/code-structure.md
Handling errors?
-> reference/error-handling.md
Setting up config/env?
-> reference/config.md
Adding authentication?
-> reference/auth.md
Writing a database query?
-> reference/typeorm-queries.md
Creating a migration?
-> reference/typeorm-migrations.md
Implementing a domain model with events?
-> reference/nestjs-domain-model.md
Adding logging?
-> reference/logging.md
Gotchas
Claude-specific failure modes in NestJS codebases:
- Throwing
HttpExceptionfrom domain/application layer — Claude defaults to HTTP exceptions everywhere. Domain layer must throw domain-specific exceptions; the exception filter maps them to HTTP responses. - Using
process.env.Xinstead of ConfigService — Claude reaches forprocess.envout of habit. Always injectConfigServiceand use.get(). - Putting auth logic in services — Claude tends to add
if (!user.isAdmin)checks inside service methods. Auth belongs in guards; services receive already-validated context. - Returning entities directly from controllers — Claude skips DTO mapping when "it's the same shape anyway." Always use response DTOs, even if they mirror the entity — the contract must be explicit.
- Circular imports between modules — Claude creates circular dependencies when wiring cross-module services. Use
forwardRef()as last resort; prefer restructuring. - Logging message-first instead of context-first — Claude writes
logger.log('User created', { userId })instead oflogger.log({ userId }, 'User created'). Pino expects context object first. - Raw SQL when QueryBuilder suffices — Claude jumps to raw SQL for anything beyond
.find(). Follow the hierarchy: built-in methods > QueryBuilder > raw SQL. - Forgetting to release QueryRunner — Must always release in a
finallyblock. Claude sometimes putsrelease()only in the happy path. - Importing from other module's internal paths — Use the module's public API (barrel exports), not deep
../other-module/internal/fileimports.
Key Rules (Always Apply)
- Domain layer MUST NOT import HTTP exceptions — use domain exceptions, map in filters
- Never access
process.envdirectly — use ConfigService - Auth in guards, not in services — domain receives validated user context
- DTOs for all input/output — never expose entities directly
- Relative imports within modules — path aliases across modules
- Context-first logging — structured fields before message string
- Query hierarchy — built-in methods first, query builder second, raw SQL last resort
- Release query runners — always in a
finallyblock
Source: anpham1925/claude-marketplace — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review