Quickly determine whether a processing activity needs a PIA, a mandatory GDPR DPIA, or can proceed — surfaces privacy policy conflicts and routes to the right next step. Use when the user asks "does this need a PIA", "triage this feature", "privacy check on X", "is this okay from a privacy perspecti

/use case triage 1. Read ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . Confirm registry is populated — if not, stop and direct to setup. 2. Use the framework below. Clarify the use case if vague. 3. Registry lookup → red line check → classify. 4. Output: classification, reasoning, conditions table (if conditional), governance tier, cross plugin handoffs. 5. Propose registry update if use case wasn't already in the registry. 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 /ai governance 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/ai governance legal/matters/<matter slug / . Never read another matter's files unless Cross matter context is on . Purpose Stop the conversation that happens in a hallway and starts as "can we just use AI for this?" Give a fast, calibrated answer from the registry — and if the answer is conditional, make the conditions concrete and the next step obvious. The triage skill is a gateway, not a destination. Its job is to classify, flag what's required, and route. The aia generation skill does the deep work. Read ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md first Before triaging, always read ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . The use case registry and red lines there are authoritative. Generic AI ethics reasoning is not a substitute for what this company has actually decided. If ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md contains [PLACEHOLDER] , surface this bounce: I notice you haven't configured your practice profile yet — that's how I tailor the use case registry, red lines, and governance tiers to your practice. Two choices: Run /ai governance legal:cold start interview (2 minutes) to configure your profile, then I'll triage tailored to YOUR practice. Say "provisional" and I'll triage against generic defaults — US jurisdiction, middle risk appetite, lawyer role, no playbook — and tag every output [PROVISIONAL — configure your profile for tailored output] so you can see what I do before committing. Provisional mode If the user says "provisional," run triage normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction, no registry (classify by general AI governance principles rather than matching to a registered entry). Tag the reviewer note and every finding block with [PROVISIONAL] . At the end of the output, append: "That was a generic run against default assumptions. Run /ai governance legal:cold start interview to get output calibrated to YOUR practice — your registry, your jurisdiction, your risk appetite. 2 minutes." Jurisdictional scope. Triage applies the registry, red lines, and governance tiers configured for the regulatory footprint in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . AI rules vary materially by jurisdiction — an APPROVED classification in one footprint may be CONDITIONAL or prohibited in another. If deployment touches a jurisdiction not in the footprint, surface that and re triage rather than extending by analogy. Triage process Step 1: Understand the use case Before classifying, make sure you understand what's actually being proposed. If the description is vague, ask: "What is the AI doing, exactly — generating content, making a decision, surfacing recommendations, automating a task?" "Who or what is the AI acting on — employees, customers, third parties, internal data only?" "Is a human reviewing the AI output before anything happens, or is it automated?" "Which vendor or tool is being proposed?" "Is this internal only, or does it touch customers or other external parties?" Don't let "we want to use AI for [vague thing]" go untriaged. Get specific enough to classify accurately. Step 2: Registry lookup Check the use case registry in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md for a direct or close match. Direct match: If the registry has a directly matching entry, apply it. Near match: If the use case is similar to a registry entry but not identical, flag this: "This looks like [registered use case] — I'm applying that classification, but if the scope is meaningfully different, it may need its own assessment." No match: If the use case isn't in the registry, default to CONDITIONAL pending an AI impact assessment. Surface the preliminary read on risk and route to the AIA. "This use case isn't in your registry yet. Defaulting to CONDITIONAL pending an AI impact assessment. Here's my preliminary read on risk: [preliminary read]. Next step: run the impact assessment, and I'll add the use case to the registry once classification is settled." Source attribution (applies whenever the triage cites regulation) Triage typically stays high level, but if the classification depends on citing a regulation, statute, rule, directive, standard, or guidance — tag the citation. Do not output untagged regulatory citations in the triage reasoning, the red line explanation, or the conditions list. A triage that says "Art. 22(1)" without a tag is exactly where a fabricated pinpoint slips past the reader. Source attribution tiering. For model knowledge citations, use one of three tiers: [settled] — stable, well known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22 as a concept, the existence of Regulation (EU) 2024/1689 as the EU AI Act). Still verify before certifying, but lower priority. [verify] — model knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, standards, effective dates, thresholds, post 2023 amendments. [verify pinpoint] — pinpoint citations (specific article numbers, annex references, subsection letters, paragraph numbers) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text. Other sources keep their own tags: [registry] when drawn from the practice profile's use case registry; [Westlaw] , [EUR Lex] , [regulator site] , or the MCP tool name when retrieved from a connected legal research tool; [web search — verify] for web search citations; [user provided] for user supplied citations. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags. For non lawyer users, uncertain dates and thresholds go in a confirm list, not inline. A [verify] tag on "effective February 1, 2026" reads as "effective February 1, 2026" to someone who doesn't know what the tag means. Read Who's using this in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . If Role is Non lawyer and an effective date, phase in, threshold, or deadline is uncertain (would carry [verify] or [verify pinpoint] if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel") and collect all uncertain assertions in a final triage section titled: " Things I'm not certain about — ask your attorney to confirm before relying on this: " with each item listed (what I said, what's uncertain, why it matters). Lawyer role users keep the inline [verify] treatment. Step 3: Red line check Before going further, check the red lines in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . If the use case triggers a red line — even partially, even in a charitable reading — say so immediately. "This use case touches [red line]. Your red lines treat this as an automatic no. If there's something different about this situation, that's a conversation for legal sign off — not a triage call." Do not soften red line outcomes. If it's a no, it's a no. Jurisdictional scope. Ask: "Who's affected, and where are they? (Employees / customers / the general public / specific groups.) Which jurisdictions? (Not just where your company is — where the affected people are.)" Then check the use case against EVERY regime in the practice profile's Regulatory footprint , not just the primary one. Flag conflicts: "APPROVED under US law, but triggers EU AI Act Article 27 FRIA if EU residents are affected — confirm whether any affected individuals are in the EU." "Standard tier under your governance framework, but NYC LL144 requires a bias audit if used for hiring decisions affecting NYC residents." "Low risk under Australian AI Ethics Framework, but may be high risk under the Colorado AI Act if Colorado residents are affected." A use case that crosses jurisdictions gets the strictest applicable treatment, not the most convenient one. Step 4: Classification and output The APPROVED / CONDITIONAL / NOT APPROVED buckets, the red line definitions, and the CONDITIONAL required controls list all come from ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md → AI use case triage criteria and Use case registry . If the playbook doesn't define a criterion the use case turns on, ask the user: "Your playbook doesn't cover [specific question]. What's your default position? I'll add it to ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md so the next triage is consistent." Before issuing an APPROVED classification (approving an AI use case for deployment): Read Who's using this in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . If the Role is Non lawyer: Approving this use case for deployment has legal consequences. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them: [Generate a 1 page summary: the use case and its scope, how it maps to the registry, what policies or red lines it touches, what could go wrong in deployment, what to ask the attorney before green lighting.] If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent). Do not proceed past this gate without an explicit yes. CONDITIONAL outputs do not require the gate. Before issuing a NOT APPROVED classification that cuts off a proposed use case: Read Who's using this in ~/.claude/plugins/config/claude for legal/ai governance legal/CLAUDE.md . If the Role is Non lawyer, a symmetric gate applies — wrongly rejecting a use case is also a consequential error, and the business will push back regardless of the triage call: This is a full stop for a business ask. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them: [Generate a 1 page summary: the use case and its scope, the specific red line or registry entry that blocks it, what a narrower version could look like that might clear elevated tier (if anything), what the business will likely ask the attorney for, and the three questions to ask the attorney before accepting the no.] If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest start

use-case-triage