| name | audit-domain-01-security |
| description | Audit the security domain — auth, authz, secrets, transport, sensitive data exposure, dependency CVEs. Run as part of /audit Phase E. |
Skill: Audit Domain 1 — Security
This skill audits one specific domain. It runs in an isolated subagent
context spawned by the audit-orchestrator. The subagent loads this
skill and the audit rules, runs against the audit scope, and returns
a ~2K-token findings report.
Pre-flight
view @.claude/context/audit-rules.md
If you have findings from previous audit phases (hard stops, Tambon,
blind spots), the orchestrator passes them as input. Use them — don't
re-discover findings other phases already produced. Specifically:
- Hard stops related to this domain: H1, H2, H3, H6, H7, H8
- Blind spots that route to this domain: B1, B7, B8
If the orchestrator didn't pass you these inputs, do NOT re-run the
hard-stops or blind-spots walks. Audit your domain only and trust the
orchestrator to stitch.
Scope
Authentication, authorization, session management, secrets handling, transport security (TLS), CORS, CSRF, rate limiting, input validation, output encoding, dependency vulnerabilities (CVEs).
Key questions to answer
For each, find the evidence and report it. The questions are the
audit's spine — every finding maps back to one of them.
- Is auth wired to every protected route, not just defined?
- Are sessions invalidated on logout server-side?
- Are passwords hashed with a slow algorithm (bcrypt/argon2)?
- Are tokens in httpOnly cookies, not localStorage?
- Is CORS scoped to specific origins, not
*?
- Is rate limiting in place on login, password reset, and AI calls?
- Are dependencies free of known high/critical CVEs?
- Are TLS certs valid, modern, and HSTS-enforced?
Files most likely to have findings
Don't read everything. Read these files first:
- auth middleware
- session/token handling
- password hashing utility
- rate limiter config
- CORS config
- dependency manifest
If you exhaust these and the budget allows, expand outward. Otherwise,
report what you found and note what you didn't read.
Process
-
Re-read the rules. R1-R7 apply to every finding. Especially R2
(quote before cite) — for a domain skill running in a subagent, the
subagent's context is fresh; don't assume you remember a file from
a previous turn.
-
Walk the key questions. For each question, run the relevant
detection commands (greps, file reads, schema lookups). Capture
evidence at path:line. Verify by reading the actual code.
-
Cross-reference orchestrator inputs. If the orchestrator passed
hard-stops or blind-spots findings tagged for this domain, include
them in your report. Don't re-investigate; just include with the
provided evidence.
-
Triage. For each finding, set severity per the audit rubric and
exploitability per R4.
-
Produce the domain report.
Output format
═══════════════════════════════════════════════════════════════════════
DOMAIN 1: Security
═══════════════════════════════════════════════════════════════════════
▶ FOUNDER VIEW
[2-4 sentences in plain English. Sample tone:]
What can a stranger break by visiting your site? This domain answers that, in concrete attack scenarios.
▶ TECHNICAL EVIDENCE
Scope of this domain audit:
Files read: <count>
Files skipped: <count> (reason: outside scope or low-priority)
Findings:
F-1.1 — <one-line title>
Severity: Critical | High | Medium | Low
Exploitability: EXPLOITABLE-NOW | EXPLOITABLE-LOW-EFFORT | BAD-PRACTICE | UNKNOWN
Hard-stop: H<N> if applicable
Blind-spot: B<N> if applicable
Evidence:
<path:line> <one-line description>
What's wrong:
<one paragraph>
Why it matters:
<one sentence>
Recommended fix:
<one paragraph; for full fix prompt, use /audit-fix F-1.1>
Verification after fix:
<command>
F-1.2 ...
Summary:
Total findings: <count>
By severity: <counts>
Most urgent: <which finding ID>
[SECTION COMPLETE: Domain 1]
If the domain has zero findings:
▶ TECHNICAL EVIDENCE
✅ No findings in this domain.
Verification:
<commands run that produced no signal>
Confidence: High | Medium | Low
Reason for low confidence: <if applicable>
Failure modes to refuse
- ❌ Producing findings without path:line citations (R1)
- ❌ Citing a path you didn't read (R2)
- ❌ Re-running hard-stops or blind-spots walks (orchestrator did this)
- ❌ Including findings outside this domain's scope (route them to the
right domain instead)
- ❌ Soft-pedaling a Critical to Medium because "it's a small app" (R3)
- ❌ Skipping section completion marker (R6)