legal-privacy-review

What this skill does

Guides a reviewer through a structured pre-launch legal + privacy review of a new product. The output is a set of documents that capture:

1. Top-risks summary with a 5×5 risk matrix (executive-readable)
2. Full review: product overview Q&A, happy/unhappy paths, prioritized checklists, product-team questions, sign-offs

The skill provides structure and methodology — section headings, scoring system, tier framework — but does not prescribe specific checklist items, regulatory citations, or risk topics. The reviewer fills those in based on their product, jurisdiction, and organizational priorities.

When to use this skill

Trigger when the user:

• Asks for a "legal review" or "legal and privacy review" of a product
• Asks to do a "pre-launch review" or "launch readiness review"
• Wants to assess legal/privacy risks for a product in development

Do NOT trigger for: code review, PR review, policy/contract drafting, generic legal questions, or post-launch incident reviews.

Output format

By default, this skill produces two markdown files in the working directory:

• <product-slug>-summary.md — the parent/landing document
• <product-slug>-review.md — the full review

The markdown files can be pasted into Notion, Confluence, Google Docs, GitHub wiki, or any other surface.

Optional: Confluence output. If the user has the Atlassian MCP server loaded (mcp__atlassian__* tools available) and wants to publish directly, ask for the destination space ID and parent page ID, then use createConfluencePage with contentFormat: "html". See "Confluence specifics" at the end of this file.

What you need from the user before starting

Before drafting, gather:

1. Product name (and any aliases / internal codenames)
2. Output destination — local markdown (default) or Confluence (if MCP is available)
3. Source documents — links or paths to PRD, scope docs, initiative pages, tickets, prototype walkthroughs
4. Reviewer name (for the sign-off table)
5. Target launch date (if known)

Ask for these via AskUserQuestion if not provided. Don't guess.

Workflow

Phase 0: Confirm scope

Ask 2–4 scoping questions:

• Output destination (markdown / Confluence)
• Source-doc links or paths
• Whether to draft both the summary and the review, or just one
• Whether to draft locally first before publishing (recommend yes for first review)

Phase 1: Read source documents

Read the linked product docs. Extract:

• Target launch date
• What the product does (1–2 sentence summary)
• Customer / buyer persona
• Pricing model (if any)
• Vendors / sub-processors named or implied
• Data the product handles
• Any explicit "out of scope at launch" callouts
• Open questions called out in source docs

Anything you can't derive from source docs becomes an open question for the product team — flag it as TBD, don't invent.

Phase 2: Draft the summary document

The summary document is the executive-readable landing. It contains:

• Status block — current status, target launch, owner placeholder
• Top-risks summary table with a 5×5 risk matrix (see "Risk matrix methodology")
• About the product (1–2 paragraphs)
• Links to primary product documentation
• Note that the review document tracks detailed analysis

Title pattern: <Product Name> — Pre-Launch Risk Summary

Phase 3: Draft the review document

Title pattern: <Product Name> — Legal & Privacy Review

Contents, in this order:

1. Status block (target launch, owner, last updated)
2. Implementation Plan & Open Questions (top-of-page summary)
   • Risk matrix table (synced from the summary doc — note that the summary is source of truth)
   • Tier 1 / Tier 2 / Tier 3 groupings
   • Open questions for the product team (a Top N at the top + full numbered list)
3. Product Overview (8-question intake — see "Product overview questions")
4. Resources (Product Documentation, Communication, Other Internal, External)
5. Legal Review Checklist (organized by category — see "Legal checklist structure")
6. Privacy Review Checklist (organized by category — see "Privacy checklist structure")
7. Sign-offs table

Phase 4: Populate iteratively

Don't try to fill every section at once. Natural flow:

1. Product Overview Q&A — pull from source docs; flag TBDs.
2. Happy Path — concrete narrative for a representative user.
3. Unhappy Paths — grouped by category (see below).
4. Checklists — Legal + Privacy.
5. Prioritization — Tier 1 / Tier 2 / Tier 3 once checklists are stable.
6. Risk Matrix — once prioritization clarifies what's structural vs. tractable.
7. Top N product-team questions — once you know what's blocking which Tier 1 items.

Ask the user for feedback between steps. Don't try to be exhaustive on the first pass.

Phase 5: Sub-pages (as needed)

Spawn sub-documents as the review surfaces specific deep-dive areas. Common ones:

• Terms of Service / Privacy Policy analysis — when the product needs significant customer-facing legal documents (common for new SaaS). See "Sub-doc: ToS/PP analysis playbook" below.
• Vendor / sub-processor assessment — when many new vendors are introduced
• DPIA — when applicable thresholds are met (e.g., GDPR Article 35)
• AI Act applicability — if EU customers are in scope and the product uses AI
• Specific risk deep-dives — any single risk that warrants its own document

Each sub-doc links back to the parent and notes its dependencies.

Reference: The 8 product overview questions

Always include these in the Product Overview section. Pull answers from source docs where possible; flag unanswerable items as TBD with a note on who can answer.

1. Business objective — revenue, users, market activation, etc.
2. What the product is — 1–2 sentences in plain language
3. When it will launch — target date; flag if public-launch vs. limited-availability is unresolved
4. How it will work — signup, key product flow, data handled (including PII / personal data). Include a Happy Path (concrete narrative) and Unhappy Paths (grouped by category). Note any access-control / RBAC details but recognize that full security review is typically owned by a separate Security function.
5. Who the product targets — customer type (B2B vs. consumer), buyer persona, organization size, other relevant audience details. Call out edge cases (e.g., sole-proprietor / single-user signups for self-serve products).
6. Where it will launch — countries / regions. This single answer typically toggles many regulatory items.
7. Pricing details — tiers, billing mechanism, free tier behavior, cancellation, refund policy
8. Key partnerships and vendors — group by category (e.g., payment providers, cloud hosts, LLM providers, integrations, other sub-processors)

Reference: Unhappy-path categories

Walk through each category and identify product-specific scenarios. Skip categories that don't apply.

• Sensitive content in customer inputs
• Unauthorized or bad-faith signup & use
• Product-output quality failures (false positives, false negatives, hallucinations for AI products)
• Product safety concerns
• Edge cases
• Cross-tenant / multi-customer risks
• Geography & data residency mismatches
• Government access requests for data
• Awareness of crime or imminent harm (distinct from government access)
• Ethical & reputational scenarios
• Soft-enforcement / customer-misuse paths
• Subscription, billing & offboarding

Each entry should have at least one concrete, plausible scenario tied to the product. Don't pad.

Reference: Legal checklist structure

The reviewer fills in specific items per product and jurisdiction. The skill provides category headings only.

1. Commercial & Customer-Facing Terms — Master agreement / ToS, EULA, AUP, pricing/billing terms, liability allocation, free-tier behavior, auto-renewal compliance (jurisdiction-speci