# Audit

> Use for a requested investigation or audit; routine checks and known fixes stay in their ordinary workflow. Not for work that starts from an idea to build (that path grounds against the codebase and goes to brainstorming).

- Skill: `giostriquer/audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add giostriquer/audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/giostriquer/audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: giostriquer (https://skillmd.com/u/giostriquer)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/giostriquer/audit

---


# Audit

Establishes the requested coverage, selects the engine, preserves uncertainty, then routes the exit by shape. Quick looks and cross-cutting static reviews can run inline.

The workbench flow's door A: turn "something to check" into a sized, engine-run,
evidence-grounded investigation. The user supplies scope and authority; use the
applicable engine and ask only for missing decisions that change the investigation.

## Steps

1. **Ask the user to size the workload**: skip the question only when they
   already stated or clearly implied the coverage (such as "full audit"). The tiers:

   | Tier | Engine | Fits |
   | --- | --- | --- |
   | **quick look** | inline, this session: a few reads/greps, minutes | "is this config even used?", a suspicion worth five minutes |
   | **deep audit** | the `claim-check` skill | one premise investigated to evidence-graded verdict: a bug to pin down, a ticket to validate, "is the refactor complete?" |
   | **static review** | inline or independent readers where delegation is authorized | cross-cutting instruction, configuration, or document review |
   | **team sweep** | the `qa-sweep` skill | a broad, decomposable surface: a release, a feature area, corroborated findings at team scale |

   Ask with a structured question tool (`AskUserQuestion` or the host's
   equivalent) when one is available: one option per tier, the recommended
   tier first and marked; otherwise present the tiers as a numbered list and
   wait for the pick. Recommend a tier with one line of reasoning, but the
   pick is the user's.

   **Runtime modality flag.** The tiers size breadth; this flags *where the
   evidence must come from*. When the thing to check is behavior a real
   client can drive (an endpoint, a flow in the running app, a CLI) code
   reading alone cannot settle it: say so in the recommendation and confirm,
   as part of the same sizing question, whether the check should drive the
   booted app. A confirmed runtime check is part of the workload handed to
   the engine (a team sweep is runtime by construction; for the other tiers,
   pass the confirmation along so the evidence comes from the running
   surface, not reading alone).

2. **Run the engine.** Static review: inventory the requested surface, inspect its contracts and interactions, and report coverage and source evidence. Quick look: investigate inline and keep it genuinely
   quick, if it starts growing past its size, stop and say so; growing the
   workload is the user's call, not drift. Deep audit / team sweep: invoke the
   engine skill and let it run per its own rules (they own their rigor;
   this skill adds none on top).

3. **Collect findings and flag uncertainty.** Separate what the evidence
   settles from what it doesn't: ambiguous reproductions, contested
   assumptions, results that surprised you, anything where two readings
   survive. Those are the **flags**.

4. **Resolve flags according to what is missing.** Investigate reachable evidence.
   Ask the user when an unresolved preference or intended behavior changes the
   verdict or next action. An ambiguous reproduction remains an evidence gap in
   the report; do not ask the user to certify it as true. Continue independent
   findings while a needed answer is pending.

5. **Route the exit:**
   - **The audit was the ask** → deliver the report (verdict-first, per the
     engine's own output shape when one ran) and stop.
   - **Work was revealed, feature/refactor-shaped** → hand into
     `brainstorming` with the findings and confirmed flags as its context; it
     must not re-derive them.
   - **Repairs already authorized** → continue confirmed in-scope fixes; use brainstorming only for unsettled design.
   - **Work was revealed without implementation authority, a confirmed fix** → skip the design debate; present
     the route pick (direct / plan / handoff-goal) directly: asked like the
     sizing question: structured question tool when available, with
     user-facing labels (**Direct**, **Plan**, **Long-running goal**) and the
     recommended route first and marked; a numbered list otherwise.

## Output

- The sized tier and engine that ran, with the runtime modality when it was
  flagged.
- Findings, verdict-first; flagged uncertainties with the user's resolutions.
- The exit taken: report-and-done, handed to brainstorming, or at the route
  gate.

## Boundaries

- **Inline investigation is limited to quick look and static review**: deep and sweep
  work belongs to the engines.
- **Never grows the workload silently.** A quick look that wants to become a
  deep audit is a question for the user, not a decision.
- Preserve unresolved evidence in the report; ask only for decisions the user can supply and pause dependent work.
- An audit-only assignment ends in its report or recommendation. Existing implementation authority carries into the supported repair afterward.