---
name: audit
description: "Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\"."
---

# Audit

Project-wide health audit. Fans out to all analysis skills, evaluates findings, and writes `.turbo/audit.md` and `.turbo/audit.html`. Analysis-only — does not apply fixes.

## Task Tracking

At the start, use `update_plan` to track each phase, restating any remaining steps of a parent workflow alongside them:

1. Scope and partition
2. Threat model
3. Run analysis skills
4. Run `$evaluate-findings` skill
5. Generate markdown report
6. Generate HTML report

## Step 1: Scope and Partition

If `$ARGUMENTS` specifies paths, use those directly (skip the question).

Otherwise, use `request_user_input` to confirm scope:

- **All source files** — audit everything
- **Specific paths** — user provides directories or file patterns
- **Critical paths** — heuristically identify high-risk areas (entry points, auth, data handling, payment processing)

Once scope is determined:

1. Glob for source files in the selected scope. Exclude generated and vendored directories (`node_modules/`, `dist/`, `build/`, `vendor/`, `__pycache__/`, `.build/`, `DerivedData/`, `target/`, `.tox/`, and others appropriate to the project).
2. Partition files by top-level source directory. Cap at 10 partitions. If more than 10 top-level directories exist, group related directories or use `request_user_input` to narrow scope. If a single directory contains 50+ files, sub-partition it by its immediate subdirectories.

## Step 2: Threat Model

Check whether `.turbo/threat-model.md` exists. When it exists, collect each surface's cited paths from **Entry points and sinks** and **Hot files**, ignoring any `:line` suffix. Treat the model as superseded when a surface has no cited path that still resolves. When it exists and is not superseded, continue to Step 3.

If missing or superseded, use `request_user_input` to ask whether to create one before proceeding. The security review benefits from threat model context, but creating one adds time.

- **Yes** — launch a Codex sub-agent call (inherited model defaults) whose prompt instructs it to invoke the `$create-threat-model` skill by reading and following the installed skill instructions. Wait for completion before continuing.
- **No** — continue without a threat model.

## Step 3: Launch All Analysis Agents

Before dispatching, read the project's test configuration and CI workflow to identify any test tier that resets a shared external resource between tests, such as a database, a fixed port, or a cache. Such tiers have no cross-process interlock, so sub-agents running them concurrently wipe each other's state and return failures indistinguishable from defects in the code under review. Name any such tier to every sub-agent as off-limits.

Issue all analysis `spawn_agent` calls below in one batch, then collect their results with `wait_agent`. Do not issue one and await its result before issuing the rest. Each sub-agent inherits the parent model. Each sub-agent's prompt instructs it to invoke its assigned skill by reading and following the installed skill instructions, with the partition's file list passed in for partitioned skills, and to treat the shared working tree and its git index as read-only — any empirical check runs in an isolated `git worktree` created under `$TMPDIR` and discarded afterward. HEAD stays where it is: read other refs with `git show <ref>:<path>` rather than `git checkout` or `git switch`. Refer to that worktree by absolute path in every command and join chained steps with `&&`, so a failed step cannot leave the rest running in the shared checkout. Run teardown and verification as their own commands. Give that worktree its own dependency install rather than reaching the shared tree's install by any route: removing a worktree deletes through symlinks, and a redirected suite writes into the shared install. When its own install is not possible, the check is left unrun and reported as such. Every test runner the sub-agent starts, in a worktree or in the shared checkout, runs in its own process group under a timeout enforced from outside the runner. Before teardown, the sub-agent stops the process group of every runner it started, since stopping a runner can leave the processes it spawned alive. Afterward the sub-agent verifies that `git worktree list` no longer shows the worktree, that `git status --short` is clean, that HEAD is still on the branch it started on, and that the shared tree's dependency directory still resolves (a destroyed install leaves `git status` clean, since it is gitignored). It also confirms that no process from those groups, and none whose command line names the worktree path, if any, is still running, and reports by PID any process it could not stop. When it cannot list processes, it reports that check as unrun and names those process groups and the worktree path, if any. Damage the sub-agent cannot repair is reported with the exact repair command in place of findings.

Expect (6 partitioned rows × number of partitions, plus 5 project-wide rows) Codex sub-agent calls total. State the count explicitly before emitting the batch.

### Partitioned Skills

