audit
The audit skill executes a comprehensive project-wide health assessment by distributing analysis tasks across multiple specialized analysis skills in parallel, aggregating their findings through an evaluation step, and producing both markdown and HTML audit reports saved to the .turbo directory. Use it when users request a full codebase audit, project health check, code review, or similar comprehensive project assessment requests.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/audit && cp -r /tmp/audit/codex/skills/audit ~/.claude/skills/auditSKILL.md
# 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: 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 if `.turbo/threat-model.md` exists. If it does, continue to Step 3. If missing, 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 Launch the analysis agents below in parallel. 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. 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. 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/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> ``` ## 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 - 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 ## Rul
For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.
Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".
Shared commit message rules and technical constraints referenced by $stage-commit and $commit-staged. Not typically invoked directly.
Commit already-staged changes and push in one step. Use when the user asks to \"commit and push staged changes\", \"commit and push what's staged\", or \"commit staged and push\".