/full-audit — Multi-Agent Comprehensive Code Audit

Trigger & invocation

Activate when the user invokes the skill explicitly (/full-audit) or uses natural-language keywords for a comprehensive audit ("audit", "review", "audit completo", "analisi completa", "controlla il codice", "security check"). Supported forms:

/full-audit → mode full su intero codebase
/full-audit differential → audit del delta vs main
/full-audit differential <base-branch> → delta vs branch specifico
/full-audit differential HEAD~5 → delta degli ultimi 5 commit
/full-audit targeted <path> → audit ristretto a <path> (es. src/auth/)
Flag opzionali: --focus <area> o --skip <area> con area ∈ {security, bugs, flow, ux, types}

For natural-language requests without specific mode, default to full (or ask the user if scope is ambiguous — su codebase LARGE confirma prima).

Promotion history: v1 monolitica → v2 multi-agent il 2026-05-19. v1 archived in ~/.claude/skills/_archived/full-audit-v1/ come reference storico.

Overview

You are the Opus orchestrator of a multi-agent audit pipeline. You delegate vertical analysis to Sonnet specialist workers (one per audit dimension) and a Haiku baseline runner. You aggregate their outputs into a structured report.

Full design rationale: ~/.claude/skills/full-audit/PRP.md.

[Opus orchestrator]
  ├─ Phase A: Triage (codebase recon, mode parse, scope decision)
  ├─ Phase B: Baseline (1× Agent Haiku: linter/type-check/tests/dep-audit/git stats)
  ├─ Phase C: Specialist dispatch (N× Agent Sonnet in parallel, each invoking a vertical skill)
  ├─ Phase D: Aggregation (dedup, severity bump, priority score, narrative synthesis)
  └─ Phase E: Output (.audit/<timestamp>-<sha>.md + .json + INDEX.md append)

Procedure

Phase A — Triage (you, main context)

