---
name: Audit
description: Audit a specific code area for correctness, architecture, data flow, and quality issues. Returns structured findings with severity levels.
parallel: true
allowBuiltinTools: [Read, Glob, Grep, Bash, BashOutput]
displayFields: [area]
parameters:
  properties:
    area:
      type: string
      description: The code area to audit. Includes the directory or file scope plus a brief description of what this area covers.
    checklist:
      type: string
      description: Optional comma-separated checklist focus areas to prioritize, e.g. "error-handling, type-safety". When omitted, all standard checks apply.
  required: [area]
---

Audit this code area thoroughly: {{area}}. {{#if checklist}}Prioritize these areas: {{checklist}}.{{/if}}

Read every file in the area. Do not sample or skim. For directories with many files, use Glob to enumerate them all, then Read each one. If a file is too large, read it in sections. The goal is full coverage of the area, not a spot check.

Apply these checks to every file you read:

Correctness: logic errors, off-by-one mistakes, wrong operator, swapped arguments, race conditions, impossible states, broken control flow, infinite loops, incorrect return values, missing awaits on promises, API contracts that don't match their callers, mutating shared objects while an async operation referencing them is still in flight.

Error handling: swallowed errors, catch blocks that silently continue, missing error propagation, thrown strings instead of Error objects, unhandled promise rejections, try-catch wrapping code that cannot throw, Promise.all discarding successful results when one rejection occurs in a batch that should tolerate partial failure, errors that lose context as they propagate (generic messages with no indication of what failed or why, re-throws that discard the original cause).

Edge cases: null or undefined inputs where not guarded, empty arrays or strings, boundary values (0, -1, MAX_SAFE_INTEGER), missing default cases in switches, partial failures in batch operations, truthiness checks (`if (x)`, `x || default`) on values where 0, empty string, or false are legitimate.

Resource management: unclosed file handles, streams, or database connections, missing cleanup in finally blocks, event listeners added but never removed, timers set but never cleared.

Type safety: unsafe casts, use of `any` that hides real types, missing type narrowing before property access, assertions that skip validation, generic parameters that default to `any`.

Consistency: patterns used elsewhere but not here, mixed sync/async styles in the same module, inconsistent return conventions across similar functions (some return null, some throw, some return undefined for the same failure mode).

Dead code: unused imports, unreachable branches after early returns, variables assigned but never read, commented-out code left behind, exports with no consumers.

Security: unsanitized user input used in shell commands or file paths, path traversal via unchecked `..`, hardcoded secrets, overly permissive file permissions.

Performance: repeated expensive calls that could be cached or hoisted, O(n^2) patterns on potentially large data, synchronous file I/O on hot paths, unbounded growth of in-memory collections.

Complexity: over-engineered solutions that are more generic or abstract than the current requirements justify, functions or classes that do too many things at once, deeply nested control flow that is hard to follow, clever code that saves lines but sacrifices readability, premature abstraction for problems that don't exist yet.

Naming: names that are misleading, ambiguous, or too vague to convey what a variable, function, or type actually represents, boolean names that read backwards (e.g., `disabled` when the logic tests for enabled), inconsistent verb/noun patterns across similar functions, abbreviations that only the author would understand.

Reliability: missing graceful degradation when an external dependency (network, file system, third-party service) is unavailable, no retry or timeout for operations that can hang, crash-on-error paths that should degrade instead, missing fallback behavior when optional features fail, hardcoded assumptions about the runtime environment (specific OS paths, timezones, locales, network availability) that silently break on a different platform or deployment.

Layering: lower-level modules importing from higher layers, circular dependencies between modules, god files that mix unrelated responsibilities, abstraction leaks where internal details are exposed through public interfaces.

Coupling: duplicated logic across modules that should share a common abstraction, modules reaching deep into another module's internals instead of going through its public API, code that is hard to modify because changes require touching many unrelated files, code that depends on global state or concrete implementations with no seam for substitution.

Validation: missing checks at system boundaries where external input enters (API handlers, file parsers, config loaders), silent data loss or corruption where values are truncated, coerced, or dropped without warning.

State: multi-step mutations without atomicity or rollback, business rules scattered across multiple locations instead of centralized, fields that should stay in sync but are updated independently, assumptions about data shape or invariants that are relied upon but never enforced.

For each finding, cite the exact file and line number. Verify the problem is real by reading the surrounding code before reporting it. Do not report style preferences or subjective opinions. Do not flag patterns that are clearly intentional (e.g., a catch-all at a top-level boundary).

Return the results in this format:

```
Area: (area name)
Files reviewed: (count)

Critical:
- [file:line] Description of the issue and why it matters.

Important:
- [file:line] Description.

Minor:
- [file:line] Description.

Clean:
- Note areas that look solid and well-handled.
```

If the area is clean, say so and still list the files you reviewed. Do not invent findings to fill the format. Do not include explanations beyond the result format.
