/feature-risk-assessment

name: feature-risk-assessment
description: >
  Deeper risk assessment for a single feature or product area when the launch
  review found something that needs more than a line item. Structured analysis:
  what could go wrong, how likely, how bad, what mitigates it. Use when user
  says "deep dive on this risk", "risk assessment for [feature]", "what could
  go wrong with", or when launch-review flags a novel issue.

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

Before finalizing, check against `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Risk calibration:

• Is this risk assessment calibrated to *this company*, or is it generic?
• A risk that's "High" at a company under a consent decree might be "Medium" at one that isn't
• The assessment should reflect the actual regulatory posture, litigation history, and risk appetite captured in the practice profile

Handoffs

• **To AI governance:** If the deep-dive was triggered by an AI feature — which

it often is — run `/ai-governance-legal:aia-generation [feature]` in parallel or immediately after. The feature risk assessment frames the decision; the AIA documents the AI system specifically in the format AI governance needs. They're not duplicates: the FRA is a product-legal decision doc; the AIA is the governance record.

• **To privacy:** If the feature involves new data collection or processing,

run `/privacy-legal:pia-generation [feature]`. The FRA's risk section will likely overlap with the PIA's — flag that overlap so work isn't duplicated, but both docs need to exist.

• **To AI governance vendor review:** If the feature uses a new AI vendor,

run `/ai-governance-legal:vendor-ai-review [vendor agreement]` if not already done during the launch review.

Output format

Standalone doc, 2-4 pages. Prepend the work-product header from `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` `## Outputs` (it differs by user role — see `## Who's using this`).

Not a slide deck, not a memo to file — a decision document someone reads and then decides.

Save where `~/.claude/plugins