Parse arguments: extract mode and --focus/--skip flags.
Reconnaissance via Bash one-shots (output piccolo, mai dump grossi):
- File count: find . -type f | wc -l (esclude .git, node_modules, dist, build)
- Languages: identifica estensioni dominanti
- Project type: presenza di package.json, pyproject.toml, go.mod, Cargo.toml
- Workflows: presenza di .github/workflows/*.yml
- Frontend: presenza di .tsx, .vue, .svelte, .jsx
Read CLAUDE.md nella project root se esiste → estrai sezione "Aree critiche" → critical_areas: [paths/keywords].
Decide codebase size:
- SMALL: <500 file
- MEDIUM: 500-2000 file
- LARGE: >2000 file
Decide dispatch plan seguendo le routing rules (sotto). Per LARGE in mode full, applica risk-first: security-defaults + security-sharp-edges + bugs sempre full coverage, altri workers solo su entry point/core e su critical_areas.
Comunica il piano all'utente: 1 frase prima di partire. Esempio: "Avvio audit full su MEDIUM codebase (1247 file): 8 worker in parallelo (security×2, supply-chain, agentic-actions, bugs, flow, ux, types). Baseline in corso."

Phase B — Baseline (1× Agent Haiku)

Skip rule (v2.0.1): se mode == targeted AND scope_file_count < 50, Phase B può essere skippata. Imposta baseline: null + baseline_skipped_reason nel JSON aggregated. Negli altri casi (full / differential / targeted con ≥50 file), baseline sempre eseguita.

Se NON skippata: UNA singola chiamata Agent con subagent_type=general-purpose, model=haiku.

Prompt esatto: vedi references/worker_prompts.md#baseline. Sostituisci {project_root}, {languages} con i valori reali.

L'output (JSON) viene incluso come baseline_summary nei prompt dei worker in Phase C. Se skippato, passa baseline_summary: null ai worker.

Phase C — Specialist Dispatch (N× Agent Sonnet in parallel)

Per ogni worker nel dispatch plan, una Agent call con subagent_type=general-purpose, model=sonnet. TUTTE le call nella stessa response per parallelism massimo.

Prompt esatto per ciascun worker: references/worker_prompts.md (sezione "Generic worker template" + "Per-worker methodology").

Aspetta completamento di tutti i worker prima di passare a Phase D.

Phase D — Aggregation (you, main context)

Per ciascun worker output:

Parse + Schema Validation (v2.0.2):
- Parse JSON. Se non parsabile → 1 retry con prompt: "Your previous response was not valid JSON. Return ONLY the JSON object matching the schema. Do not include any markdown fences, preamble, or explanation. Start the response with { and end with }."
- Validate schema on each finding. Required fields: id, file, line_start (int), line_end (int), category, severity (UPPERCASE enum), confidence (lowercase enum), title, description, evidence, recommendation, scope_relation. Common aliases to detect (and reject): lines (string instead of line_start/line_end), fix (instead of recommendation), flow (extra field), missing evidence, missing scope_relation, severity lowercase, confidence UPPERCASE.
- Se schema-non-conforming → 1 retry con prompt: "Your previous output used wrong field names or missing required fields. Required field names: line_start (int, not 'lines' string), line_end (int), recommendation (not 'fix'), evidence (use '(see referenced file)' if no snippet), scope_relation ('in_scope' default). Severity values must be UPPERCASE. Re-emit the JSON with correct field names per the schema. See references/worker_prompts.md#required-field-names-v202--critical for examples."
- Se entrambi i retry falliscono → marca status: "partial" per quel worker e annota in workers_partial[]. Phase D normalizza manualmente i campi noti: lines: "X,Y" → line_start: X, line_end: Y; lines: "X" → line_start: X, line_end: X; fix → recommendation; default evidence: "(no snippet provided)", scope_relation: "in_scope"; severity to UPPERCASE.
- Se il parsing JSON proprio fallisce dopo retry (non solo schema) → marca status: "failed", prosegui.
Dedup (v2.0.1: 2-pass):
- Pass 1 (strict): raggruppa per chiave (file, line_start // 10, category). Cluster ≥2 da worker diversi → merge.
- Pass 2 (semantic by domain): sui findings non ancora dedupplicati, raggruppa per (file, |line_start_a − line_start_b| ≤ 20, domain_of(cat_a) ∩ domain_of(cat_b) ≠ ∅). Cluster ≥2 da worker diversi → merge. Il domain_of() mapping è in references/json_schemas.md#category-domain-mapping — alcune category sono in più di un domain.
Su ogni merge (Pass 1 o 2):
- Mantieni severity più alta del cluster (originale, pre-bump)
- Merge recommendation (set union, separator " / ")
- Bumpa confidence a high
- Imposta cross_validated_by: [worker1, worker2, ...]
- Annota dedup_method: "strict" | "domain"
Scope relation classification (v2.0.1): per ogni finding (post-dedup), imposta scope_relation:
- in_scope se file matcha uno dei scope_paths (prefix match)
- out_of_scope_reachable altrimenti (il worker ha trovato un issue su file esterno seguendo riferimenti)
I findings out_of_scope_reachable contribuiscono allo scoring globale (sono issue reali), ma il report MD li mostra in una sezione separata "Out-of-scope findings (reachable from scope)".
Severity bump da CLAUDE.md: per ogni finding, se file matcha un path/keyword in critical_areas:
- MEDIUM → effective_severity = HIGH
- HIGH → effective_severity = CRITICAL
- LOW o CRITICAL → effective_severity = severity (LOW non bumpato, CRITICAL già al massimo)
- Imposta severity_bumped: true/false, severity_bump_reason: "matched critical_area: <path>"
- Bump max +1 anche se file matcha più aree critiche (no cascading)

Priority score (usa effective_severity):

priority_score = effective_severity_rank × (blast_radius_hint || 1) × confidence_rank
severity_rank:   CRITICAL=4, HIGH=3, MEDIUM=2, LOW=1
confidence_

full-audit