Feature Risk Assessment

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /product-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

The launch review is broad. This is deep. When a single issue needs more than a table row — a novel AI feature, a children's product, something a regulator is actively looking at — this skill produces a standalone assessment.

Not every launch needs one. Most don't. This is for the 10% where "PIA done, shipped" isn't the right level of scrutiny.

When to run this

• Launch review found a pattern that's not in the calibration table (novel)
• Launch review found something in the "usually blocks" category
• GC or leadership asked "what's the risk here" and wants more than a one-liner
• The feature is in an area with active regulatory attention (AI, children, biometric, health)
• Someone outside legal is worried and a structured answer would help

If none of the above, the launch review is enough. Don't generate paperwork for its own sake.

Structure

1. What we're assessing

One paragraph. What the feature does, what's new about it, why it got escalated to a full assessment.

2. The risks

For each distinct risk (aim for 2-5, not 15):

### Risk [N]: [Short name]

**Scenario:** [What would have to happen for this to go wrong. Be specific —
not "data breach" but "the recommendation algo surfaces a user's sensitive
category interest to someone who shouldn't see it because X."]

**Who gets hurt:** [Users? The company? A third party? Specific.]

**How likely:** [Low / Medium / High — with a reason. "Low — would require
both X and Y to fail simultaneously." Not just a vibes rating.]

**How bad if it happens:** [Low / Medium / High — with a reason. "High —
regulatory fine + class action exposure + press" vs. "Low — one angry
tweet, no actual harm."]

**Existing mitigations:** [What already reduces the likelihood or impact]

**Gap:** [What's missing, if anything]

**Residual risk:** [After existing mitigations — is this acceptable or does
it need more?]

3. Regulatory landscape (if relevant)

Only include if a regulator is actively interested in this space. If so:

• Which regulator, what they've said/done recently
• How this feature would look to them
• Whether we'd rather they hear about it from us or from a headline

4. Precedent (if any)

Has another company done something similar? What happened?

• If nothing bad happened → useful, not dispositive
• If something bad happened → what was different about their situation, does it apply here

Don't overweight precedent. Regulators change priorities; one company getting away with something doesn't mean the next one will.

5. Options

Present 2-3 realistic paths:

| Option | Description | Risk reduction | Cost |
|---|---|---|---|
| A: Ship as designed | [current plan] | None | None |
| B: Ship with [mitigation] | [change] | [how much] | [eng effort, timeline, UX] |
| C: Don't ship [component] | [scope cut] | [how much] | [product impact] |

6. Recommendation

Pick one. Explain why. Acknowledge what you're trading off.

**Recommended: Option [X]**

[Why. What risk remains. Why that's acceptable. Who accepts it.]

**If the answer is "not my call":** [Who decides, what they need to know]

Calibration check

…