skills/privacy-policy-drafter/SKILL.md

---
name: privacy-policy-drafter
description: >-
  Draft and audit external privacy policies, collection notices, employee
  notices, child-facing notices, just-in-time notices, and layered disclosures.
  Use when notices must match verified processing, legal bases, sharing,
  transfers, retention, automated decisions, rights, and contact routes,
  including when Codex should inspect a website or application project and
  derive the processing inventory from its code, configuration, and dependencies.
---

# Privacy Policy Drafter

Draft from a verified data inventory and user journey, not a generic template.
A notice describes processing; it does not itself create a lawful basis or consent.

## Source selection

1. Check the current Codex workspace before requesting a URL or questionnaire.
2. If it contains website or application code, use project mode. Read
   [references/project-code-audit.md](references/project-code-audit.md) completely,
   inspect the project repository-wide, and derive an evidence-backed processing
   inventory. Do not ask for a URL unless no relevant code is available or the
   user wants deployed behaviour compared with the project.
3. If the workspace does not contain relevant code, use document or URL mode and
   obtain the data inventory from supplied materials, the deployed service, and
   targeted questions.
4. Treat code as evidence of implemented capability, not proof of every production
   practice. Separate confirmed facts, supported inferences, and unresolved facts.

## Intake

Derive as much as possible from the available project or source materials before
asking questions. Then obtain only the unresolved audience and jurisdictions,
organisation and roles, products and channels, data categories and sources,
purposes, legal bases or permissions, cookies and tracking, profiling and automated
decisions, recipients, sale or sharing concepts, transfers, retention, children,
security, rights, appeals, complaints, contact channels, prior versions, effective
date, and change process.

## Drafting method

1. Define each notice's audience, collection context, controller or fiduciary,
   scope, language, accessibility, delivery point, and relationship to other notices.
2. Map every disclosed data category to its source, purpose, legal basis or
   permission, recipient, transfer, retention rule, and rights impact.
3. Name categories in language meaningful to the audience; distinguish provided,
   observed, device, transaction, third-party, generated, and inferred data.
4. Explain purposes specifically enough to understand consequences. Separate
   service delivery, security, legal compliance, analytics, personalisation,
   advertising, research, and model training where applicable.
5. Describe recipients and onward use accurately, including processors,
   affiliates, partners, authorities, transaction counterparties, and public disclosure.
6. Explain international transfers, applicable safeguards, and how to obtain
   information where law requires.
7. State retention periods or useful criteria by data and purpose, including
   account closure, backups, disputes, legal holds, and deletion or de-identification.
8. Explain profiling, consequential automated decisions, human review, logic or
   significance where required, and available choices.
9. Present rights, withdrawal, objection, appeal, grievance, complaint, authorised
   agent, verification, accessibility, and response routes without deterring use.
10. Add child, employee, sensitive-data, cookie, mobile, camera, biometric, or
    other contextual disclosures only when the processing exists.
11. Cite project file paths and relevant implementation evidence in the working
    inventory, but keep source-code citations out of the public-facing notice.
12. Validate the draft with product, engineering, security, HR, marketing,
    procurement, support, and records owners before publication.

## Output

Provide the layered notice, short or just-in-time text, disclosure-to-inventory
matrix, unresolved fact list, localisation plan, publication checklist, version
record, and review triggers. In project mode, also provide the code-evidence
inventory and save or update the requested policy artifact in the project. If no
path is specified, choose a conventional documentation or site-content location,
avoid overwriting an existing policy without reviewing it, and report the path.

## Guardrails

Do not copy unsupported practices, promise absolute security, use blanket consent,
hide material processing, or say data is never shared when processors receive it.
Avoid dark patterns and vague future-use clauses. Verify current jurisdictional
notice content, language, timing, and accessibility rules before publication.
Do not expose secrets or personal data found in project files. Do not infer actual
production use, vendor contract terms, hosting location, retention periods, or
organisational identity solely from an integration, environment-variable name, or
unused code path. Mark such matters for confirmation and use conspicuous placeholders
when the user asks for a draft before they are resolved.