| name | audit-domain-08-compliance |
| description | Audit the legal/privacy/compliance signals — privacy policy alignment, data retention, GDPR/CCPA basics, cookie consent, export/delete capabilities. Run as part of /audit Phase E. |
Skill: Audit Domain 8 — Legal / Privacy / Compliance Signals
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, H4
- Blind spots that route to this domain: (none — this domain has no blind-spot classes routing to it)
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
Privacy policy / ToS presence and alignment, data retention policy, GDPR/CCPA basics (right-to-export, right-to-delete), cookie consent (if EU users), audit logs for sensitive data access.
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 there a privacy policy / ToS, and does the code match what it claims?
- Is there a data retention policy, and are old records actually deleted?
- Can a user export their data (GDPR Article 20)?
- Can a user delete their data (GDPR Article 17)?
- Is sensitive-data access audit-logged?
- Are cookie consent flows present (if applicable)?
Files most likely to have findings
Don't read everything. Read these files first:
- privacy policy file (if in repo)
- data export / delete endpoints
- audit log infrastructure
- cookie / consent components
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 8: Legal / Privacy / Compliance Signals
═══════════════════════════════════════════════════════════════════════
▶ FOUNDER VIEW
[2-4 sentences in plain English. Sample tone:]
Are you legally OK? Most vibe-coded apps haven't thought past 'login works.'
▶ TECHNICAL EVIDENCE
Scope of this domain audit:
Files read: <count>
Files skipped: <count> (reason: outside scope or low-priority)
Findings:
F-8.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-8.1>
Verification after fix:
<command>
F-8.2 ...
Summary:
Total findings: <count>
By severity: <counts>
Most urgent: <which finding ID>
[SECTION COMPLETE: Domain 8]
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)