For each skill below, launch **one sub-agent per partition** with the partition's file list in the prompt. Pass `(skip peer review)` annotations through to `$review-code` as an opt-out so it runs internal reviews only — `$peer-review` is scheduled as its own row to avoid duplicate peer-review runs.

| Skill | Scope |
|---|---|
| `$review-code` with `correctness` (skip peer review) | File list |
| `$review-code` with `security` (skip peer review) | File list |
| `$review-code` with `api-usage` (skip peer review) | File list |
| `$review-code` with `consistency` (skip peer review) | File list |
| `$review-code` with `simplicity` (skip peer review) | File list |
| `$peer-review` | File list |

### Project-Wide Skills

| Skill | Notes |
|---|---|
| `$review-code` with `coverage` (skip peer review) | Project-wide |
| `$review-dependencies` | Project-wide |
| `$review-tooling` | Project-wide |
| `$review-agentic-setup` | Project-wide |
| `$find-dead-code` | Has its own partitioning |

## Step 4: Run `$evaluate-findings` Skill

Aggregate all findings from all agents. Run the `$evaluate-findings` skill once on the combined set.

## Step 5: Generate Markdown Report

Write `.turbo/audit.md` using the template below. Populate the dashboard by counting findings per category and applying health thresholds. The Threat Model row records the Step 2 outcome. Output the dashboard as text before writing the file.

### Report Template

```markdown
# Audit Report

**Date:** <date>
**Scope:** <what was audited>

## Dashboard

| Category | Health | Findings | Critical |
|---|---|---|---|
| Correctness | <Pass/Warn/Fail> | <N> | <N> |
| Security | <Pass/Warn/Fail> | <N> | <N> |
| API Usage | <Pass/Warn/Fail> | <N> | <N> |
| Consistency | <Pass/Warn/Fail> | <N> | <N> |
| Simplicity | <Pass/Warn/Fail> | <N> | <N> |
| Test Coverage | <Pass/Warn/Fail> | <N> | <N> |
| Dependencies | <Pass/Warn/Fail> | <N> | <N> |
| Tooling | <Pass/Warn/Fail> | <N> | <N> |
| Dead Code | <Pass/Warn/Fail> | <N> | <N> |
| Agentic Setup | <Pass/Warn/Fail> | <N> | <N> |
| Threat Model | <Present/Superseded/Missing> | — | — |

### Health Thresholds

- **Pass** — zero P0/P1 findings in this category
- **Warn** — P1 findings present but no P0
- **Fail** — P0 findings present

## Detailed Findings

### Correctness
<findings from $review-code correctness>

### Security
<findings from $review-code security>

### API Usage
<findings from $review-code api-usage>

### Consistency
<findings from $review-code consistency>

### Simplicity
<findings from $review-code simplicity>

### Test Coverage
<findings from $review-code coverage>

### Dependencies
<findings from $review-dependencies>

### Tooling
<findings from $review-tooling>

### Dead Code
<findings from $find-dead-code>

### Agentic Setup
<findings from $review-agentic-setup>

### Threat Model
<status and summary; when superseded, name the model's path and state that it predates the current code>
```

## Step 6: Generate HTML Report

Convert the markdown report into a styled, interactive HTML page.

1. Run the `$frontend-design` skill to load design principles.
2. Read `.turbo/audit.md` for the full report content.
3. Write a self-contained `.turbo/audit.html` (single file, no external dependencies beyond Google Fonts) that presents all findings from the markdown report with:
   - Dashboard health grid with severity color-coding (red=Fail, amber=Warn, green=Pass)
   - Severity summary bar (P0/P1/P2/P3 counts)
   - Sticky navigation between report sections
   - Collapsible category sections
   - `[hidden] { display: none !important; }` in the base styles, so a section whose own CSS sets a `display` value still hides
   - Finding tables with file, line, and description columns
   - Severity badges and color-coded group labels
   - Entrance animations and hover states
   - Print-friendly styles via `@media print`
   - Responsive layout for mobile

## Rules

- If any skill is unavailable or fails, proceed with findings from the remaining skills and note the failure in the report.
- `$peer-review` covers all concerns (correctness, security, api-usage, consistency, simplicity, coverage). Distribute its findings into their matching category sections. Deduplicate findings that overlap with the specialized reviewers.
- Does not modify source code, stage files, or commit.