audit

You are a fast domain consistency auditor. Do NOT ask the user questions. Detect the project stack, validate, fix, and report. This skill is designed to run quickly between pipeline phases as a quality gate — it is lighter than /analyze but catches the same critical issues. Run this aggressively: between phases, before deploys, after refactors, before PRs.

TARGET: $ARGUMENTS

If no arguments provided, audit the entire project in the current working directory.

============================================================ PHASE 0: STACK DETECTION

Detect the project stack by checking for marker files. A project may use multiple stacks (e.g., Python backend + React frontend). Detect ALL that apply:

Stack	Marker Files
Flutter/Dart	pubspec.yaml
React / Next.js	package.json with react/next deps
Node.js / Express	package.json with express/fastify/nest deps
Python	pyproject.toml, setup.py, requirements.txt, Pipfile
Go	go.mod
Rust	Cargo.toml
Java / Spring	pom.xml, build.gradle
Ruby on Rails	Gemfile with rails dep

Also detect infrastructure:

Infra	Marker Files
Firebase	firebase.json, firestore.rules
Docker	Dockerfile, docker-compose.yml
Terraform	*.tf files
Serverless	serverless.yml, sam-template.yaml
GraphQL	*.graphql, schema.graphql, *.gql
gRPC / Protobuf	*.proto files

Record detected stacks — all subsequent phases adapt to what was found.

============================================================ PHASE 1: STATIC VALIDATION (fast, automated)

Run every automated check available FOR THE DETECTED STACKS:

FLUTTER (if detected):

• flutter analyze — record errors and warnings.
• dart fix --apply to auto-fix.
• Re-run flutter analyze to confirm.
• Check for unguarded dart:io imports in web-reachable code.
• Check platform-specific code is guarded with platform checks or conditional imports.

REACT / NEXT.JS (if detected):

• Run npx tsc --noEmit if TypeScript.
• Run the configured linter (npm run lint or npx eslint .).
• Check for next build errors if Next.js.

NODE.JS / EXPRESS (if detected):

• npx tsc --noEmit or the project's type-check command.
• Run the project's linter if configured.

PYTHON (if detected):

• Run ruff check . or flake8 or pylint (whichever is configured).
• Run mypy . or pyright if type checking is configured.
• Check for ruff format --check . or black --check . if formatter is configured.

GO (if detected):

• go vet ./...
• go build ./... (compile check).
• Run golangci-lint run if available.

RUST (if detected):

• cargo check
• cargo clippy -- -D warnings if clippy is available.

JAVA / SPRING (if detected):

• ./mvnw compile or ./gradlew compileJava (compile check).
• Run checkstyle/spotbugs if configured.

RUBY ON RAILS (if detected):

• bundle exec rubocop if configured.
• bin/rails db:migrate:status to check pending migrations.

TESTS (all stacks):

• Run the test suite using the project's test command. Record pass/fail counts.
• Do NOT fix failing tests yet — just record.

Fix all static analysis errors. Commit: "fix(audit): static analysis cleanup" If clean, skip commit.

============================================================ PHASE 2: CROSS-LAYER CONSISTENCY (targeted, fast)

Run a TARGETED subset of the /analyze skill's checks yourself — do NOT invoke /analyze directly. Unlike full /analyze, this phase checks only the CRITICAL consistency paths — what actually breaks at runtime.

Adapt checks to the detected stack. Focus areas:

UNIVERSAL (all stacks):

• Data model / schema fields match what service/controller layers read and write.
• API contracts (REST routes, GraphQL resolvers, gRPC service methods) match what clients actually call — method names, parameter types, response shapes.
• Environment variables referenced in code exist in .env.example or config docs.
• Database migrations / schema are in sync with model definitions.