privacy-policy-drafting
Draft privacy-policy language and a review checklist tailored to a business model, data practices, and relevant jurisdictions. Use when the user requests a privacy policy or needs to map disclosures for GDPR, CCPA, or similar frameworks; do not use it to guarantee legal compliance.
git clone --depth 1 https://github.com/seb1n/awesome-ai-agent-skills /tmp/privacy-policy-drafting && cp -r /tmp/privacy-policy-drafting/legal-and-compliance/privacy-policy-drafting ~/.claude/skills/privacy-policy-draftingSKILL.md
# Privacy Policy Drafting Draft legally informed privacy-policy language that addresses potentially applicable privacy frameworks and exposes unresolved business inputs. Treat the result as a working draft and review checklist, not proof of compliance. Verify current law, regulator guidance, product behavior, and jurisdiction with qualified counsel before publication. ## Workflow 1. **Gather Business Information** — Collect details about the business entity (name, jurisdiction, contact info), the product or service offered, target user demographics, and geographic reach. Determine which regulations apply based on where users are located, not just where the business is incorporated. A US-based SaaS serving EU customers must address GDPR. 2. **Identify Data Collection Practices** — Map every category of personal data collected: direct inputs (forms, account creation), automatic collection (cookies, analytics, device info, IP addresses), third-party sources (OAuth providers, data brokers), and derived data (usage patterns, preferences). For each category, document the collection method, storage location, retention period, and whether it includes sensitive/special category data. 3. **Map Legal Requirements** — Cross-reference collected data types against applicable frameworks. GDPR requires lawful basis for each processing activity, CCPA requires disclosure of sale/sharing practices and opt-out mechanisms, COPPA applies if users under 13 may access the service, and sector-specific rules (HIPAA, FERPA, GLBA) may layer additional requirements. Identify all required policy sections. 4. **Draft Policy Sections** — Generate each section with plain-language explanations alongside legally precise disclosures. Required sections include: data collected and purposes, legal basis for processing (GDPR), data sharing and third parties, cookies and tracking technologies, data retention, user rights and how to exercise them, international data transfers, children's privacy, security measures, and policy change notification procedures. 5. **Review for Compliance Gaps** — Audit the draft against a regulatory checklist. Verify that every data processing activity has a stated legal basis, all required rights are enumerated, contact information for DPO or privacy inquiries is included, cookie consent mechanisms are described, and data breach notification procedures are referenced. Flag any gaps or areas needing business input. ## Usage Describe your business, what data you collect, and which jurisdictions your users are in. Include technical details about cookies, analytics tools, and third-party integrations. **Example prompt:** ``` Draft a privacy policy for my SaaS app "TaskFlow" — a project management tool. We collect email, name, and usage analytics via Mixpanel. Users are in the US and EU. We use Stripe for payments and Google OAuth for login. ``` ## Examples ### Example 1: SaaS App with Email and Usage Data **Input:** TaskFlow, a project management SaaS. Collects email, name, profile photo, usage analytics (Mixpanel), payment info (Stripe), Google OAuth login. Users in US and EU. **Output (key sections):** **Information We Collect** *Information you provide:* When you create an account, we collect your name, email address, and profile photo (if provided via Google OAuth). When you subscribe to a paid plan, our payment processor Stripe collects your payment card details — we do not store full card numbers on our servers. *Information collected automatically:* We collect usage data including features accessed, session duration, and interaction patterns through Mixpanel. We collect device information (browser type, operating system, screen resolution), IP address, and approximate location derived from IP. We use cookies and similar technologies as described in our Cookie Policy section below. *Information from third parties:* If you sign in via Google OAuth, we receive your name, email, and profile photo from Google per your Google account settings. **Legal Basis for Processing (EEA/UK Users)** | Processing Activity | Legal Basis | |---------------------|-------------| | Account creation and service delivery | Performance of contract | | Payment processing | Performance of contract | | Usage analytics for product improvement | Legitimate interest (improving service quality) | | Email notifications about your account | Performance of contract | | Marketing communications | Consent (opt-in) | **Your Rights** Under GDPR (EEA/UK users): access, rectification, erasure, restriction, portability, objection, and withdrawal of consent. Under CCPA (California residents): right to know, right to delete, right to opt-out of sale (we do not sell personal information), and right to non-discrimination. ### Example 2: Mobile App with Location Tracking **Input:** FitRoute, a fitness tracking mobile app. Collects GPS location (continuous during workouts), health data (heart rate from wearables), email, age, weight. Users are global. **Output (additional sections):** **Location Data** FitRoute collects precise GPS location data during active workout sessions to map your route and calculate distance. Location tracking begins only when you start a workout and stops when you end it. We do not track your location in the background. You can revoke location permissions at any time through your device settings, though this will prevent route mapping features from functioning. **Health and Sensitive Data** We collect health-related data including heart rate (synced from connected wearables), workout duration, calories burned, and body metrics you voluntarily provide (age, weight, height). Under GDPR, health data is a special category requiring explicit consent — we obtain this consent during onboarding. Under California law, this constitutes sensitive personal information subject to additional protections. This data is encrypted at rest using AES-256 and in transit using TLS 1.3. **Consent Requirements*
Design reproducible evaluations for AI agents with representative task sets, explicit rubrics, appropriate graders, baselines, regression gates, and failure analysis. Use when defining agent quality, comparing prompts or models, validating a release, measuring tool-use reliability, investigating regressions, or deciding whether an agent is ready for production.
Design privacy-aware observability for AI agents using traces, spans, structured events, metrics, cost attribution, dashboards, alerts, and investigation workflows. Use when instrumenting an agent, debugging intermittent tool or model failures, defining service-level objectives, analyzing latency or spend, auditing agent decisions, or preparing production monitoring.
Design and verify auditable human oversight, approval gates, escalation paths, and safe state transitions for AI agent workflows. Use when deciding which agent actions require review, adding approve/reject or dual-control flows, preventing unauthorized autonomous effects, creating decision records, reducing rubber-stamping, or recovering safely from rejected, expired, or failed actions.
Design, implement, harden, and verify Model Context Protocol (MCP) servers with precise tool contracts, least-privilege authorization, safe transports, structured errors, and interoperability tests. Use when creating a new MCP server, exposing an API or data source through MCP, reviewing an MCP server design, adding or revising MCP tools, or preparing an MCP server for production.
Design and operate bounded multi-agent workflows with task decomposition, dependency graphs, ownership, handoff contracts, shared-state controls, approvals, recovery, and synthesis. Use when a task contains genuinely independent workstreams, specialized roles, parallel research or implementation, reviewer-worker loops, or coordination problems that one agent should not execute sequentially.
Design and validate model-facing tool definitions with clear names, action-oriented descriptions, bounded JSON Schema parameters, explicit side effects, safe defaults, idempotency, errors, and realistic tests. Use when creating function-calling tools, MCP tools, agent actions, structured tool inputs, or when a model selects the wrong tool, invents arguments, or causes unsafe side effects.
Plan, execute, document, and retest authorized security assessments of AI agents and multi-agent workflows using safe adversarial cases, synthetic identities, canaries, and evidence-based findings. Use when defining red-team rules of engagement, assessing prompt injection or excessive agency, testing tool and identity boundaries, evaluating memory or cross-agent attacks, scoring a campaign, or verifying remediation in an approved environment.
Threat-model and harden AI agents, RAG systems, assistants, and tool-using workflows against direct, indirect, stored, cross-agent, and multimodal prompt injection. Use when reviewing an agent architecture, isolating untrusted content, constraining tools and egress, protecting secrets, adding injection-focused tests, investigating a suspected injection incident, or documenting residual prompt-injection risk.