An AI coding agent can generate a NestJS controller in seconds. The harder part is deciding where the change belongs, which behavior must stay stable, and how to prove that the result is correct.
I built NestJS Skills to make those decisions more explicit. It is an MIT-licensed collection of seven focused Agent Skills for Claude Code, Codex, and other clients that support the Agent Skills standard.
The project was previously called
nestjs-agent-skills. Its current home is amirtaherkhani/nestjs-skills, and its latest stable release is v2.2.0.
Explore the NestJS Skills website and documentation for installation, skill selection, and practical guides.
🧭 Seven skills, seven clear responsibilities
| Skill | Responsibility |
|---|---|
| Professional Software Engineering | Implement features, fixes, and refactors using the project's conventions, then verify them. |
| Architecture Principles | Reason about modules, dependencies, data ownership, transactions, and service boundaries. |
| OOP & Design Patterns | Choose patterns when the actual variation justifies them, rather than adding abstractions by default. |
| Features & Performance | Review APIs, errors, queues, security, reliability, and measured runtime behavior. |
| Code Audit | Produce a prioritized, evidence-backed review without changing code. |
| Feature Audit | Compare a feature against its documented roadmap on the requested branch. |
| Git Commit & PR Message | Prepare intentional commits and PRs while protecting unrelated work and respecting the authorized publication workflow. |
You do not need all seven for every task. Start with the skill that owns the decision. Each includes a conflict guard: when active instructions disagree about responsibilities, contracts, or changes, resolve that disagreement before editing.
These are instructions for an agent, not a guarantee of correct results. The code and the verification evidence still matter.
✨ What v2.2.0 adds
🔎 Code Audit can work independently
Code Audit now bundles its own semantic review guidance. Other skills can add depth, but are no longer mandatory siblings.
Try this audit request:
Audit this NestJS repository and return one prioritized, evidence-backed
report without changing code. Use healthy controls where they help show
why a finding is real.
The collector uses installed local ESLint and TypeScript checks. It does not install dependencies, apply fixes, run migrations, or deploy.
Feature Audit remains different: it needs a clear roadmap in docs/ or supplied by the user. It should not invent requirements when that evidence is missing.
🧪 Three examples you can run
1. Parse a boolean query correctly
For GET /items?includeArchived=false, JavaScript boolean coercion treats the string "false" as truthy. The corrected fixture uses DefaultValuePipe(false) and ParseBoolPipe. Tests cover omitted, true, false, and invalid values.
2. Protect a module invariant
A wallet operation checks a positive charge and a nonnegative balance. One consumer uses it correctly; another bypasses it through exported storage. The correction routes the unsafe consumer through the public operation and stops exporting that storage. A healthy consumer stays in the fixture so an audit must distinguish actual defects from working code.
3. Optimize a small API with evidence
The slow fixture fetches [one, two, one, two] from a local dependency. Its correction fetches the two unique items concurrently within the request, then restores the original response order. It preserves timeout and failure behavior without introducing a cross-request cache.
This fixture has only two unique items. A user-controlled workload would need explicit bounds and a concurrency limit. Local timing is not a production performance promise.
Run the examples with Node.js 20 or newer:
npm ci
npm run test:fixtures
The runner checks both faulty and corrected variants: seeded regressions must fail as expected, and reference corrections must pass.
📏 Evaluate the skills, not just the examples
Passing fixture tests proves that the examples and their corrections work. It does not prove that a skill improved an agent.
The opt-in evaluation harness compares three tasks across two skill versions, records actual CLI usage when available, and supports held-out checks plus behavior review. Ordinary CI does not invoke a model.
The initial cloud pilot was blocked before a model turn. A later six-run local comparison completed, but it was exploratory: one run per task and version, fixed execution order, ambient skill metadata, and sandbox restrictions limit what we can conclude. There is no established claim of lower costs, consistent token savings, or better model quality.
The useful outcome is a repeatable starting point for checking behavior instead of relying only on a convincing prompt.
🚀 Try it on a real NestJS task
Install the collection:
npx skills add amirtaherkhani/nestjs-skills
Or install only Code Audit for Claude Code and Codex:
npx skills add amirtaherkhani/nestjs-skills \
--skill nestjs-code-audit \
--agent claude-code \
--agent codex
Use /nestjs-code-audit in Claude Code or $nestjs-code-audit in Codex.
Start with a real question: a module cycle, an unsafe retry, a slow endpoint, or a feature that may have drifted from its roadmap. Ask for repository evidence and a verification plan.
Explore the project
Start with the NestJS Skills website and documentation to choose a skill and try it in your project.
If you try it, a small reproducible case is especially useful: the request, relevant code, what the agent missed, and the expected result. If the project helps you, a GitHub star is appreciated.
💬 Which NestJS decision would you want an agent to check more carefully before changing your code?
Top comments (0)