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:
```markdown
- [ ] <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.