Compliance Auditor

Disclaimer - read this first and surface it to the user EVERY TIME

WARNING - NOT LEGAL ADVICE

This skill produces drafts and research artifacts to help engineers
reason about privacy, terms of service, and compliance. It is not a
substitute for a licensed attorney in the user's jurisdiction.

The user MUST have a qualified lawyer review the output before the
docs are relied on in production, especially for any of:
- Paid product / monetization
- EU, UK, or California users at scale
- Health, financial, biometric, or children's data
- Enterprise B2B contracts
- Any live incident or regulator contact

Primary-source citations in the output are aids for the attorney's
review, not a substitute for it. Regulatory interpretation requires
professional judgement.

The final legal docs the user ships MUST include a disclaimer line in their "Who we are" or "About this policy" section that notes professional review was performed (or not) - the drafter agent is instructed to ASK the user about this before writing.

What this skill does

The skill turns a vague "make my legal pages compliant" request into a rigorous multi-agent pipeline that produces accurate Privacy Policy, Terms of Service, and related compliance artifacts that:

Reflect the user's ACTUAL data flows (discovered by reading the user's codebase, not assumed from a template)
Cover the jurisdictions that ACTUALLY apply to their user base (EU GDPR, UK GDPR, CCPA/CPRA, COPPA, Israel PPL, etc.)
Mirror clause structures from best-in-class SaaS peers (Notion, Linear, Stripe, Vercel, Readwise, Raycast, Supabase) that already survive regulator scrutiny
Cite primary-source regulators (EDPB, ICO, CPPA, FTC, PPA, Google Limited Use policy) rather than blog paraphrases
Are internally consistent, prose-clean, and TypeScript-clean when rendered into the user's web app
Commit an audit trail to the repo so the next maintainer (human or AI) can diff against the reasoning

The skill also produces a follow-up punch list of code / UI changes the user should make to match what the docs now promise - consent flow positioning, email footer contents, data-export endpoint, cookie banner, opt-out handling, RLS checks, and so on. Producing the docs without the matching code changes creates liability drift; the skill is explicit about both.

When to use - stronger triggers

Trigger this skill BEFORE responding when any of these appear in the user's message:

"privacy policy", "terms", "ToS", "ToU", "privacy page", "legal pages", "compliance"
"GDPR", "CCPA", "CPRA", "COPPA", "UK GDPR", "Israel PPL", "ePrivacy", "CAN-SPAM"
"data processing agreement", "DPA", "DPIA", "sub-processor", "controller", "processor"
"cookie banner", "cookie policy", "consent flow", "consent banner"
"data retention", "breach notification", "right to erasure", "right to access", "portability"
"EU representative", "Article 27", "DPO", "data protection officer"
"Google Limited Use", "OAuth data policy", "Limited Use disclosure"
"accessibility", "a11y compliance", "WCAG", "ADA compliance"
Regulator names - EDPB, ICO, CNIL, DPC, CPPA, FTC, PPA, Garante

Skill should NOT trigger for: one-off document reads ("what does section 4 of Stripe's ToS say?"), legal-research questions ("what does Art. 6 GDPR require?") where the user is not working on their own docs, or pure factual lookups.

The Pipeline - Ten Phases

This skill runs as a deterministic orchestration. Do not skip phases. Do not shortcut. Run each phase in full before starting the next, with one exception: Phase 2 (research) and Phase 3 (code audit) and Phase 4 (peer benchmark) are mutually independent and MUST run in parallel for efficiency.

Phase 0 - Intake and scope

Ask the user, before writing any code or spawning agents, these FIVE questions (combine them into a single message):

Project identity. What is the product, what is the domain, where is the codebase, what tech stack is the legal surface (Next.js pages? a Jekyll site? a PDF? backend-only?).
Jurisdictions in scope. Where are they based, and where are their users? (US only? EU? UK? California? Israel? Global?) If unsure, default to: "business based in [country from git config or user], users possibly global" - and research the matching framework.
What exists today. Do they already have /privacy and /terms pages, or are we writing from scratch? Provide paths if any.
Real gaps vs. aspirational. What user-facing features exist but might be missing from the legal docs? What are they about to ship that will add new data flows? Prompt them to mention AI, payments, social bots, Chrome extensions, mobile apps, email marketing, analytics, etc.
Attorney review status. Do they already have a lawyer on retainer, or are they pre-attorney (most vibe coders)? The disclaimer text shipped in the final docs depends on this.

Save these answers to .compliance-auditor/intake.md in the user's repo. This file is the anchor for every downstream agent.

Phase 1 - Memory and prior-art lookup

Check whether the user already has project memory files (memory/MEMORY.md, CLAUDE.md, .claude/memory/) that the skill should load. Look specifically for:

Existing email addresses (DO NOT invent new mailboxes - the skill must use real ones)
Existing known sub-processors
Existing legal-docs-update rule (if this skill has run before)
Deployment region / controller location hints

If legal-docs-update-rule.md memory already exists from a prior run, load it and use as the baseline. If not, the skill will CREATE this memory at the end (see Phase 9).

Phase 2 - Primary-source legal research (agent A, parallel)

Dispatch a researcher subagent (Claude Code) or equivalent. Skills it should load: parallel-web-search, and WebFetch for primary-source reading. Instruct it to output specs/legal/research-<YYYY-MM-DD>.md with per-jurisdiction requirements + 2+ primary-source URLs per jurisdiction + any 2025/2026-specific changes. See references/orchestration.md for the full agent prompt template, and references/jurisdictions.md for the list of jurisdictions to research.

Phase 3 - Code data-practices audit (agent B, parallel with Phase 2)

Dispatch a code-analyzer or equivalent subagent to produce a factual inventory of the user's actual code. Use the 12-topic audit template in references/orchestration.md#phase-3. The audit MUST cite file:line for every claim. When the code does not clearly support a claim, the auditor says so - the drafter then uses honest hedging language rather than inventing behavior.

This step is what distinguishes the skill from every template generator on the market - we do not let the drafter assume behavior, we require evidence.

Phase 4 - Peer benchmark (agent C, parallel with Phase 2 and 3)

Dispatch a researcher subagent to reverse-engineer 5 peer SaaS policies most structurally similar to the user's product. See references/peer-benchmarking.md for a selection framework (match by content-shape, user-base region, AI exposure, OAuth posture, small-team pedigree). Output: specs/legal/benchmark-peers-<YYYY-MM-DD>.md with clause-level comparison + adopt-worthy-with-attribution + over-promise warnings.

Phase 5 - Draft (agent D, sequential, after 2+3+4 all complete)

Dispatch a coder subagent with the elements-of-style:writing-clearly-and-concisely skill loaded. Give it the three Phase-1 reports + the user's intake + the existing policy (if any) as input. Require it to:

Write ONLY what the code audit supports
Cite the research file for each jurisdictional claim
Use peer-benchmark phrasings as inspiration, not copy-paste
Use real contact emails (from intake / memory, never invented)
Preserve the user's project style conventions (style rules from CLAUDE.md)
Output into the user's actual page components (e.g. app/app/(public)/privacy/page.tsx for Next.js) AND mirror the can

compliance-auditor