Guide · Skill routing
Choose a skill
Use Professional Engineering to coordinate implementation, domain skills for NestJS decisions, and Git Publication only after the intended change is verified.
For a whole-codebase quality review, start with nestjs-code-audit. For one feature measured against a documented roadmap on a named branch, start with nestjs-feature-audit.
Routing matrix
| Decision level | Lead skill | Typical questions |
|---|---|---|
| Git and GitHub publication | Git Commit and Pull Request | What belongs in the commit? Is staged content safe? Should this push create a PR or trigger Pages? |
| Implementation workflow and syntax | Professional Software Engineering | What syntax does this project and version support? Is syntactic sugar clearer and safe? How should the change be tested? |
| Feature roadmap status | Feature Audit | Which roadmap items are implemented, missing, legacy, broken, or blocked on this branch? |
| System shape and ownership | Architecture & Principles | Which module owns this write? Is a port justified? Does this capability need its own deployment boundary? |
| Object responsibilities and collaboration | OOP & Design Patterns | Where should this invariant live? Is Strategy warranted? How do we refactor this god provider safely? |
| Framework lifecycle and runtime behavior | Features & Performance | Is this a guard or interceptor? Why is the endpoint slow? How should jobs retry and drain? |
Git Commit and Pull Request
Lead with nestjs-git-commit-pr-message when the user asks to commit, push, open or update a PR, prepare changelog/release text, or confirm CI and GitHub Pages after publication.
It owns publication mechanics, not implementation correctness. It stages only intended files, scans for sensitive content, matches repository history, performs only authorized remote actions, and distinguishes a pushed feature branch from a deployed public site.
Professional Software Engineering
Lead with nestjs-professional-software-engineering for NestJS feature implementation, fixes, refactors, public APIs, library work, developer experience, and syntax selection.
It inspects the actual project and installed versions, compares explicit and convenient forms, and uses syntactic sugar only when it reduces real ceremony without hiding meaningful behavior. NestJS-specific architecture, object-design, and runtime decisions remain owned by the domain skills below.
Feature Audit
Lead with nestjs-feature-audit when the user asks to validate one feature against a roadmap, acceptance plan, migration plan, or phased delivery target on main or another branch.
It safely prepares a stable target revision, stops when no clear roadmap exists, traces every roadmap item to code and verification evidence, and returns the required implemented, missing, legacy, bug, and blocker categories. It does not implement findings.
Use the Feature Audit workflow → · Open the full skill →
Architecture & Principles
Lead with nestjs-architecture-principles for decisions that affect dependency direction, capability ownership, module APIs, transaction boundaries, or deployment shape.
It chooses the lowest architecture level that satisfies known constraints. A cohesive modular monolith is the default starting point; layers, ports, CQRS, and independent services must earn their operational and cognitive cost.
OOP & Design Patterns
Lead with nestjs-oop-design-patterns when the system boundary is understood but the responsibilities inside it are unclear. It diagnoses cohesion, encapsulation, substitutability, variation, and code smells before selecting a pattern.
It does not require an interface for every class or a pattern for every conditional. Direct code remains preferable when no durable variation or boundary exists.
Features & Performance
Lead with nestjs-features-performance for framework feature selection, request and message lifecycles, error taxonomy and transport mapping, CI/CD, containers, Kubernetes, observability/SRE, resource bottlenecks, reliability, or horizontal scale.
It measures before optimizing and compares repository intent with the built artifact and live runtime before diagnosing deployment. Fastify, Redis, workers, replicas, and service splits are possible remedies only after evidence identifies the constraint and the compatibility cost is understood.
Intentional overlap
Overlap is resolved by decision ownership, so the skills reinforce rather than override each other.
| Topic | Primary ownership | Handoff |
|---|---|---|
| Git publication | Git Publication owns staging, commits, pushes, PRs, changelog/release text, CI, and Pages follow-up | Professional Engineering and domain skills determine whether implementation is ready |
| Implementation and syntax | Professional Engineering coordinates inspection, syntax selection, coding, testing, and reporting | Domain skills own architecture, object design, and NestJS runtime decisions |
| Feature roadmap status | Feature Audit owns target revision, roadmap gate, traceability, classification, and the feature report | Code Audit may supply quality findings; domain skills retain technical judgment; implementation requires a separate request |
| Dependency injection | Architecture defines boundaries and composition; OOP defines collaborator contracts | Features evaluates provider scope and runtime cost |
| Interceptors and guards | Features owns lifecycle placement | OOP reviews cohesion; Architecture prevents business policy from leaking into transport adapters |
| Events | Architecture owns capability and transaction boundaries | OOP models completed facts; Features owns delivery, retries, idempotency, and backpressure |
| CQRS | Architecture decides whether command/query separation is justified | OOP shapes handlers and messages; Features verifies transport and operational behavior |
| Error handling | Features owns taxonomy, public/transport mapping, filters, deadlines, retry classification, fatal-process behavior, and diagnostics | OOP models cohesive failure types; Architecture owns transactions and partial-effect consistency; Security owns disclosure |
| Security | Features owns validation, identity, access, secrets, output, and abuse controls | Architecture assigns trust/data ownership; OOP encapsulates resource policy |
| Testing | Features owns test-layer selection and runtime verification | Architecture owns boundary assertions; OOP owns object behavior and test seams |
| Database & ORM | Architecture owns data, migration, transaction, and persistence boundaries | OOP shapes domain objects/ports; Features diagnoses query, pool, and capacity cost |
| API design | Features owns transport contracts, DTOs, compatibility, and protocol semantics | Architecture owns capability boundaries; OOP owns invariant-rich internal models |
| Microservices | Architecture owns extraction, service contracts, and data ownership | Features implements transport, delivery, backpressure, health, and measured capacity |
| DevOps & deployment | Features owns artifact, configuration, health, telemetry, drain, and rollout mechanics | Architecture owns independently deployable boundaries and data compatibility |
| Performance-driven service split | Features supplies measurements and capacity evidence | Architecture decides whether independent deployment and data ownership justify the split |
| Repository pattern | Architecture decides whether persistence needs a port | OOP keeps the contract application-owned and cohesive; Features checks query and transaction cost |
Pre-execution conflict guard
Every skill carries the same guard, with ownership specialized to its decision level. After selecting all applicable skills and before any file edit, package installation, generator, migration, deployment, or other state-changing command:
- Read the target repository instructions and each active skill's prerequisites and ownership declaration.
- List the intended files, contracts, commands, target environments, and assumptions.
- Flag incompatible outcomes, unsafe command ordering or side effects, overlapping primary ownership, and unmet prerequisites.
- Resolve each disputed decision using explicit user intent, verified repository/runtime constraints, and then the narrowest primary owner in the routing matrix.
- Assign one lead skill to the decision. If a material conflict remains, stop before mutation and present the conflict and smallest safe choices.
Read-only inspection may continue to collect the evidence needed to resolve a conflict. The guard blocks mutation, not diagnosis.
Do not merge incompatible advice
Running both commands, introducing parallel abstractions, or letting the last skill overwrite the first is not conflict resolution. The agent must preserve one coherent architecture and execution plan.
Shared rules
All implementation and NestJS domain skills use the same non-negotiable order when advice competes:
- Correctness, security, and data integrity.
- Explicit external contracts and backward compatibility.
- Operability, failure containment, and measured runtime behavior.
- Healthy repository conventions.
- Design purity and local elegance.
They also share four working defaults:
- inspect the actual repository and installed versions before prescribing;
- prefer the least complex safe design;
- keep business policy separate from volatile framework and infrastructure concerns;
- verify behavior with tests, traces, measurements, or operational checks.
A conflict is evidence to investigate
If two recommendations still appear incompatible, do not silently pick the more elaborate one. State the concrete requirement, identify which decision level owns it, and verify the repository or runtime evidence that resolves it.
A cross-skill sequence
For a feature that writes data and publishes work:
- Professional Engineering: inspect the project, versions, conventions, public contracts, and verification commands.
- Architecture: assign write ownership, transaction intent, and dependency direction.
- OOP: place invariants and define the smallest useful collaborators or ports.
- Features: choose the controller, validation, event or queue mechanism, idempotency, observability, and shutdown behavior.
- Professional Engineering: implement the coherent design and verify the public contract, boundary wiring, failure paths, and runtime target.
- Git Publication: stage the intended scope, scan for sensitive content, publish only the requested Git/GitHub state, and verify matching CI or Pages workflows.