Update to Rohas Legal AI: Privacy

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 329
    },
    {
      "relative_path": "references/project-code-audit.md",
      "size_in_bytes": 4708
    }
  ],
  "name": "privacy-policy-drafter",
  "skill_md_contents": "---\nname: privacy-policy-drafter\ndescription: >-\n  Draft and audit external privacy policies, collection notices, employee\n  notices, child-facing notices, just-in-time notices, and layered disclosures.\n  Use when notices must match verified processing, legal bases, sharing,\n  transfers, retention, automated decisions, rights, and contact routes,\n  including when Codex should inspect a website or application project and\n  derive the processing inventory from its code, configuration, and dependencies.\n---\n\n# Privacy Policy Drafter\n\nDraft from a verified data inventory and user journey, not a generic template.\nA notice describes processing; it does not itself create a lawful basis or consent.\n\n## Source selection\n\n1. Check the current Codex workspace before requesting a URL or questionnaire.\n2. If it contains website or application code, use project mode. Read\n   [references/project-code-audit.md](references/project-code-audit.md) completely,\n   inspect the project repository-wide, and derive an evidence-backed processing\n   inventory. Do not ask for a URL unless no relevant code is available or the\n   user wants deployed behaviour compared with the project.\n3. If the workspace does not contain relevant code, use document or URL mode and\n   obtain the data inventory from supplied materials, the deployed service, and\n   targeted questions.\n4. Treat code as evidence of implemented capability, not proof of every production\n   practice. Separate confirmed facts, supported inferences, and unresolved facts.\n\n## Intake\n\nDerive as much as possible from the available project or source materials before\nasking questions. Then obtain only the unresolved audience and jurisdictions,\norganisation and roles, products and channels, data categories and sources,\npurposes, legal bases or permissions, cookies and tracking, profiling and automated\ndecisions, recipients, sale or sharing concepts, transfers, retention, children,\nsecurity, rights, appeals, complaints, contact channels, prior versions, effective\ndate, and change process.\n\n## Drafting method\n\n1. Define each notice's audience, collection context, controller or fiduciary,\n   scope, language, accessibility, delivery point, and relationship to other notices.\n2. Map every disclosed data category to its source, purpose, legal basis or\n   permission, recipient, transfer, retention rule, and rights impact.\n3. Name categories in language meaningful to the audience; distinguish provided,\n   observed, device, transaction, third-party, generated, and inferred data.\n4. Explain purposes specifically enough to understand consequences. Separate\n   service delivery, security, legal compliance, analytics, personalisation,\n   advertising, research, and model training where applicable.\n5. Describe recipients and onward use accurately, including processors,\n   affiliates, partners, authorities, transaction counterparties, and public disclosure.\n6. Explain international transfers, applicable safeguards, and how to obtain\n   information where law requires.\n7. State retention periods or useful criteria by data and purpose, including\n   account closure, backups, disputes, legal holds, and deletion or de-identification.\n8. Explain profiling, consequential automated decisions, human review, logic or\n   significance where required, and available choices.\n9. Present rights, withdrawal, objection, appeal, grievance, complaint, authorised\n   agent, verification, accessibility, and response routes without deterring use.\n10. Add child, employee, sensitive-data, cookie, mobile, camera, biometric, or\n    other contextual disclosures only when the processing exists.\n11. Cite project file paths and relevant implementation evidence in the working\n    inventory, but keep source-code citations out of the public-facing notice.\n12. Validate the draft with product, engineering, security, HR, marketing,\n    procurement, support, and records owners before publication.\n\n## Output\n\nProvide the layered notice, short or just-in-time text, disclosure-to-inventory\nmatrix, unresolved fact list, localisation plan, publication checklist, version\nrecord, and review triggers. In project mode, also provide the code-evidence\ninventory and save or update the requested policy artifact in the project. If no\npath is specified, choose a conventional documentation or site-content location,\navoid overwriting an existing policy without reviewing it, and report the path.\n\n## Guardrails\n\nDo not copy unsupported practices, promise absolute security, use blanket consent,\nhide material processing, or say data is never shared when processors receive it.\nAvoid dark patterns and vague future-use clauses. Verify current jurisdictional\nnotice content, language, timing, and accessibility rules before publication.\nDo not expose secrets or personal data found in project files. Do not infer actual\nproduction use, vendor contract terms, hosting location, retention periods, or\norganisational identity solely from an integration, environment-variable name, or\nunused code path. Mark such matters for confirmation and use conspicuous placeholders\nwhen the user asks for a draft before they are resolved.\n"
}