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.