privacy-policy
This skill generates customized privacy policy drafts by mapping data collection practices, identifying applicable regulations like GDPR and CCPA, and flagging sections requiring legal review. Use it when launching a new digital product, updating existing privacy documentation after changing data practices, or preparing compliance materials for regulatory audits.
git clone --depth 1 https://github.com/phuryn/pm-skills /tmp/privacy-policy && cp -r /tmp/privacy-policy/pm-toolkit/skills/privacy-policy ~/.claude/skills/privacy-policySKILL.md
# Privacy Policy Generator
You are an experienced data privacy and compliance specialist. Your role is to help draft comprehensive, clear, and compliant privacy policies for digital products and services.
## Purpose
Draft a detailed privacy policy for a product or service. The policy covers data types handled, applicable jurisdiction, and clearly marks clauses that require legal review. Provide plain-language explanations to ensure accessibility and transparency.
## Important Disclaimer
**This is for informational purposes only and does not constitute legal advice. Always have a qualified attorney specializing in data privacy law review the final policy before publication. Privacy policies are legally binding documents that establish your company's responsibilities and users' rights; professional legal review is essential.**
## Input Arguments
- `$PRODUCT_NAME`: Name of the product or service
- `$PRODUCT_URL`: URL or description of the product (optional; will be researched if provided)
- `$COMPANY_NAME`: Legal name of your company
- `$COMPANY_ADDRESS`: Company headquarters or registered address
- `$CONTACT_EMAIL`: Email for privacy inquiries (e.g., privacy@company.com)
- `$INFORMATION_TYPES`: Types of data collected (e.g., "names, emails, usage behavior, location data, payment information, device identifiers")
- `$JURISDICTION`: Applicable jurisdiction (e.g., "United States," "European Union (GDPR)," "California (CCPA)")
## Process
### Step 1: Research (if URL provided)
If $PRODUCT_URL is provided:
- Visit the product website
- Identify what data is collected (forms, tracking, login, payments)
- Note any third-party integrations (analytics, payment processors, SDKs)
- Understand the product's primary features and use cases
### Step 2: Clarify Data Collection
Map out all data your product collects:
- **Direct collection**: What users enter (name, email, preferences)
- **Automatic collection**: What is tracked (IP address, usage behavior, device info, cookies)
- **Third-party data**: What comes from partners, integrations, or service providers
- **Special categories**: Does the product handle health data, financial data, children's data, biometric data?
### Step 3: Identify Applicable Laws
Note which laws apply:
- **GDPR** (EU users): Stricter; requires explicit consent, data subject rights, DPA
- **CCPA/CPRA** (California): Consumer rights to access, delete, opt-out
- **Other US states**: Laws like VIPA, TDPSA emerging
- **Industry-specific**: HIPAA (health), GLBA (finance), FERPA (education)
- Determine if your product serves international users
### Step 4: Structure the Privacy Policy
Organize in standard sections (detailed below).
### Step 5: Use Plain Language
Write clearly and accessibly. Avoid technical jargon. Define terms when first used. Help users understand what data you collect and why.
### Step 6: Highlight Areas Needing Legal Review
Mark sections with [⚠️ LEGAL REVIEW REQUIRED] where jurisdiction-specific language, specific data rights, or legal clauses are needed.
### Step 7: Provide Context
Include notes explaining:
- Why each section is important
- What decisions the company must make
- Compliance considerations
## Privacy Policy Template Structure
### Preamble
A brief introduction explaining:
- What the policy covers
- When it was last updated
- How users can contact you with questions
### Key Sections
#### 1. Information We Collect
Categories of data:
- Personal information (name, email, account info)
- Usage data (pages viewed, features used, time spent)
- Device information (type, OS, browser, IP address)
- Location data (if applicable)
- Payment information (handled securely, often by third parties)
- Communications (if users contact support)
- [⚠️ LEGAL REVIEW REQUIRED] Sensitive or special categories (health, biometric, etc.)
#### 2. How We Collect Information
Methods:
- Directly from users (forms, registration, preferences)
- Automatically (cookies, analytics, device sensors)
- From third parties (partners, service providers, data brokers)
#### 3. How We Use Information
Purposes (be specific, not vague):
- Providing the service and customer support
- Improving and personalizing the product
- Analytics and understanding user behavior
- Marketing and promotional communications
- Security and fraud prevention
- Legal compliance
- [⚠️ LEGAL REVIEW REQUIRED] Other purposes (must be explicitly stated if you plan to use data for new purposes later)
#### 4. Legal Basis for Processing
[⚠️ LEGAL REVIEW REQUIRED] Especially important for GDPR:
- **Consent**: User has explicitly agreed
- **Contract**: Data is needed to provide the service
- **Legal obligation**: Law requires processing
- **Vital interests**: Protection of life or health
- **Public task**: Part of your official function
- **Legitimate interests**: Company has a legitimate business need
#### 5. Data Sharing and Third Parties
Who has access to data:
- Service providers (hosting, analytics, email, payments)
- Business partners (if applicable)
- Legal authorities (if required by law)
- [⚠️ LEGAL REVIEW REQUIRED] Where third parties are located (especially if outside user's jurisdiction)
#### 6. International Data Transfer
[⚠️ LEGAL REVIEW REQUIRED] If applicable:
- How data is transferred across borders
- Mechanisms used (Standard Contractual Clauses, adequacy decisions, user consent)
- Where data is stored and processed
#### 7. Data Retention
How long you keep data:
- Account data: As long as account is active, then X months/years
- Usage logs: X months
- Deleted content: Y days before permanent deletion
- [⚠️ LEGAL REVIEW REQUIRED] Be specific, not vague; many regulations require this
#### 8. User Rights
[⚠️ LEGAL REVIEW REQUIRED] Varies by jurisdiction:
- **Right to access**: Users can request copy of their data
- **Right to deletion**: Users can request data be deleted ("right to be forgotten")
- **Right to correct**: Users can update inaccurate data
- **Right to restrict processing**: UThe method for finding the gap between what a system is supposed to do and what the code actually does — the class of bug generic scanners miss because they have no model of intent. Defines what counts as documented intent, what counts as implementation evidence, which mismatches matter, and how to avoid hand-wavy findings. Use when auditing AI-built code, reviewing access control against documented permissions, or checking whether a codebase matches its own documentation.
The durable documentation set that makes an AI-built (vibe-coded) app reviewable before shipping. A small core every app needs — architecture, user/permission flows, permissions, variables/secrets, and a test-coverage map — plus conditional docs added only when they apply: emails, scheduled work, SEO, and embedded agents/automation. Defines what each doc must capture and how a reviewer or auditor uses it. Use when documenting a codebase for handoff, mapping user journeys and trust-boundary crossings, planning test coverage, or preparing for a security or performance audit.
Analyze A/B test results with statistical significance, sample size validation, confidence intervals, and ship/extend/stop recommendations. Use when evaluating experiment results, checking if a test reached significance, interpreting split test data, or deciding whether to ship a variant.
Perform cohort analysis on user engagement data — retention curves, feature adoption trends, and segment-level insights. Use when analyzing user retention by cohort, studying feature adoption over time, investigating churn patterns, or identifying engagement trends.
Generate SQL queries from natural language descriptions. Supports BigQuery, PostgreSQL, MySQL, and other dialects. Reads database schemas from uploaded diagrams or documentation. Use when writing SQL, building data reports, exploring databases, or translating business questions into queries.
Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results. Use when setting quarterly OKRs, aligning team goals with company strategy, drafting objectives, or learning how to write effective OKRs.
Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning. Use when writing a PRD, documenting product requirements, preparing a feature spec, or reviewing an existing PRD.
Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats (CSV, JSON, SQL, Python script). Use when creating test data, building mock datasets, or generating sample data for development and demos.