Privacy Policy Drafting skill for Codex
A policy that matches what the code collects. Codex builds the privacy policy from evidence instead of a template: it scans dependencies, page scripts, database schemas, cookies and vendor keys to inventory every personal data flow, maps purpose, legal basis, recipients and retention, then drafts plain-language sections against GDPR, UK GDPR and CCPA disclosure checklists. Mismatches between code and policy are reported as findings, and the draft is labelled for legal review.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- privacy-policy-draftingInstalls to ~/.agents/skills/privacy-policy-drafting/ for every project on this machine.
curl -fsSL codexskills.dev/cli.mjs -o codex-skills.mjsnode codex-skills.mjs install privacy-policy-draftingThe CLI also searches, updates and removes skills. Run it with no arguments to pick from a list. Needs Node 20.12+.
curl -fsSL codexskills.dev/install.sh \ | sh -s -- --project privacy-policy-draftingInstalls to .agents/skills/privacy-policy-drafting/ in the current repository. Commit it and everyone who runs Codex there gets it.
curl -fsSLO codexskills.dev/downloads/privacy-policy-drafting.zipunzip -o privacy-policy-drafting.zip -d ~/.agents/skills/The archive holds the skill folder with its generated agents/openai.yaml. Unzip into .agents/skills/ to scope it to a repo.
& ([scriptblock]::Create((irm codexskills.dev/install.ps1))) privacy-policy-draftingPowerShell 5.1 or 7. Installs to %USERPROFILE%\.agents\skills\. Add -Project for the current repo.
104-line POSIX script. No sudo, no telemetry. Read install.sh
Use it in Codex
Start a prompt with $privacy-policy-drafting, or pick it from /skills.
You can also just describe the task: Codex reads the description below and loads the playbook when your request matches.
What Codex reads before loading it
Drafts and updates website and app privacy policies from the product's real data flows - inventories personal data by scanning code, schemas, SDKs, cookies and vendors, maps purposes, legal bases, recipients and retention, then writes a plain-language policy covering GDPR, UK GDPR, CCPA/CPRA and other US state disclosure items. Not legal advice. Use when asked to write or update a privacy policy, check a policy against what the app actually collects, add a new analytics or AI vendor, or prepare a data inventory for counsel.
Use it when
- Launching a site or app that collects personal data and needs a policy
- Adding analytics, ad pixels, AI providers or other vendors that receive user data
- The existing policy has not been reviewed in over a year
- Counsel asked for a data inventory before drafting
Use something else when
- You need consent gating, retention jobs or DSAR tooling built in code: use gdpr-privacy-engineering
- You are reviewing a vendor's DPA or contract terms: use contract-review-checklist
How to check the result
Every row of the data inventory maps to a policy section, every vendor found in code appears in the sharing section, and consent-based scripts are confirmed not to load before consent.
The mistake it prevents
Stating 'we never sell your data' while an ad pixel shares identifiers for cross-context advertising, which CCPA treats as sharing that must be disclosed with an opt-out.
A privacy policy is correct when every statement matches what the product actually does: every category of personal data collected appears, every vendor that receives it is covered, every purpose is real, and nothing the code does is missing. A beautiful policy that contradicts the code is worse than none, because regulators enforce the promises a company makes.
Every output must say: “Draft for legal review. Not legal advice. Have a privacy lawyer review before publishing, especially for children’s data, health, financial or biometric data, or sales of personal data.” Publishing the policy is outward-facing; confirm with the user before replacing a live policy.
Workflow
- Read the existing policy, terms, cookie banner config and
AGENTS.mdnotes - Build the data inventory from the code and vendors (below)
- Confirm the inventory with the user: what is collected outside the code (support inbox, sales calls, events, offline forms)?
- Determine which laws likely apply (table below) and confirm with the user
- Draft the policy section by section from the inventory
- Run the consistency check: every inventory row appears in the policy and vice versa
- Deliver the draft, the inventory and open questions for counsel
Build the data inventory from the code
Search for collection points and recipients:
# Third-party SDKs and services in dependencies
rg -n --glob 'package.json' --glob 'requirements*.txt' --glob 'pyproject.toml' --glob 'Gemfile' \
-i 'analytics|segment|posthog|mixpanel|amplitude|sentry|datadog|intercom|hubspot|stripe|twilio|sendgrid|mailchimp|openai|anthropic|hotjar|clarity|gtag|facebook|tiktok|linkedin'
# Scripts and pixels injected into pages
rg -n -i '<script[^>]+src=|gtag\(|fbq\(|dataLayer' --glob '*.{html,tsx,jsx,vue,svelte,astro,erb,php}'
# Personal-data fields in schemas and models
rg -n -i '\b(email|phone|address|birth|dob|ssn|ip_address|ip|location|lat|lng|gender|passport|card)\b' \
--glob '*.{sql,prisma,rb,py,ts}' | rg -i 'column|field|model|create table|schema'
# Cookies and local storage
rg -n -i 'document\.cookie|set-cookie|localStorage|sessionStorage|cookies\.set'
# Secrets naming vendors (names only; never print values)
rg -n -o '^[A-Z0-9_]*(KEY|TOKEN|SECRET|DSN)[A-Z0-9_]*' .env.exampleAlso check server logs (IP addresses, user agents), backups, support tooling, email providers, payment processors, and any AI or LLM API that receives user content.
Record each flow as one row:
| Data category | Examples | Source | Purpose | Legal basis (EU/UK) | Recipients / vendors | Location / transfer | Retention | Sold or shared for ads? |
|---|---|---|---|---|---|---|---|---|
| Account data | name, email, password hash | user signup | provide account | contract | AWS (hosting) | US; SCCs | life of account + 30 days | no |
| Usage analytics | page views, device, IP | SDK | product improvement | consent | PostHog | EU | 12 months | no |
| Ad conversion data | hashed email, click id | Meta pixel | ad measurement | consent | Meta | US | per vendor | yes (sharing under CCPA) |If the user cannot answer retention, write “[RETENTION - TO CONFIRM]”; never invent a period.
Which rules likely apply
Applicability depends on facts counsel must confirm. Use this to decide which disclosure sets to include:
| Situation | Likely in scope |
|---|---|
| Users or customers in the EU/EEA, or monitoring their behaviour | GDPR |
| Users in the UK | UK GDPR and the Data Protection Act 2018 |
| California consumers and the business meets a CCPA threshold (revenue above roughly $25M adjusted for inflation, 100,000+ consumers or households, or half of revenue from selling/sharing data) | CCPA as amended by CPRA |
| Any commercial site collecting personal information from California residents | CalOPPA (posting a policy, Do Not Track disclosure) |
| Consumers in other US states with general consumer privacy laws (Virginia, Colorado, Connecticut, Texas, Oregon and many more) | Their thresholds vary; most require an appeal process |
| Service directed at children under 13, or actual knowledge of collecting from them | COPPA, which needs specialist review |
| EU/UK cookies or trackers that are not strictly necessary | Consent before setting (ePrivacy / PECR) |
For the required disclosure items per law, read references/disclosure-requirements.md when drafting the corresponding sections.
Policy structure
- Who we are and how to contact us (legal entity name, address, privacy email, DPO or EU/UK representative if required)
- Scope (which sites, apps and services; what it does not cover)
- Personal data we collect, grouped by source: you provide, collected automatically, from third parties
- How we use it, with the legal basis for each purpose (EU/UK)
- Cookies and similar technologies (link to cookie policy or table)
- How we share it: categories of recipients, named key vendors or a sub-processor list link, sale or sharing for targeted advertising
- International transfers and safeguards
- Retention, by category
- Your rights and how to exercise them, verification, authorised agents, appeals
- Security (describe measures at a high level; do not promise “complete security”)
- Children
- Region-specific sections (for example “California residents”) where needed
- Changes to this policy, and effective / last updated date
Writing rules
- Plain language, second person (“you”, “we”), short sentences. Target a reading level a general audience can follow.
- Specific beats vague: “we use PostHog to measure which features are used” rather than “we may use third-party tools to improve our services”.
- Do not write “we never sell your data” if any ad pixel or data-sharing for cross-context behavioural advertising exists; under CCPA that sharing must be disclosed and opt-out offered.
- Do not copy another company’s policy. It describes their data flows, not these.
- Keep the policy consistent with the cookie banner, the consent records and the DPA offered to business customers.
Consistency check
- Every inventory row maps to a section of the policy
- Every vendor in the code appears in the sharing section or sub-processor list
- Every purpose in the policy is actually performed
- Consent-based processing (analytics, ads) is actually gated by the consent banner; check that scripts do not load before consent where consent is required
- Rights requests have a working channel (email or form) and someone who handles it
- Effective date updated; previous version archived
Report any mismatch between code and policy as a finding for engineering, not just a wording change. Engineering fixes for gaps (consent gating, retention jobs, DSAR tooling) belong to the gdpr-privacy-engineering skill.
Gotchas
- Session replay and heatmap tools capture form contents and screen text unless masked. Check masking configuration before describing them.
- Sending user content to an LLM provider is a disclosure to a processor and often an international transfer. Cover it, and check the vendor’s data-retention and training terms.
- IP addresses and device identifiers are personal data under GDPR.
- “Last updated” dates that never change signal neglect; CCPA requires review at least every 12 months.
- Mobile apps also need App Store privacy labels and Google Play Data safety forms; they must match the policy.
Output
> Draft for legal review. Not legal advice.
1. Data inventory table (as above)
2. Draft policy (markdown, ready for counsel)
3. Code vs policy mismatches found: <list, each with file path>
4. Open questions for counsel: <applicability, legal bases, transfers, children, sale/share>
5. Placeholders still to fill: <list>What the zip contains
Codex reads bundled files only when a step points to them. Every one is shown here, so you can review it before installing.
agents/openai.yaml
Gives the Codex app a display name, a one-line description and a starter prompt for this skill.
interface:
display_name: "Privacy Policy Drafting"
short_description: "A policy that matches what the code collects"
default_prompt: "$privacy-policy-drafting Write a privacy policy for our Next.js SaaS based on what the code actually collects"references/disclosure-requirements.md
# Disclosure requirements by law
Checklists of what a privacy notice typically must contain. They summarise the
requirements to help structure a draft; the statutes, regulations and regulator guidance
govern, and counsel confirms applicability and wording. Laws change; note the date you
relied on this list in the open-questions section of the output.
## GDPR / UK GDPR - data collected from the person (Article 13)
- [ ] Identity and contact details of the controller (and EU or UK representative if the
controller is established outside and the representative rule applies)
- [ ] Contact details of the data protection officer, where one is appointed
- [ ] Purposes of processing and the legal basis for each purpose
- [ ] The legitimate interests pursued, where legitimate interests is the basis
- [ ] Recipients or categories of recipients
- [ ] Transfers to third countries and the safeguard used (adequacy decision, Standard
Contractual Clauses, UK IDTA or Addendum) and how to obtain a copy
- [ ] Retention period, or the criteria used to determine it
- [ ] Rights: access, rectification, erasure, restriction, objection, data portability
- [ ] Right to withdraw consent at any time, where consent is the basis
- [ ] Right to complain to a supervisory authority (UK: the ICO)
- [ ] Whether providing the data is a statutory or contractual requirement or necessary
to enter a contract, and the consequences of not providing it
- [ ] Automated decision-making including profiling with legal or similarly significant
effects: meaningful information about the logic, significance and consequences
## GDPR - data obtained from elsewhere (Article 14) adds
- [ ] Categories of personal data concerned
- [ ] The source of the data, and whether it came from publicly accessible sources
## Cookies and trackers (EU ePrivacy rules, UK PECR)
- [ ] Consent before setting non-essential cookies or similar technologies
- [ ] Clear information about each category (strictly necessary, preferences, analytics,
advertising), the provider, and duration
- [ ] Withdrawing consent as easy as giving it (a persistent way to reopen settings)
## California - CCPA as amended by CPRA (privacy policy content)
- [ ] Categories of personal information collected in the preceding 12 months
- [ ] Categories of sources
- [ ] Business or commercial purposes for collecting, selling or sharing
- [ ] Categories of third parties to whom personal information is disclosed
- [ ] Categories sold or shared in the preceding 12 months, and to which categories of
third parties; or a statement that none are sold or shared
- [ ] Whether the business has actual knowledge that it sells or shares personal
information of consumers under 16
- [ ] Sensitive personal information categories collected, and whether it is used or
disclosed for purposes beyond those permitted (which triggers "Limit the Use")
- [ ] Retention period for each category, or the criteria used
- [ ] Consumer rights: know/access, delete, correct, opt out of sale or sharing, limit use
of sensitive personal information, and non-discrimination for exercising rights
- [ ] Methods for submitting requests (at least two designated methods for most
businesses; email-only is allowed for online-only businesses with a direct
relationship), how requests are verified, and how authorised agents can act
- [ ] How opt-out preference signals such as Global Privacy Control are processed
- [ ] Notice of financial incentive, if loyalty or discount programmes use personal data
- [ ] Date last updated; review and update at least once every 12 months
- [ ] Larger data handlers have additional metrics-reporting duties; flag for counsel
Separate requirements: a "Do Not Sell or Share My Personal Information" link (or an
alternative opt-out link) when selling or sharing; a "Limit the Use of My Sensitive
Personal Information" link when applicable; a notice at collection.
## CalOPPA (California Online Privacy Protection Act)
- [ ] Categories of personally identifiable information collected and categories of third
parties shared with
- [ ] How users can review and request changes, if offered
- [ ] How the policy notifies users of material changes, and its effective date
- [ ] How the site responds to Do Not Track signals, and whether third parties may collect
information about users' online activities over time and across sites
## Other US state consumer privacy laws (common pattern)
Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and a growing list of other
states have laws with differing thresholds. Their privacy notice requirements commonly
include:
- [ ] Categories of personal data processed, including sensitive data
- [ ] Purposes of processing
- [ ] Categories of personal data shared with third parties, and categories of third parties
- [ ] Consumer rights (access, correction, deletion, portability, opt out of targeted
advertising, sale and certain profiling) and how to exercise them
- [ ] How to appeal a decision on a rights request (most of these laws require an appeal
process; CCPA does not)
- [ ] Whether data is sold or used for targeted advertising, and how to opt out
- [ ] Consent for processing sensitive data in states that require opt-in
Check each state the business operates in; thresholds are usually based on the number of
residents whose data is processed, with lower thresholds when data is sold.
## Children (US COPPA)
Applies to services directed to children under 13 or with actual knowledge of collecting
their personal information. The FTC amended the COPPA Rule in 2025, with compliance
required from 2026. Requirements include verifiable parental consent, a specific direct
notice to parents, data minimisation and retention limits, and a written security
programme. Do not draft a COPPA notice without specialist review; recommend counsel.
## Sector-specific triggers to flag for counsel
- Health data (HIPAA covered entities and business associates; Washington My Health My
Data Act and similar consumer health data laws)
- Financial data (GLBA privacy notices)
- Biometric data (Illinois BIPA and similar)
- Education records (FERPA), student data laws
- Employee and applicant data (separate notices are often needed)
About this skill
Written and maintained by the Codex Skills editors to the same editorial standard as every skill here: a selective description, a real workflow, known pitfalls and a way to verify the work. First published , last updated . MIT licensed. Something wrong or out of date? Tell us.