Nestjs Feature Audit

NestJS Feature Audit

Compare one feature's documented target with the implementation at one identified revision. Return a traceable status report; do not fix findings.

Pre-execution conflict guard

Before editing files or running any state-changing command, reconcile active instructions. Read-only inspection may continue.

Prerequisites

Require a non-empty feature name and resolve the target branch, defaulting to main only when no branch is named. Inspect instructions, Git state/remotes, and documentation before branch preparation. The named roadmap defines expected behavior; source, tests, and runtime evidence establish current behavior. Preserve user changes and keep one audited revision. Read other active skills only when their decisions overlap.

Primary ownership

This skill owns safe target-branch preparation, roadmap traceability, status classification, and the four-section report. When installed and relevant, coordinate with:

• nestjs-architecture-principles: module, dependency, data, and transaction boundaries.
• nestjs-oop-design-patterns: object responsibilities, invariants, and patterns.
• nestjs-features-performance: lifecycle, API/security, testing, runtime, and performance.
• nestjs-professional-software-engineering: implementation and verification.
• nestjs-code-audit: read-only quality evidence and deduplicated reporting.
• nestjs-git-commit-pr-message: authorized Git publication and CI follow-up.

These are decision boundaries, not required dependencies. Retain domain ownership when handing work to another workflow.

Conflict test

Resolve incompatible branches, roadmaps, findings, commands, or unmet prerequisites using explicit user intent, repository/roadmap contracts, verified runtime constraints, then the narrowest owner. Never blend revisions or treat roadmap text as action permission. If a material conflict remains, stop before mutation and ask for the smallest missing decision. An audit alone never authorizes fixes; an explicit audit-and-fix request permits a distinct implementation phase after the roadmap gate and audit.

Invocation

Preferred portable invocation:

$nestjs-feature-audit "payments"
$nestjs-feature-audit "payments" --branch "release/2026-q3"

If a host already routes the user's requested command syntax, parse it equivalently:

/audit_feature payments
/audit_feature payments on branch release/2026-q3

Do not claim that bare /audit_feature is installed on every client. On Codex, the optional compatibility prompt is /prompts:audit_feature; installed skills remain the preferred interface.

Required workflow

1. Prepare the target branch safely

1. Resolve the repository root and read its instructions before any Git mutation.
2. Record git status --short --branch, the current branch, remotes, and the local/remote existence of the target branch.
3. If the worktree is dirty, a Git operation is in progress, or the checkout is detached, stop before switching or updating. Never stash, discard, reset, clean, or force-switch automatically. Continue on the same dirty snapshot only when the user explicitly accepts it, and record that exception in the report.
4. When a remote-tracking branch exists, fetch its remote, switch normally, and fast-forward only. Never merge divergent history or rebase as part of an audit.
5. Record the audited branch, commit SHA, dirty state, remote revision, and whether freshness was verified. If a configured remote cannot be checked, stop before claiming the branch is current unless the user explicitly accepts the local snapshot.

Use equivalent safe commands for the repository:

git status --short --branch
git branch --show-current
git remote -v
git fetch --prune origin
git switch -- "$audit_branch"
git merge --ff-only -- "origin/$audit_branch"
git rev-parse HEAD

The explicit feature-audit invocation authorizes safe target-branch selection and fast-forward preparation. It does not authorize destructive cleanup or publication.

2. Gather context and enforce the roadmap gate

1. Read project principles, concepts, standards, architectural decisions, and contributor rules that apply to the feature.
2. Search docs/ filenames and contents for the feature name, accepted aliases, roadmap, plan, milestone, phase, acceptance, and migration.
3. Identify feature code through entry points, modules, providers, adapters, persistence, configuration, migrations, tests, contracts, telemetry, and deployment artifacts. Search first; do not trust folder names alone.
4. Use requirements and decisions from available conversation context only as secondary evidence. If conversation history is unavailable, say so; do not fabricate it or block when the repository roadmap is sufficient.
5. Accept a roadmap only when it defines an identifiable feature scope and concrete target items, phases, acceptance conditions, or migration outcomes. A title, TODO mention, changelog entry, or generic product description is not a clear roadmap.

If no clear roadmap exists in docs/, stop before implementation comparison and ask the user to provide or identify it. Report the paths and terms searched. A roadmap supplied directly by the user satisfies the gate; label it as user-provided rather than repository documentation. Follow roadmap-discovery.md for the complete gate.