| name | privacy-policy |
| version | 3.0.0 |
| description | Draft a jurisdiction-aware privacy policy for any digital product — use this skill whenever a PMM or Product Manager needs to create, update, audit, or review data protection documentation, asks about GDPR, CCPA, or UK GDPR obligations, mentions "privacy policy", "cookie policy", "data retention", "right to be forgotten", "data processing agreement", or asks what their product needs to comply with applicable privacy law. |
| metadata | {"author":"Stefanos Karakasis","context":"context-agnostic","quality_gate":false} |
| last_updated | 2026-08-24T00:00:00.000Z |
privacy-policy
A drafting engine for PMMs and Product Managers who need a rigorous, jurisdiction-aware
privacy policy ready for legal review — not a generic template.
The contract of this skill: this skill drafts. It does not certify.
Every output is a structured first draft requiring qualified legal review before publication.
High-risk clauses are marked [⚠️ LEGAL REVIEW REQUIRED] throughout — always.
Trigger
- When: Creating, updating, auditing, or reviewing a privacy policy or other data protection documentation, or answering what a product needs to comply with applicable privacy law.
- Not for: n.v.t. — this skill has no overlap with another skill in this stack; overlap was considered and there is none.
- Example prompts:
- "Draft a privacy policy"
- "Are we GDPR compliant?"
- "Update our cookie policy"
- "Review our data retention policy"
- "What does our product need for CCPA compliance?"
Inputs
- Args: Product name, company legal name and address, privacy contact, user location(s), data types collected, third-party tools in use, and optionally an existing policy to refresh. Free format — Step 1 (Intake) fills gaps conversationally.
- Defaults: If the user skips intake, default to broadest jurisdiction coverage and flag all inferred inputs.
- Context keys:
/foundation/brain.md — optional. Product name/description, company name/address, primary market, data types, and ICP can all be inferred from it.- Brain contract: Reads brain content opportunistically (no fixed section numbers — this skill infers from whatever's present). Writes: none.
Pre-flight
Read /foundation/brain.md if available. Extract silently:
- Product name and description
- Company name and registered address
- Primary market / geographic focus → infer likely jurisdiction(s)
- Data types mentioned in the product description
- ICP → infer B2C vs B2B exposure
If missing, proceed without it and collect everything through Intake instead.
Even with brain context loaded, surface what was inferred and require explicit
confirmation in Step 1. Legal documents cannot be built on silent assumptions.
Steps
Step 1: Intake
Present as a single message — not a question drip.
"I've loaded your product context. Before I draft, verify or correct these — legal
documents can't rely on inferences.
Which product is this policy for? [Pre-fill or blank]
Company legal name and registered address: [Pre-fill or blank]
Privacy contact email (e.g. privacy@company.com):
Who are your users? Consumers (B2C), businesses (B2B), or both?
[Pre-fill from ICP if found — flagged as inferred]
Where are your users located? (determines which laws apply)
EU/EEA → GDPR · UK → UK GDPR + PECR · California → CCPA/CPRA · Multiple → all applicable
[Pre-fill from market context — flagged as inferred, not confirmed]
What data does your product collect? Check all that apply:
Names and emails · Passwords / credentials · Usage behaviour and analytics ·
Device identifiers and IP addresses · Location data · Payment information ·
Health or biometric data [⚠️ special category] · Children's data [⚠️ COPPA/GDPR-K]
Anything else?
[Pre-fill from product description where inferrable — flagged as inferred]
Third-party tools in use? Analytics, payments, CRM, email, ads, SSO — list them.
These determine your processor obligations.
Existing policy? Paste it or describe what changed — I'll diff rather than start over."
If the user provides an existing policy → REFRESH mode.
If the user provides a brain dump → DRAFT mode from their inputs.
If the user skips intake → default to broadest jurisdiction coverage; flag all inferred inputs.
Step 2: Jurisdiction Baseline
Derive applicable laws from confirmed inputs — never assume. Apply the relevant
baseline below. These are the core obligations to draft from; treat every specific
period, threshold, or right listed as a candidate to confirm or correct with the
user, not a fact to state unflagged in the final policy.
| User location | Primary law | Core obligations to reflect |
|---|
| EU / EEA | GDPR | Lawful basis for each processing activity; data subject rights (access, rectification, erasure, portability, restriction, objection); DPO required above certain processing thresholds (Art. 37); breach notification to the supervisory authority within 72 hours; cross-border transfer mechanism (SCCs or adequacy) for any non-EEA processor. |
| UK | UK GDPR + PECR | Same core rights as GDPR, enforced by the ICO; PECR governs cookies and direct electronic marketing consent separately from the general lawful-basis regime; UK IDTA or the UK Addendum to SCCs for cross-border transfers. |
| California | CCPA / CPRA | Right to know, delete, correct, and opt out of sale/sharing of personal information; "Do Not Sell or Share My Personal Information" link required if applicable; look-back disclosure of categories collected in the past 12 months; opt-out for sensitive personal information processing. |
| US (other states) | VCDPA, CPA, TDPSA, CTDPA, and similar | Broadly CCPA-adjacent: access, deletion, correction, opt-out of targeted advertising/sale, and (in several states) opt-out of profiling with legal effect. Thresholds and exact rights vary by state — flag as [⚠️ LEGAL REVIEW REQUIRED] rather than asserting exact scope. |
| Canada | PIPEDA / Law 25 (QC) | Consent-based collection, meaningful purpose limitation, breach reporting to the Privacy Commissioner where real risk of significant harm exists; Law 25 adds Quebec-specific consent and cross-border transfer assessment requirements. |
| Australia | Privacy Act + APPs | 13 Australian Privacy Principles covering collection, use, disclosure, access, and correction; notifiable data breach scheme for eligible breaches. |
| Global / Multi | All above | Use GDPR as the floor (it is the strictest baseline) and layer jurisdiction-specific rights (e.g. CCPA's "sale/share" opt-out) as additional sections rather than separate policies where feasible. |
Industry overlays — apply silently when relevant:
| Product type | Additional obligations |
|---|
| FinTech / Payments | PSD2 data obligations, PCI-DSS, FCA breach notification (UK) |
| Health data | HIPAA (US), GDPR Article 9 special category, NHS DSPT (UK) |
| Children | COPPA (US), GDPR Article 8 age of consent (13–16 by member state), UK Children's Code |
| HR / employee data | Additional GDPR lawful basis requirements |
| B2B only | Reduced consumer-rights exposure; processor obligations remain |
Every obligation in these tables is a drafting starting point, not confirmed law for
the user's specific situation — tag any clause built from this baseline [M] (model
knowledge, not a loaded authoritative source) and mark it [⚠️ LEGAL REVIEW REQUIRED].
Step 3: Select Operating Mode
| Mode | Trigger | Output |
|---|
| DRAFT | New policy from scratch | Full three-part output |
| REFRESH | Existing policy provided | Diff: legal changes + redlined clauses |
| AUDIT | "Review our policy" / "are we compliant" | Gap analysis + prioritised fix list |
| CLAUSE | "Write the cookie section" / "draft our retention policy" | Single section with alternatives |
| LEARN | "Our lawyer flagged X" / "legal said we need Y" | Legal feedback surfaced back to the user for their own records |
Default: DRAFT.
Step 4: Draft the Twelve-Section Policy Architecture
Draft every DRAFT and REFRESH policy in this order. This is the baseline structure —
adapt section depth to what Step 1 and Step 2 actually surfaced, and drop a section
only if it is genuinely inapplicable (state why, briefly, rather than deleting silently).
- Overview and scope — who this policy covers, what product/service it applies to.
- Data we collect — every data type from Intake, organized by collection method
(provided directly, collected automatically, received from third parties).
- How we use your data — purpose for each data type, tied to a lawful basis
(GDPR) or business purpose (CCPA).
- Legal basis for processing (GDPR/UK GDPR jurisdictions only) — consent,
contract, legitimate interest, legal obligation, vital interest, or public task,
named per processing activity.
- Cookies and tracking technologies — categories used (strictly necessary,
functional, analytics, advertising), consent mechanism, link to cookie settings.
- Third-party sharing and processors — every named third party from Intake,
what data they receive, and why. Never describe processors generically.
- International data transfers — named transfer mechanism (SCCs, UK IDTA,
adequacy decision) for every processor outside the user's primary jurisdiction.
- Data retention — a stated period or deletion trigger per data type. Every
period gets
[⚠️ LEGAL REVIEW REQUIRED] — no exceptions.
- Your rights — the specific rights from the Step 2 baseline for the user's
confirmed jurisdiction(s), plus how to exercise each one.
- Security measures — a general, honest description of safeguards in place.
Never overstate; never make an unverifiable claim (e.g. "military-grade").
- Children's data — state whether the product is directed at children; if
special-category handling applies, flag it explicitly.
- Changes to this policy and contact information — how updates are
communicated, plus the confirmed privacy contact from Intake.
Step 5: Follow the Drafting Protocol
Follow this sequence — it prevents confident-sounding errors.
- Confirm all inputs are verified, not inferred.
- Apply the Step 2 jurisdiction baseline for every confirmed location.
- Identify special categories and industry overlays.
- List every named third-party processor before drafting Section 6 of the policy.
- Draft all twelve sections from Step 4, in order.
- Run self-audit (Step 8) — all four layers must pass before output.
- Deliver three-part output (Step 6).
- Run the legal feedback check (Step 9).
The specificity rule — apply to every clause:
❌ "We use your data to improve our services."
✅ "We analyse session recordings and feature usage logs to identify friction in onboarding flows and prioritise product improvements. This is based on our legitimate interest in improving the product experience. [⚠️ LEGAL REVIEW REQUIRED]"
If a clause could appear in any product's privacy policy unchanged, rewrite it.
Step 6: Deliver Output Format
Deliver in three parts every session, every mode.
Part 1 — Intake Confirmation
PRODUCT: [name — confirmed]
COMPANY: [legal name — confirmed]
JURISDICTIONS: [list — confirmed vs ⚠️ inferred]
DATA TYPES: [confirmed list]
THIRD PARTIES: [named list]
SPECIAL CATEGORIES: [Yes — type / No]
INFERRED INPUTS: [anything not explicitly confirmed — flagged]
MODE: [DRAFT / REFRESH / AUDIT / CLAUSE / LEARN]
Part 2 — Full Policy Document
Complete, ready-to-send-to-legal policy using the twelve-section architecture in
Step 4. Write in plain English. No legalese. Define technical terms on first use.
Every [⚠️ LEGAL REVIEW REQUIRED] marker visible inline.
Part 3 — Compliance Notes and Next Steps
- Summary of every
[⚠️ LEGAL REVIEW REQUIRED] clause and why it needs legal attention
- Jurisdiction-specific obligations that require action, not just documentation
- Third-party DPA checklist
- Technical tasks: consent management, deletion flows, breach notification procedure
- Pre-publish checklist:
Step 7: Apply Hard Rules
Never present output as a finished legal document.
The disclaimer is mandatory. Remove or soften it at user request: not permitted.
Never draft without confirmed product identity.
The user must name the specific product before any clause is written.
Never auto-populate jurisdiction silently.
Pre-fill and flag. A policy written for the wrong jurisdiction is worse than no policy.
Never state a retention period without flagging it for legal review.
Retention periods are a primary enforcement target. Every stated period gets
[⚠️ LEGAL REVIEW REQUIRED] — no exceptions.
Never describe third-party processors generically.
Name them, or state "processors are listed at [URL]" with a maintained live list.
Never present the Step 2 baseline as confirmed law for the user's situation.
It is model knowledge ([M]), not a verified legal source. Flag every clause drawn
from it.
Step 8: Run Self-Audit
Run internally before producing any output. All four layers must pass.
Layer 1 — Input integrity
Any inputs still inferred rather than confirmed? Disclosed in Part 1?
Layer 2 — Jurisdiction coverage
All applicable laws covered? Cross-border transfers addressed for every named processor?
Every relevant user right included per confirmed jurisdiction?
Layer 3 — Specificity
Every clause product-specific? Retention periods concrete? All processors named?
Layer 4 — Legal flag completeness
Every high-risk clause marked [⚠️ LEGAL REVIEW REQUIRED]?
All special category clauses flagged?
Only after all four layers pass: produce output.
Step 9: Legal Feedback Check
Run at end of every session, after output delivered and audit passed. This is
a bespoke feedback loop for this skill only — distinct from the repo's
standard Learning Close (Section 5.1 of SKILL-SPEC.md), which does not
apply here since this is a T3 skill with quality_gate: false. This step
never writes to /context/skill-sessions.md or any other file on its own.
Why this matters
A clause that reads well can still get flagged by a data protection authority.
The skill cannot infer legal quality from silence — learning only fires when the
user explicitly reports legal outcomes.
Prompt the user before closing:
"Before I close — did your lawyer flag anything in a previous policy review,
or do you have feedback from a legal or compliance review?
Even a quick note helps me apply the right pattern next time."
If the user reports feedback, treat it as a signal for this session and any
future one you draft for them — but do not write it to any file on your own. If they
want it saved, ask where (their own notes, or a brain-adjacent doc they maintain)
and let them confirm the destination.
| User input | How to use it this session |
|---|
| "Our lawyer flagged [clause]" | Treat as a known risk area — apply extra scrutiny to that clause type for the rest of this draft and any future one. |
| "Legal said [X] needed to be added / removed / reworded" | Apply the correction now; note it back to the user as a pattern worth remembering. |
| "This draft got approved unchanged" | Good signal — keep using the same structure for that clause type. |
| "We were fined / audited about [X]" | Highest priority — treat that clause area as [⚠️ LEGAL REVIEW REQUIRED] even where it wouldn't otherwise be flagged, for the rest of this engagement. |
Step 10: Ecosystem Integration
| Upstream | This skill | Downstream |
|---|
product-marketing-context → product, market, ICP | privacy-policy | Legal review → published policy |
| User confirms data types and jurisdiction | | gaccs-brief if policy change triggers comms |
If product context changes — new market, new data type, new feature:
→ Re-run in REFRESH mode.
Outputs
- Files written: None — this skill does not write to
/context/skill-sessions.md
or any other file on its own. If the user wants a policy or its notes saved
anywhere, ask where.
- Chat output format: Three-part output every session — Intake
Confirmation, Full Policy Document, and Compliance Notes and Next Steps
(Step 6).
- External side effects: None.
Verification
- All inputs confirmed or explicitly flagged as inferred (Part 1 of output).
- Jurisdiction baseline applied for every confirmed location, with
[M] and [⚠️ LEGAL REVIEW REQUIRED] tags on every clause drawn from it.
- Self-Audit (Step 8) passed on all four layers before output was produced.
- Every retention period and high-risk clause carries
[⚠️ LEGAL REVIEW REQUIRED].
- Disclaimer present and not softened or removed at user request.
Do Not Use For
- n.v.t. — this skill has no overlap with another skill in this stack; overlap was considered and there is none.
