legal-privacy-review

name

legal-privacy-review

description

Conduct a structured pre-launch legal and privacy review for a new product. Trigger when the user asks for a "legal review", "legal and privacy review", "pre-launch review", "launch readiness review", or asks to assess a product for legal/privacy risks before launch. Produces a parent summary document (top-risks overview with a 5×5 risk matrix) and a child review document (full review, prioritization, checklists, product-team questions). Optionally spawns sub-pages (ToS/PP analysis, vendor assessment, DPIA, etc.).

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-specific), cancellation, refund, tax handling, in-product disclaimers
2. IP & Branding — Trademark, copyright/ownership of inputs and outputs, open-source license review
3. Third-Party & Vendor Agreements — Vendor terms, sub-processor list, vendor DPAs, vendor government-access policies
4. Regulatory & Compliance — Applicable AI / data / consumer-protection regimes for the launch geography, export controls, marketing-claims accuracy, attestations / certifications scope
5. Government Access & Law Enforcement Requests — Intake procedure, designated POC, applicable legal frameworks for the geographies in scope, customer-notification posture, data minimization, transparency reporting, internal-access controls
6. Trust & Safety — Posture on proactive vs. incidental observation, mandatory reporting inventory, escalation procedures, duty-to-warn analysis, evidence preservation, customer-notification stance, staff training, sub-processor coordination, acceptable-use reservation
7. Ethical & Reputational Considerations (proactive, distinct from Trust & Safety) — Customer-selection / sales-screening posture, signup screening, brand-promise consistency, bias/fairness review for AI outputs, internal responsible-AI / ethics review, crisis-comms plan, voluntary public commitments, post-launch impact monitoring

Within each section, use task-list style:

- [ ] <Specific item the product needs>

---

Reference: Privacy checklist structure

Same approach: categories only; reviewer fills in items.

1. Data Mapping & Inventory — All inputs/outputs, PII assessment in customer content, end-user data ingestion check, data-flow diagram, intake-field documentation
2. Data Handling & Storage — Residency, encryption at rest / in transit, retention by category, deletion / account-closure, internal access controls
3. Model & AI-Specific Privacy (for AI products) — Whether customer content is used to train upstream models, LLM prompt / output logging and retention, customer-facing disclosure
4. Customer-Facing Privacy — Privacy policy, DPA template, sub-processor disclosure, in-product disclosures / consent prompts, government-request handling explanation, intake-field disclosure (purpose limitation), explicit AI-use consent at signup (where applicable)
5. Regulatory — DPIA, data-protection law obligations, cross-border transfer mechanisms, applicable consumer-privacy law assessments
6. Security Coordination (privacy-adjacent) — Certifications / attestations coordination, auth / authz model review with Security, audit logging of customer-data access

---

Reference: Risk matrix methodology

5×5 Likelihood × Impact, 12-month-from-launch horizon. Score each risk on two dimensions:

• Inherent — current state, none of Tier 1 work done
• Residual — projected after Tier 1 to-do's complete by proposed dates

The delta shows what the work buys. Risks that remain high after Tier 1 are "structural" and need ongoing investment.

Likelihood scale (1–5): 1 Rare · 2 Unlikely · 3 Possible · 4 Likely · 5 Almost Certain

Impact scale (1–5): 1 Insignificant · 2 Minor · 3 Moderate · 4 Major · 5 Catastrophic

Score = L × I (max 25). Tag the dominant impact dimension per risk:

• Regulatory
• Financial
• Reputational
• Customer-trust
• Operational

Bands:

• 1–6 = Low
• 8–12 = Significant
• 15–25 = Critical

(In markdown, render with emoji or a status word. In Confluence, use status macros: <span data-type="status" data-color="green|yellow|red">Label</span>.)

For each row include: Risk · Primary impact · Inherent (L×I + band) · Residual (L×I + band) · Major to-do's · Proposed due date.

Always include a "How to read this matrix" note below the table — explain that tractable residuals shrink with Tier 1 work, and structural residuals reflect categories that require ongoing investment (e.g., trust & safety events, reputational scenarios) regardless of pre-launch work.

---

Reference: Tier system

Tier 1 (must do before launch): Highest-risk, externally-facing, easy-win, or legally compelled the moment the product accepts customer content. Group Tier 1 by workstream so the work is assignable:

• Customer-facing documents (ToS, AUP, Privacy Policy, DPA, sub-processor disclosure)
• Foundational privacy work
• Regulatory baseline
• IP & vendors
• Pricing / billing / subscription
• Government access basics
• Trust & Safety basics
• In-product disclosures & UX layer (consent gates, AI disclaimers if applicable, geofencing mechanism)
• Ethical & reputational positioning
• Marketing & comms
• Security coordination

Tier 2 (strengthens posture): Won't materially expose the org if deferred a few weeks post-launch.

Tier 3 (longer-term): Only relevant post-launch, or only if specific triggers occur.

---

Reference: Product-team question library

Group questions by topic. Start with a Top N callout (5–10 questions) that prioritizes what's blocking the highest-scoring inherent risks. Then a full numbered list grouped by topic. Suggested topic groupings — adapt based on product:

• Launch scope & geography
• Pricing & commercial
• Customer scope (audience details, edge cases)
• Vendors & data flows
• Data content & retention
• Internal access & operations
• Ethical & reputational positioning
• In-product UX & disclosure (consent gates, AI disclaimers, geofencing — where applicable)

