Privacy Policy Writer

Privacy Policy Writer

Create or update a practical privacy policy draft based on installed packages, product code, project docs, and the user's stated data practices.

This skill is a drafting aid, not legal advice. Always recommend qualified legal review before publishing.

Workflow

Step 1: Inspect Product And Data Context

Before writing, inspect the project for real data flows and existing privacy language.

Prioritize these sources:

1. Existing privacy policy, legal pages, cookie notices, consent banners, footer links, onboarding copy, settings pages, account deletion flows, and support docs.
2. README.md, product docs, landing pages, feature specs, app store copy, and public marketing pages.
3. Package manifests and lockfiles that reveal installed SDKs or services.
4. Auth/account flows, forms, API routes, server actions, backend models, database schemas, storage buckets, uploads, exports, deletion jobs, and webhooks.
5. Analytics, telemetry, crash reporting, advertising, attribution, payments, email, chat/support, maps/location, AI APIs, push notifications, identity providers, and cloud services.
6. Environment variable examples and config files that name third-party providers.

Common files and patterns to inspect:

PRIVACY.md
privacy*.md
LEGAL.md
README.md
docs/**/*
app/**/*.{ts,tsx,js,jsx,md,mdx}
pages/**/*.{ts,tsx,js,jsx,md,mdx}
src/**/*.{ts,tsx,js,jsx,py,rb,php,go,rs,md,mdx}
components/**/*.{ts,tsx,js,jsx}
routes/**/*
api/**/*
server/**/*
models/**/*
schema.prisma
migrations/**/*
package.json
pnpm-lock.yaml
package-lock.json
yarn.lock
requirements*.txt
pyproject.toml
Gemfile
go.mod
Cargo.toml
.env.example
app.json
app.config.*
next.config.*
firebase
supabase
stripe
posthog
analytics
amplitude
segment
sentry
crashlytics
mixpanel
ads
cookies
consent
delete-account
data-export

Treat the user's explicit data-practice statements as the highest-priority input. Treat project files as evidence of actual implementation. Do not invent legal facts or compliance claims.

Step 2: Identify Data Practices

Create an internal inventory of confirmed and inferred data practices.

Capture:

• Product name, operator/legal entity, contact email, address, and supported regions if stated.
• Categories of personal data collected, such as account details, contact details, profile data, billing data, user content, uploaded files, messages, usage analytics, device/browser data, cookies, IP address, approximate location, precise location, crash logs, support messages, and AI prompts/outputs.
• Source of each category: user-provided, automatically collected, imported from third parties, generated by the product, or inferred from usage.
• Purpose for each category: account creation, authentication, service delivery, billing, fraud prevention, analytics, personalization, support, marketing, legal compliance, safety, debugging, product improvement, or AI feature operation.
• Third parties or processors that may receive data, such as hosting providers, analytics tools, payment processors, auth providers, email providers, customer support tools, ad networks, AI model providers, storage/CDN providers, app stores, and fraud prevention tools.
• Retention signals: account lifetime, billing/legal retention, logs retention, backups, analytics retention, deleted-account retention, or unknown retention.
• User controls: access, correction, export, deletion, consent withdrawal, marketing unsubscribe, cookie preferences, account deletion, and support contact.

Record assumptions separately from confirmed facts.

Step 3: Ask Only For Missing Material Facts

If important privacy facts are missing, ask a short set of focused questions before drafting. Prefer 3-7 questions.

Ask only what materially affects the policy, such as:

1. What is the legal company/operator name and privacy contact email?
2. What personal data do you intentionally collect from users?
3. Which third-party services receive or process user data?
4. How long do you retain account data, billing records, logs, analytics, backups, and deleted-account data?
5. How can users request access, export, correction, or deletion of their data?
6. Do you use cookies, tracking, ads, analytics, or marketing emails?
7. Which regions matter for the policy, such as EU/UK, California, Brazil, Canada, or global users?

If the user wants a fast draft and missing facts remain, write with clear placeholders such as [Privacy Contact Email] and an assumptions section.

Step 4: Draft Or Update The Privacy Policy

Create or update PRIVACY.md at the project root by default.

Use the reference structure in references/privacy-policy-template.md. Adapt every section to the product; do not keep irrelevant sections.

Writing rules:

• Use clear English and practical privacy language.
• Explain what data is collected, why it is collected, who it is shared with, how long it is retained, and how users can ask for deletion or export.
• Base disclosures on observed code, installed packages, configured services, and user-provided facts.
• Distinguish confirmed practices from assumptions.
• Use placeholders for missing legal or operational facts rather than inventing them.
• Do not claim GDPR, CCPA/CPRA, HIPAA, COPPA, PCI, SOC 2, ISO 27001, or other compliance unless project docs clearly support it.
• Do not promise encryption, anonymization, deletion timelines, regional hosting, no sale/no sharing, or zero tracking unless supported by user instructions or project docs.
• Keep the policy readable for end users while preserving enough specificity to be useful.

Step 5: Create A Privacy Page If Requested

If the user asks to create a privacy page for a SaaS, website, app, or marketing site, inspect the app framework and routing conventions before editing code.

Implementation rules:

• Write into the appropriate page route/file instead of PRIVACY.md when the user explicitly asks for a page.
• Reuse the existing routing structure, layout components, metadata conventions, typography, and styling system.
• Prefer rendering the privacy content from PRIVACY.md, Markdown, or MDX when the project already supports it.
• If Markdown rendering is not available, create a simple page component with semantic headings and readable sections.
• Add metadata/title when the framework supports it.
• Add or update footer/settings/legal links only when the user asks or existing patterns make the intended location obvious.
• Do not introduce a new UI library, markdown pipeline, or route convention just for the privacy page.
• Preserve existing design language and accessibility expectations.

Common route targets:

/privacy
/privacy-policy
/legal/privacy

Step 6: Quality Check

Before finishing, verify the policy:

• Lists collected data categories and avoids unsupported categories.
• Explains collection purposes in plain language.
• Identifies third-party sharing and processors when visible from code or provided by the user.
• Covers cookies, analytics, advertising, and marketing only when relevant.
• Covers retention and deletion/export request process with placeholders if unknown.
• Includes children's privacy, security, international transfers, user rights, contact, and update language when appropriate.
• Marks assumptions, placeholders, and items needing legal review.
• Avoids unsupported compliance, security, deletion, retention, or no-sale/no-sharing claims.

Step 7: Final Summary

At the end, explain and summarize what was written.

Include:

• Where the privacy document or page was created or updated.
• Which project sources and user-provided facts were used.
• The data categories included.
• Why the data is collected.
• Which third parties, services, or sharing categories are mentioned.
• Retention and deletion/export rules included.
• Key assumptions, placeholders, missing details, or facts still needing confirmation.
• Whether legal review is recommended before publishing.