Find exploitable vulnerabilities in codebases

Runs a six-phase, multi-agent security audit of an authorized codebase - web apps, APIs, services, CLI tools, libraries, or daemons - producing only reproducible, exploitable findings rather than a checklist of theoretical issues. Phase 1 (Reconnaissance) maps the application's architecture, trust boundaries, and input surfaces into an architecture.md fed to later agents; Phase 2 (Hunt) dispatches parallel delegated agents against attack-class scopes routed by target type, with native/memory-safety, AI/LLM (prompt injection, tool-calling, output handling), HTTP-protocol/auth, and client-side (DOM injection, UI redress, prototype pollution) each getting a dedicated companion reference with its own attack classes and validation rules; Phase 3 (Validate) consolidates duplicates and independently tries to disprove every finding; Phase 4 (Report) writes a human-readable REPORT.md plus a FINDINGS-DETAIL.md for MEDIUM-and-above findings; Phase 5 (Structured output) emits a schema-validated findings.json; and Phase 6 (Independent verification) re-checks every factual claim and reconciles all outputs. A target.json manifest binds each run to a canonical repository path plus normalized origin URL so same-named repos never share audit history, and prior runs for the same verified target ID are read to skip already-known findings and redirect effort toward under-explored ground rather than re-discovering the same bug.

Use it only against a codebase the user owns or has explicit written authorization to assess - the skill enforces a mandatory confirmation gate before any command that probes, exploits, changes, persists on, or extracts data from a target: state the exact target, confirm written authorization and scope, show the exact commands and their expected effect, and wait for explicit confirmation; absent that, it stays read-only and gives defensive guidance only. Five core principles bound what counts as a real finding: only report what you can actually exploit, a concrete attacker action and outcome rather than "could theoretically"; prefer dynamic confirmation - building, running, or extracting suspect code into a minimal standalone harness - over source-only argument, and mark anything requiring infrastructure the auditor doesn't have as "requires deployment testing" rather than confirmed; calibrate against comparable applications rather than a fixed checklist; treat a defense-in-depth gap behind a working control as a hardening note, not a vulnerability; and score severity on likelihood times impact, with the HIGH-versus-MEDIUM line for business-logic findings being whether an explicit security boundary, a system-enforced role or permission, is actually defeated. Ten named anti-patterns catch what makes an audit useless: treating an OWASP checklist deviation as an automatic finding, rating a defense-in-depth gap as HIGH/CRITICAL, ignoring the deployment model, flagging designed-and-trusted behavior as a bug, padding a report with LOW findings to look thorough, reporting "potential" findings with no proof, omitting what the codebase does well, constructing an exploit from an unverified parser or runtime assumption, skipping business-logic and creative attacks in favor of only scanner-class bugs, and concluding "no SQL injection because parameterized queries" without checking every raw-SQL, dynamic-identifier, or query-builder-bypass path.

Input is the target codebase, from the request or the current working directory, plus an output directory defaulting to ~/security-audit-skill/<target-id>/run-<N>. Output is a fixed artifact set per run: architecture.md (Phase 1), REPORT.md and FINDINGS-DETAIL.md (Phase 4), a schema-validated findings.json (Phase 5), and target.json recording the canonical path, normalized origin, and target ID. Delegated subagents in Phases 1, 2, 3, and 6 never write files themselves - they return results through the Task-tool delegation mechanism, and the orchestrating agent is solely responsible for writing everything to the output directory. Coverage is explicitly partial: testing shows a single run finds roughly half of total vulnerabilities across multiple runs, so the report should recommend a repeat run when no prior runs exist, and should summarize prior-run coverage when they do.

Platform-neutral by design: it maps onto whatever delegation or sub-agent mechanism the host coding agent provides - a Task tool for spawning a research agent for focused fact-finding, or a general agent that can investigate broadly and spawn further research agents - requires a model that supports tool use and parallel sub-agents, and needs a trusted JSON Schema validator already present in the user's environment to structurally validate findings.json against resources/report-schema.json. It explicitly does not replace manual penetration testing or automated SAST/DAST tooling.

Security auditors and engineering teams running an authorized security assessment of their own codebase who want a structured, multi-phase, evidence-gated methodology - confirmed exploits over theoretical findings, calibrated severity, and independent verification - rather than a raw checklist scan.