Generate specific questions per category based on the product. Don't ask generic questions — every question should be answerable by the product team and should unblock specific Tier 1 items.

---

Reference: Sub-doc — ToS/PP analysis playbook

When the product needs significant customer-facing legal documents (common for new SaaS), spawn a sub-doc titled <Product> — Terms of Service & Privacy Policy Analysis.

Structure:

1. Purpose — what this doc does, owner, target completion, last-updated

2. Initial-pass warning — if populated from public docs, explicitly warn that the public copy may diverge from the canonical internal version

3. Source documents — links + version dates

4. Method — Keep / Amend / Addendum / New recommendation framework + severity bands (Low / Significant / Critical)

5. Part 1: ToS Analysis — 6-column table per topic:

   | Topic | Current state | Product-applicable? | Gap | Recommendation (Keep / Amend / Addendum / New) | Severity |

   Topics to consider (adapt per product): service definition, account/user model, AUP, license grants (in / out), IP ownership of inputs / outputs, AI output disclaimers (if applicable), liability, warranties, indemnification, subscription tiers, consumption billing, free tier, auto-renewal, cancellation, refund, post-cancellation handling, suspension / termination, customer-selection, government access, mandatory reporting reservation, export controls, modification of terms, dispute resolution, class action / arbitration, B2B-only positioning, product-specific provisions.

6. Part 2: PP Analysis — same 6-column table format. Topics to consider: data categories collected, voice/audio (if applicable), inadvertent PII in customer uploads, sources, purposes, legal basis, sub-processors disclosed, sub-processor change notification, "not used to train" statement (if applicable), sharing/disclosure, international transfers, retention, deletion/account-closure, post-cancellation data flows, data subject rights, automated-decision-making, cookies, children's data, marketing comms, government access, mandatory reporting, security measures, state/province-specific obligations, change notification, contact / DPO.

7. Part 3: DPA & sub-processor disclosure — verify existence and applicable-law compliance

8. Companion in-product UX layer — table mapping each UX requirement to the document it pairs with (consent gates, AI disclaimers, geofencing — where applicable)

9. Findings Summary — grouped by Keep / Amend / Addendum / New for work planning

10. Open Questions — specific to this analysis

11. Dependencies — what's blocked by Top N product-team questions

If the public-facing ToS and PP are available online, fetch them to pre-populate "Current state" — but always include the warning about public-vs-canonical divergence.

---

Common pitfalls to avoid

• Don't invent product details. If source docs don't say something, flag it as TBD and add it to the product-team questions list. Don't guess at pricing, vendors, geography, or launch posture.
• Don't conflate Trust & Safety with Ethical & Reputational. T&S is reactive (mandatory reporting, escalation paths when something happens). E&R is proactive (positioning, customer selection, brand-promise consistency). Different owners, different artifacts.
• Don't pad checklists. Each item should be actionable. A 50-item checklist nobody completes is worse than a 25-item one that's tracked.
• Don't over-score risks. "Critical" should be reserved for items that could genuinely derail launch or cause material harm. If everything is Critical, nothing is.
• Don't treat residual risk as if Tier 1 mitigations are silver bullets. Some risks are structural — Tier 1 work changes how prepared you are, not whether they happen. Call this out.
• Don't push the summary and review out of sync. The summary's risk matrix is source of truth; the review syncs from it. When scores change, update both.
• Don't bury the product-team questions. The Top N callout exists because answering a small set of questions often unblocks half the Tier 1 work. Make it prominent and short.
• Don't forget the in-product UX layer. For AI products especially, contractual language alone is rarely enough — consent at signup, just-in-time disclaimers, and enforcement mechanisms (e.g., geofencing) need to be tracked alongside the contracts.
• Don't skip the "what Tier 1 buys us" framing. Reviewers want to see the delta between inherent and residual. That's where prioritization decisions get made.
• Don't be exhaustive on first pass. This is iterative. Land the structure, get user feedback, then deepen the sections that matter for this product.

---

Confluence specifics (optional)

If the user has the Atlassian MCP server loaded and wants to publish directly, ask for:

• Cloud ID (e.g., <workspace>.atlassian.net)
• Space ID where the review should live
• Parent page ID (the folder / parent under which the summary doc goes)

Then:

• Use mcp__atlassian__createConfluencePage with contentFormat: "html" — Confluence converts to ADF cleanly
• Use status macros for severity: <span data-type="status" data-color="green|yellow|red|neutral">Label</span>
• Use panels for callouts: <div data-type="panel-info|warning|note|success|error"><p>...</p></div>
• Use task-list for checkboxes: <ul data-type="task-list"><li data-type="task-item"><input type="checkbox"> Item</li></ul>
• When editing existing pages, always preserve prior content; use updateConfluencePage with the full new body

---

When you're done

Hand the user:

• Paths or links to both documents (summary + review)
• A note on which sections are most populated vs. placeholder
• A reminder of the Top N product-team questions that unblock the next round of work
• An offer to spawn sub-docs (ToS/PP analysis is the most common next step)

Don't claim the review is complete — the user signs off on review completion, not the skill.

---

Attribution

This skill is based on a methodology originally developed by Linsey Krolik for pre-launch legal and privacy reviews. Released under CC BY 4.0 — see LICENSE.