/preflight-security-audit

name: preflight-security-audit
description: >
  This skill should be used when the user wants a comprehensive pre-ship audit
  of an app, product, or codebase — phrases like "audit my app", "security
  check before launch", "is this ready to ship", "preflight audit", "review my
  product for vulnerabilities", "check my code for security issues", or after
  building a feature/product and wanting a thorough security, reliability,
  performance, privacy, and launch-readiness review. Covers OWASP Top 10 (2025),
  LLM Top 10, GDPR/KVKK, accessibility, SEO, and Stripe/Supabase/Next.js stacks.
version: 0.1.0

Preflight Security Audit

Run a comprehensive, 360° audit of a codebase before it ships. This skill is the methodology behind the `/audit` command. It defines the passes to run, how to run them without hallucinating findings, the severity rubric, and the report format.

Core principles

1. **Evidence over suspicion.** Every finding must cite a concrete `file:line` and explain the exploit or failure path. If it cannot be proven from the code, it does not go in the report as a finding — it goes in an "unverified notes" appendix at most. 2. **Trace, don't pattern-match.** Follow untrusted data from its source to its sink. Follow every state-changing operation to its failure paths. Naming a category is not an audit; proving a specific instance is. 3. **Language- and stack-agnostic, but stack-aware.** The passes apply to any language. When the stack is detected (Next.js, Supabase, Stripe, an AI SDK, etc.), apply the stack-specific checks in the reference files. 4. **Verification is a pass, not an afterthought.** Track 6 re-checks every finding and rejects the ones that can't survive scrutiny. Always run it last. 5. **Nothing is changed without approval.** The audit reports and proposes. Fixes are applied only via `/audit-fix` after the user approves specific items.

How to run an audit

When invoked (directly or via `/audit`):

1. **Scope.** Determine the target path (default: current project root). Identify the languages, frameworks, and services in use (read `package.json`, lockfiles, config, `.env.example`, framework markers). Note what you find — it drives which stack-specific checks apply. Always run all six tracks; **stack- conditional passes (marked "Applies when…") run only when their marker is detected — otherwise record them as not applicable and skip them.** Emit the detected stack up front so the report shows what ran and what was skipped. 2. **Dispatch the tracks.** Run all six tracks below. On large repos, dispatch the five auditor agents in parallel (they exist in `agents/`), each reading its matching reference file; on smaller work or when subagents are unavailable, run the passes inline by reading the reference files directly. 3. **Collect raw findings** from every track into one list, each with: file:line, category, description, exploit/failure path, suggested fix, proposed severity. 4. **Verify (Track 6).** Run every raw finding through `references/06-verification.md`. Drop anything unprovable, merge duplicates, calibrate severity. 5. **Write the report** to `AUDIT-<YYYY-MM-DD>.md` in the project root using the template below. 6. **Propose fixes** for every Critical and High finding: show the concrete diff and ask which to apply. Never edit code in this step.

The six tracks

Each track has a reference file with the full pass list, "hunt-for" checklists, and stack-specific checks. Read the relevant file when running that track.

| Track | Reference file | Focus | |-------|----------------|-------| | 1. Code Core (the 20) | `references/01-code-core.md` | injection, auth, authz/IDOR, secrets, error handling, concurrency, resources, N+1, complexity, memory, external calls, idempotency, transactions, config, deps, logging, API/module contracts, tests | | 2. Web/App Security | `references/02-web-security.md` | XSS, CSRF, SSRF, headers/CORS/TLS, cryptography, file upload, rate limiting, multi-tenancy/RLS, business logic, data integrity, live-DB advisor; client-side storage, serverless/edge\*, GraphQL/realtime\*, modern attacks (Trojan Source), advanced injections, exposed files, bot/DoS, JWT\* | | 3. AI/LLM Security | `references/03-ai-llm-security.md` | prompt injection, output handling, sensitive disclosure, excessive agency, AI supply chain | | 4. Privacy & Compliance | `references/04-privacy-compliance.md` | PII inventory, GDPR/KVKK, cookies, retention/deletion, DPAs, legal pages | | 5. Product & Launch Readiness | `references/05-launch-readiness.md` | accessibility, SEO, Core Web Vitals, monitoring, backups, CI/CD, billing correctness, email deliverability; subdomain takeover, Docker\*, security.txt | | 6. Verification | `references/06-verification.md` | re-check, reject unprovable, dedupe, calibrate, 0–100 score, assemble |

\* = **stack-conditional** — runs only when the relevant marker (serverless/edge host, GraphQL/WebSocket, Dockerfile, JWTs) is detected; skipped and marked N/A otherwise.

Severity rubric

Assign severity by **impact × exploitability**, not by category.

• **Critical** — Remotely exploitable with no/low privilege, leads to data breach,

auth bypass, RCE, payment manipulation, or full tenant-data exposure. Ship-blocker.

• **High** — Exploitable but needs some privilege or specific conditions; serious

data exposure, privilege escalation, money/data loss under realistic conditions. Fix before launch.

• **Medium** — Real weakness with limited impact or meaningful preconditions;

reliability/perf issues that degrade production; missing compliance controls. Fix soon.

• **Low** — Best-practice gaps, defense-in-depth, minor info leaks, hygiene.
• **Info** — Observations, not defects.

Note on calibration: brute-force / rate-limiting / DoS / open-redirect findings are real for a shipping product but usually **Medium/Low**, not Critical — do not inflate them. Conve