Full Review: Quad Audit Orchestrator

Run four independent audits in parallel and present each report separately. One command that catches bugs, slop, security issues, and stale docs across the entire codebase without invoking each skill manually.

The four audits:

1. Code Review (code-review skill) - bugs, logic errors, edge cases, race conditions, resource leaks, convention violations. Uses confidence-based filtering (>= 80%), adversarial self-check, and evidence-based verification.
2. Slop Check (anti-slop skill) - machine-generated patterns, over-abstraction, verbose code, stale idioms
3. Security Audit (security-audit skill) - vulnerabilities, secrets, dependency risks, OWASP mapping
4. Docs Sweep (update-docs skill) - stale docs, bloated instruction files, missing gotchas, broken links, companion-file drift

Each audit runs in its own parallel agent/subprocess with a fresh context window, so they don't compete for tokens or bias each other's findings.

When to use

• Running a repo-wide quality gate before merge, release, or handoff
• Auditing an unfamiliar codebase across correctness, security, slop, and docs in one pass
• Getting a broad review when the user explicitly wants multiple audit lenses at once

When NOT to use

• A targeted correctness review on specific files - use code-review
• Style/slop cleanup without the other audit passes - use anti-slop
• A dedicated security review only - use security-audit
• A documentation-only maintenance sweep - use update-docs
• A comprehensive audit across all applicable lenses (up to 29 audit agents, including 20 conditional Wave 3 domain lenses) - use deep-audit
• Auditing the skill collection for consistency or quality - use skill-creator
• CI/CD pipeline design or pipeline-config review - use ci-cd

AI Self-Check

Run this checklist after all agents return but before presenting the combined report to the user. Do not present results until every item passes.

Verify:

• All 4 agents dispatched as general-purpose type (NOT feature-dev:*, code-simplifier:*, or other restricted types)
• Each agent invoked its assigned custom skill (code-review, anti-slop, security-audit, update-docs) via the Skill tool
• Each report presented under its own header, unedited
• No cross-report merging or editorializing (findings from different audits stay separate)
• SECURITY-AUDIT.md gitignore reminder included
• Failed agents noted with reason (don't silently drop a missing audit)
• Preflight context block was passed to all agents
• When user specified a scope, the Scope: line in every agent's context block reflects that scope (not "full codebase review")
• Scope held in output: each agent's findings reference only files/modules within the requested scope. If any agent's output references out-of-scope paths, flag it in that report's header (see Step 3 scope verification)
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• Routing explicit: code-review, anti-slop, security-audit, and update-docs findings stay in their lanes
• No false coverage: unrun tests, skipped directories, and unavailable tools are reported

Performance

• Run inventory and changed-file analysis before invoking every review mode.
• Escalate only confirmed high-risk areas to deeper sweeps.

Best Practices

• Lead with actionable findings and severity; keep summaries secondary.
• Separate code bugs, security issues, slop, and docs drift so owners can act.
• Do not claim a full audit if the pass was sampled or tool-limited.

Workflow

Step 0: Preflight

Gather context before dispatching agents. Run these in parallel (guard each with ; true so one failure doesn't cancel siblings):

1. Repo state: git rev-parse --show-toplevel ; true and git rev-parse --short HEAD ; true
2. Branch: git branch --show-current ; true
3. Language detection: check for manifest files (package.json, requirements.txt, go.mod, Cargo.toml, pyproject.toml, composer.json, Gemfile, *.tf, helmfile.yaml)
4. Repo size estimate: git ls-files | wc -l ; true

If not a git repo (step 1 fails): stop and tell the user. The audits rely on git context (history, blame, diff). Running without it produces low-quality results.

Record preflight values - each subagent prompt uses them. Substitute {placeholders} in the agent prompts below with the actual values from preflight (e.g., replace {repo_root} with the output of git rev-parse --show-toplevel). Default {scope} to "full codebase review - scan everything"; override in Step 1 if the user specifies a narrower target.

Step 1: Determine Scope

Default is full codebase since the user is running this as a quality gate. Adapt if context suggests otherwise:

• Uncommitted changes present -> mention this, but still audit the full repo.
• Detached HEAD / bare repo -> warn the user, proceed with what's available.
• User specified a narrower scope (specific files, directory, module) -> pass that scope constraint to all four agents. Each agent only audits within the specified scope. This is the key to scoped reviews: narrowing the target, not the audit dimensions. Set {scope} in the context block to the user's scope (e.g., "src/auth/ directory only") instead of the default "full codebase review - scan everything".

Step 2: Dispatch Four Parallel Agents

Spawn all four agents concurrently. Each agent invokes one of the four custom skills and runs a full codebase audit.

Agent type selection (critical): Each agent MUST be dispatched as a general-purpose agent (or equivalent full-access agent type). Do NOT use specialized agent types like feature-dev:code-reviewer, feature-dev:code-explorer, code-simplifier:*, or any other restricted-toolset agent - these lack access to the Skill tool and cannot invoke custom skills. The agent type name should reflect its capabilities (full tool access), not the audit it performs.

Skill invocation: Each general-purpose agent MUST invoke the named custom skill via the Skill tool (or equivalent skill-loading mechanism) as its first action. Custom skills from the user's installed collection take priority over built-in reviewers or platform-provided audit modes. Specifically:

• Agent 1 invokes code-review via Skill tool, not a built-in code-review mode
• Agent 2 invokes anti-slop via Skill tool, not a built-in code simplifier
• Agent 3 invokes security-audit via Skill tool, not a built-in security scanner
• Agent 4 invokes update-docs via Skill tool, not a built-in documentation reviewer

Fallback: If a custom skill is not available (skill lookup/load returns "not found" or similar), THEN fall back to the best available alternative (manual review following the skill's principles) and note which skill was unavailable in the output header.

If parallel execution is unavailable (restricted sandbox, no subagent support): run sequentially in this order: Security Audit, Code Review, Slop Check, Docs Sweep. Security first because those findings are most time-sensitive. If any agent exceeds 5 minutes wall-clock, note the timeout in the output header and continue with the