/use-case-triage

1. Read ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. Confirm privacy practice is configured — if not, stop and direct to setup.
2. Run the workflow below. Clarify the activity if vague.
3. House trigger check → mandatory DPIA check (if GDPR in footprint) → privacy policy conflict check.
4. Output: classification (PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP), reasoning, conditions table if required, cross-plugin handoffs.
5. Offer to continue into PIA generation if assessment is required.

/privacy-legal:use-case-triage "New feature that uses behavioral data to personalize content recommendations"

Privacy Use Case Triage

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 /privacy-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/privacy-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Destination check

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical ## Shared guardrails → Destination check in this plugin's CLAUDE.md.

Purpose

Answer the question that comes up before anyone runs a PIA: "does this thing even need one?" And if it does, what kind, and what's blocking the way?

Privacy triage is faster than PIA generation but upstream of it. It doesn't write the assessment — it determines whether one is needed and on what terms. The PIA generation skill does the deep work.

The output is one of four classifications:

• PROCEED — No PIA needed. Standard safeguards apply.
• PIA REQUIRED — Assessment needed before or alongside deployment.
• DPIA MANDATORY — A regime-mandated data protection impact assessment is required (research the applicable regime's trigger and cite primary sources). Harder bar, DPO/GC involvement likely.
• STOP — Processing activity conflicts with the privacy policy or has no lawful basis as described. Needs redesign before proceeding.

Jurisdiction assumption

This triage assumes the jurisdictional scope specified in your configuration. Privacy rules, assessment triggers, and lawful bases vary materially by jurisdiction (GDPR vs. state consumer privacy laws vs. sectoral). If the processing activity, controller, or affected data subjects fall under a different jurisdiction, this classification may not apply as written.

Read the config first

Before triaging, always read ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md. The PIA trigger criteria, regulatory footprint, and privacy policy commitments there are authoritative. Generic privacy law reasoning is not a substitute for what this company has actually committed to.

If the file is missing or contains [PLACEHOLDER], surface this bounce:

I notice you haven't configured your practice profile yet — that's how I tailor the PIA trigger criteria, regulatory footprint, and privacy policy commitments to your practice.

Two choices:

…