[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718QV8HAB8PR2PCK9GT2MX9":3,"skill-same:01M718QV8HAB8PR2PCK9GT2MX9":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M718QV8HAB8PR2PCK9GT2MX9","use-case-triage",null,"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 perspective\", or describes a new data processing activity, product feature, or vendor relationship.","anthropics\u002Fclaude-for-legal","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M7189QY7HXHMC9BW4MFHPZ6H",9970,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fprivacy-legal\u002Fskills\u002Fuse-case-triage\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"use case triage","use","case","triage","case triage","feature","next step","describe","data","activity","surfaces","product","next","privacy policy","conflicts","dpia","relationship","when","new","processing","2026-11-10 10:12:30",false,"---\nname: use-case-triage\ndescription: >\n  Quickly determine whether a processing activity needs a PIA, a mandatory GDPR\n  DPIA, or can proceed — surfaces privacy policy conflicts and routes to the right\n  next step. Use when the user asks \"does this need a PIA\", \"triage this feature\",\n  \"privacy check on X\", \"is this okay from a privacy perspective\", or describes a\n  new data processing activity, product feature, or vendor relationship.\nargument-hint: \"[describe the data processing activity or feature]\"\n---\n\n# \u002Fuse-case-triage\n\n1. Read `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md`. Confirm privacy practice is configured — if not, stop and direct to setup.\n2. Run the workflow below. Clarify the activity if vague.\n3. House trigger check → mandatory DPIA check (if GDPR in footprint) → privacy policy conflict check.\n4. Output: classification (PROCEED \u002F PIA REQUIRED \u002F DPIA MANDATORY \u002F STOP), reasoning, conditions table if required, cross-plugin handoffs.\n5. Offer to continue into PIA generation if assessment is required.\n\n```\n\u002Fprivacy-legal:use-case-triage \"New feature that uses behavioral data to personalize content recommendations\"\n```\n\n---\n\n# Privacy Use Case Triage\n\n## Matter context\n\n**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 `\u002Fprivacy-legal:matter-workspace switch \u003Cslug>` or say `practice-level`.\" Load the active matter's `matter.md` for matter-specific context and overrides. Write outputs to the matter folder at `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002Fmatters\u002F\u003Cmatter-slug>\u002F`. Never read another matter's files unless `Cross-matter context` is `on`.\n\n---\n\n## Destination check\n\nBefore 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\u002Fopposing 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.\n\n## Purpose\n\nAnswer the question that comes up before anyone runs a PIA: \"does this thing even\nneed one?\" And if it does, what kind, and what's blocking the way?\n\nPrivacy triage is faster than PIA generation but upstream of it. It doesn't write\nthe assessment — it determines whether one is needed and on what terms. The PIA\ngeneration skill does the deep work.\n\nThe output is one of four classifications:\n- **PROCEED** — No PIA needed. Standard safeguards apply.\n- **PIA REQUIRED** — Assessment needed before or alongside deployment.\n- **DPIA MANDATORY** — A regime-mandated data protection impact assessment is\n  required (research the applicable regime's trigger and cite primary sources).\n  Harder bar, DPO\u002FGC involvement likely.\n- **STOP** — Processing activity conflicts with the privacy policy or has no\n  lawful basis as described. Needs redesign before proceeding.\n\n## Jurisdiction assumption\n\nThis 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.\n\n## Read the config first\n\nBefore triaging, always read `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md`. The PIA trigger criteria, regulatory\nfootprint, and privacy policy commitments there are authoritative. Generic privacy\nlaw reasoning is not a substitute for what this company has actually committed to.\n\nIf the file is missing or contains `[PLACEHOLDER]`, surface this bounce:\n\n> 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.\n>\n> **Two choices:**\n> - Run `\u002Fprivacy-legal:cold-start-interview` (2 minutes) to configure your profile, then I'll triage tailored to YOUR practice.\n> - 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.\n\n### Provisional mode\n\nIf the user says \"provisional,\" run triage normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction (CCPA + common federal sectoral baselines), no playbook (classify from general privacy-law principles rather than matching to configured commitments). Tag the reviewer note and every finding block with `[PROVISIONAL]`. At the end of the output, append:\n\n> \"That was a generic run against default assumptions. Run `\u002Fprivacy-legal:cold-start-interview` to get output calibrated to YOUR practice — your regulatory footprint, your privacy policy commitments, your risk appetite. 2 minutes.\"\n\n---\n\n## Triage process\n\n### Step 1: Understand the activity\n\nIf the description is vague, ask before classifying. Get specific on:\n\n- What data is being collected or processed? Which categories?\n- Who are the data subjects — customers, employees, third parties?\n- What's the purpose? What problem is this solving?\n- Is this new data collection, or repurposing data you already have?\n- Is a third-party vendor involved? New vendor or existing?\n- Is any automated decision-making involved — does the output affect anyone?\n- What's the deployment context — internal only, customer-facing, public?\n\n\"New feature\" and \"data processing activity\" are not enough to triage accurately.\n\n---\n\n### Step 2: Check house triggers\n\nRead `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## PIA house style` → Trigger criteria. Apply them.\n\nIf the house trigger is met → at minimum **PIA REQUIRED**.\n\nIf house trigger is not met, continue to Step 3 before concluding PROCEED. Some\nactivities need a PIA regardless of internal policy.\n\n---\n\n### Step 3: Mandatory assessment check\n\n**Before researching regime-specific triggers, ask the activity-based federal overlay question first.** If the processing touches a federally-regulated data category, the federal overlay is usually the controlling framework, not state privacy law, and the triage needs to surface that early rather than as an afterthought.\n\n> **Activity-based federal overlays — ask first:**\n>\n> Does this processing touch:\n> - **Financial account data or \"nonpublic personal information\" about consumers** (GLBA \u002F Reg P — applies to financial institutions and their non-affiliated third parties; imposes substantive restrictions on sharing NPI for marketing, separate from and on top of any state privacy-law exemption)?\n> - **Protected health information held by a covered entity or business associate** (HIPAA Privacy \u002F Security Rules — substantive restrictions on use and disclosure, breach notification at 500+ records, BAA required for any vendor)?\n> - **Education records held by a school or a service provider acting for a school** (FERPA — consent requirements for disclosure, directory-information carve-outs)?\n> - **Data from children under 13 collected by an operator of an online service directed to children or with actual knowledge** (COPPA — parental consent, notice, deletion rights, strict limits on retention and sharing)?\n> - **Another sectoral federal regime** (e.g., VPPA for video-viewing records, CPNI for carrier data, DPPA for DMV records, TCPA for SMS\u002Fcall consent)?\n>\n> If yes to any: the federal overlay usually supplies the controlling substantive restriction, not just an exemption from a state consumer privacy law. Research and cite the specific provision before continuing. An activity that is \"exempt\" from CCPA under § 1798.145(e) because it is GLBA-covered is still subject to the GLBA restrictions (e.g., § 6802(a)-(c) on NPI sharing) — the CCPA exemption does not make the activity lawful; it just moves the governing framework to GLBA.\n\nFor each regime in `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## Regulatory footprint`, **research the currently operative mandatory privacy\u002Fdata-protection assessment triggers**. Cite controlling statute, regulation, or regulator guidance with pinpoint references. Note effective dates — national and state regulators publish and update trigger lists regularly; do not rely on a static checklist. Flag uncertainty for attorney verification rather than guess.\n\nIf **any** applicable regime's mandatory trigger is met → **DPIA MANDATORY** (or the equivalent regime-specific mandate), regardless of house trigger.\n\n**Strong indicators (not necessarily mandatory but do one anyway):**\n- New technology or novel use of existing technology\n- Children's data\n- Combining datasets that weren't collected together\n- Data that could enable discrimination\n- Processing users would not expect\n- Lookalike audiences, cross-context behavioral advertising, or other tracking-based ad-tech activity (recurring question for consumer-facing companies; surfaces policy-commitment conflicts and federal sectoral overlays reliably)\n\nOne or more strong indicators with no researched mandatory trigger → escalate to **PIA REQUIRED**\n(not DPIA mandatory, but flag in the output).\n\n---\n\n### Step 4: Privacy policy conflict check\n\nRead `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## Privacy policy commitments`. Check the proposed activity\nagainst every stated commitment.\n\n**Common conflicts to catch:**\n- Policy says \"we collect X, Y, Z\" — this activity collects W. Policy update\n  needed before launch, or stop collecting W.\n- Policy says \"we don't sell or share data with third parties\" — this activity\n  passes data to a vendor for their own purposes. Research whether the flow falls\n  within a regulated \"sale,\" \"share,\" or other disclosure category under each\n  applicable regime.\n- Policy states retention limits — this activity retains data longer.\n- Policy says \"we use data only for [purpose]\" — this activity uses it for a new\n  purpose without fresh consent or legitimate interest assessment.\n- Policy specifies user rights offered — this activity creates a new data category\n  the rights process wasn't built for.\n\nIf a direct conflict exists → **STOP**. Not \"proceed with caution\" — the policy\nconflict has to be resolved (policy update or activity redesign) before this\nproceeds.\n\n---\n\n### Step 5: Classification and output\n\n---\n\n### Bottom line\n[PIA required \u002F Mandatory DPIA required \u002F Proceed — one-sentence why]\n\n---\n\n**ACTIVITY:** [State the processing activity as you understand it]\n\n**CLASSIFICATION:** [PROCEED \u002F PIA REQUIRED \u002F DPIA MANDATORY \u002F STOP]\n\n**House trigger met?** [Yes \u002F No]\n**GDPR mandatory DPIA trigger?** [Yes — [trigger] \u002F No \u002F N\u002FA (GDPR not in footprint)]\n**Privacy policy conflict?** [None \u002F Yes — [specific conflict]]\n\n**Reasoning:**\n[1-3 sentences. For PROCEED: what makes it safe under current policy. For PIA\u002FDPIA:\nwhat creates the obligation. For STOP: which specific policy commitment or principle\nis in conflict.]\n\n---\n\n*If PIA REQUIRED or DPIA MANDATORY — conditions before proceeding:*\n\n| Requirement | Owner | Done? |\n|---|---|---|\n| [e.g., Privacy Impact Assessment — full DPIA format] | [Privacy counsel] | ☐ |\n| [e.g., Legitimate interest assessment (if LI basis)] | [Privacy counsel] | ☐ |\n| [e.g., DPO consultation (DPIA mandatory track)] | [DPO] | ☐ |\n| [e.g., Vendor DPA in place] | [Privacy \u002F Legal] | ☐ |\n| [e.g., Privacy policy update before launch] | [Privacy counsel] | ☐ |\n| [e.g., Consent mechanism built and tested] | [Product] | ☐ |\n| [e.g., Data subject rights process covers new data category] | [Privacy \u002F Product] | ☐ |\n\n**Lawful basis (if GDPR in footprint):** [Consent \u002F Contract \u002F Legitimate Interest \u002F\nLegal Obligation — or \"unclear — needs determination in PIA\"]\n\n**Next step — offer to continue:**\n\nAfter presenting a PIA REQUIRED or DPIA MANDATORY result, always end with:\n\n> \"Want me to start the PIA now? I can run the intake questions and produce the\n> assessment document without you needing to run a separate command.\"\n\nIf they say yes, load the `pia-generation` skill and continue in the same\nconversation — pass the activity description and any triggers already identified.\n\nIf they say no, the triage result stands. The PIA can be run any time with:\n`\u002Fprivacy-legal:pia-generation [activity]`\n\n---\n\n*If STOP:*\n\n**Conflict:** [Specific privacy policy commitment or principle in conflict]\n\n**To proceed, one of these has to change:**\n- [Option A — redesign the activity so it doesn't create the conflict]\n- [Option B — update the privacy policy to cover this processing (requires review\n  of whether the update is itself consistent with lawful basis)]\n\nDon't offer a path forward if there isn't one. If the processing simply can't be\nreconciled with stated commitments or lawful basis, say so.\n\n---\n\n### Step 6: Cross-plugin handoffs\n\n**AI governance handoff:** If the activity involves an AI system making or\ninfluencing decisions about individuals:\n\n> \"This activity involves AI decision-making. An AI impact assessment is likely\n> required in addition to a PIA. Use `\u002Fai-governance-legal:aia-generation [activity]`\n> to run that in parallel — they're not substitutes.\"\n\n**Product counsel handoff:** If this is a new product feature or launch:\n\n> \"If this is part of a product launch, loop in product counsel.\n> Use `\u002Fproduct-legal:launch-review` — it will detect the privacy component\n> and route to this plugin.\"\n\nOnly flag handoffs that are actually relevant. Don't append both as boilerplate.\n\n---\n\n## Batch triage\n\nIf the user presents a feature list, roadmap, or backlog — summary table first,\nthen expand each non-PROCEED entry:\n\n| # | Activity | Classification | Key condition \u002F blocker |\n|---|---|---|---|\n| 1 | [activity] | 🟢 Proceed | — |\n| 2 | [activity] | 🟡 PIA required | Lawful-basis assessment needed; vendor DPA not in place |\n| 3 | [activity] | 🟠 DPIA mandatory | Large-scale special category data |\n| 4 | [activity] | 🔴 Stop | Privacy policy conflict — purpose limitation |\n\n---\n\n## Edge cases and failure modes\n\n**\"It's anonymized\" doesn't automatically mean PROCEED.**\nAsk how it's anonymized and whether re-identification is realistically possible\ngiven the data set. Pseudonymized data is still personal data under GDPR.\n\n**\"We already do something similar\" isn't a triage.**\nExisting processing that was never assessed doesn't grandfather new processing.\nIf the new activity is materially different in scale, purpose, or data category,\ntriage it fresh.\n\n**\"Just a pilot\" doesn't skip triage.**\nA pilot that touches real user or employee data is subject to the same triggers.\nApply the same classification; if a PIA is required, the pilot should have one.\n\n**\"The vendor handles all the privacy.\"**\nVendor handles the infrastructure. You're still the controller determining the\npurposes. If personal data flows to the vendor, a DPA is required and triage still\napplies to the purpose.\n\n**Inferred data and derived attributes count.**\nIf the activity generates inferred data about individuals (e.g., a behavioral score,\na predicted preference), treat the inferred attribute as personal data for triage\npurposes. Don't let \"we're just computing a score\" obscure what the score represents.\n\n## Close with the next-steps decision tree\n\nEnd with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.\n","# \u002Fuse-case-triage\n\n1. Read `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md`. Confirm privacy practice is configured — if not, stop and direct to setup.\n2. Run the workflow below. Clarify the activity if vague.\n3. House trigger check → mandatory DPIA check (if GDPR in footprint) → privacy policy conflict check.\n4. Output: classification (PROCEED \u002F PIA REQUIRED \u002F DPIA MANDATORY \u002F STOP), reasoning, conditions table if required, cross-plugin handoffs.\n5. Offer to continue into PIA generation if assessment is required.\n\n```\n\u002Fprivacy-legal:use-case-triage \"New feature that uses behavioral data to personalize content recommendations\"\n```\n\n---\n\n# Privacy Use Case Triage\n\n## Matter context\n\n**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 `\u002Fprivacy-legal:matter-workspace switch \u003Cslug>` or say `practice-level`.\" Load the active matter's `matter.md` for matter-specific context and overrides. Write outputs to the matter folder at `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002Fmatters\u002F\u003Cmatter-slug>\u002F`. Never read another matter's files unless `Cross-matter context` is `on`.\n\n---\n\n## Destination check\n\nBefore 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\u002Fopposing 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.\n\n## Purpose\n\nAnswer the question that comes up before anyone runs a PIA: \"does this thing even\nneed one?\" And if it does, what kind, and what's blocking the way?\n\nPrivacy triage is faster than PIA generation but upstream of it. It doesn't write\nthe assessment — it determines whether one is needed and on what terms. The PIA\ngeneration skill does the deep work.\n\nThe output is one of four classifications:\n- **PROCEED** — No PIA needed. Standard safeguards apply.\n- **PIA REQUIRED** — Assessment needed before or alongside deployment.\n- **DPIA MANDATORY** — A regime-mandated data protection impact assessment is\n  required (research the applicable regime's trigger and cite primary sources).\n  Harder bar, DPO\u002FGC involvement likely.\n- **STOP** — Processing activity conflicts with the privacy policy or has no\n  lawful basis as described. Needs redesign before proceeding.\n\n## Jurisdiction assumption\n\nThis 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.\n\n## Read the config first\n\nBefore triaging, always read `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md`. The PIA trigger criteria, regulatory\nfootprint, and privacy policy commitments there are authoritative. Generic privacy\nlaw reasoning is not a substitute for what this company has actually committed to.\n\nIf the file is missing or contains `[PLACEHOLDER]`, surface this bounce:\n\n> 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.\n>\n> **Two choices:**\n> - Run `\u002Fprivacy-legal:cold-start-interview` (2 minutes) to configure your profile, then I'll triage tailored to YOUR practice.\n> - 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.\n\n### Provisional mode\n\nIf the user says \"provisional,\" run triage normally using these generic defaults: middle risk appetite, lawyer role, US jurisdiction (CCPA + common federal sectoral baselines), no playbook (classify from general privacy-law principles rather than matching to configured commitments). Tag the reviewer note and every finding block with `[PROVISIONAL]`. At the end of the output, append:\n\n> \"That was a generic run against default assumptions. Run `\u002Fprivacy-legal:cold-start-interview` to get output calibrated to YOUR practice — your regulatory footprint, your privacy policy commitments, your risk appetite. 2 minutes.\"\n\n---\n\n## Triage process\n\n### Step 1: Understand the activity\n\nIf the description is vague, ask before classifying. Get specific on:\n\n- What data is being collected or processed? Which categories?\n- Who are the data subjects — customers, employees, third parties?\n- What's the purpose? What problem is this solving?\n- Is this new data collection, or repurposing data you already have?\n- Is a third-party vendor involved? New vendor or existing?\n- Is any automated decision-making involved — does the output affect anyone?\n- What's the deployment context — internal only, customer-facing, public?\n\n\"New feature\" and \"data processing activity\" are not enough to triage accurately.\n\n---\n\n### Step 2: Check house triggers\n\nRead `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## PIA house style` → Trigger criteria. Apply them.\n\nIf the house trigger is met → at minimum **PIA REQUIRED**.\n\nIf house trigger is not met, continue to Step 3 before concluding PROCEED. Some\nactivities need a PIA regardless of internal policy.\n\n---\n\n### Step 3: Mandatory assessment check\n\n**Before researching regime-specific triggers, ask the activity-based federal overlay question first.** If the processing touches a federally-regulated data category, the federal overlay is usually the controlling framework, not state privacy law, and the triage needs to surface that early rather than as an afterthought.\n\n> **Activity-based federal overlays — ask first:**\n>\n> Does this processing touch:\n> - **Financial account data or \"nonpublic personal information\" about consumers** (GLBA \u002F Reg P — applies to financial institutions and their non-affiliated third parties; imposes substantive restrictions on sharing NPI for marketing, separate from and on top of any state privacy-law exemption)?\n> - **Protected health information held by a covered entity or business associate** (HIPAA Privacy \u002F Security Rules — substantive restrictions on use and disclosure, breach notification at 500+ records, BAA required for any vendor)?\n> - **Education records held by a school or a service provider acting for a school** (FERPA — consent requirements for disclosure, directory-information carve-outs)?\n> - **Data from children under 13 collected by an operator of an online service directed to children or with actual knowledge** (COPPA — parental consent, notice, deletion rights, strict limits on retention and sharing)?\n> - **Another sectoral federal regime** (e.g., VPPA for video-viewing records, CPNI for carrier data, DPPA for DMV records, TCPA for SMS\u002Fcall consent)?\n>\n> If yes to any: the federal overlay usually supplies the controlling substantive restriction, not just an exemption from a state consumer privacy law. Research and cite the specific provision before continuing. An activity that is \"exempt\" from CCPA under § 1798.145(e) because it is GLBA-covered is still subject to the GLBA restrictions (e.g., § 6802(a)-(c) on NPI sharing) — the CCPA exemption does not make the activity lawful; it just moves the governing framework to GLBA.\n\nFor each regime in `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## Regulatory footprint`, **research the currently operative mandatory privacy\u002Fdata-protection assessment triggers**. Cite controlling statute, regulation, or regulator guidance with pinpoint references. Note effective dates — national and state regulators publish and update trigger lists regularly; do not rely on a static checklist. Flag uncertainty for attorney verification rather than guess.\n\nIf **any** applicable regime's mandatory trigger is met → **DPIA MANDATORY** (or the equivalent regime-specific mandate), regardless of house trigger.\n\n**Strong indicators (not necessarily mandatory but do one anyway):**\n- New technology or novel use of existing technology\n- Children's data\n- Combining datasets that weren't collected together\n- Data that could enable discrimination\n- Processing users would not expect\n- Lookalike audiences, cross-context behavioral advertising, or other tracking-based ad-tech activity (recurring question for consumer-facing companies; surfaces policy-commitment conflicts and federal sectoral overlays reliably)\n\nOne or more strong indicators with no researched mandatory trigger → escalate to **PIA REQUIRED**\n(not DPIA mandatory, but flag in the output).\n\n---\n\n### Step 4: Privacy policy conflict check\n\nRead `~\u002F.claude\u002Fplugins\u002Fconfig\u002Fclaude-for-legal\u002Fprivacy-legal\u002FCLAUDE.md` → `## Privacy policy commitments`. Check the proposed activity\nagainst every stated commitment.\n\n**Common conflicts to catch:**\n- Policy says \"we collect X, Y, Z\" — this activity collects W. Policy update\n  needed before launch, or stop collecting W.\n- Policy says \"we don't sell or share data with third parties\" — this activity\n  passes data to a vendor for their own purposes. Research whether the flow falls\n  within a regulated \"sale,\" \"share,\" or other disclosure category under each\n  applicable regime.\n- Policy states retention limits — this activity retains data longer.\n- Policy says \"we use data only for [purpose]\" — this activity uses it for a new\n  purpose without fresh consent or legitimate interest assessment.\n- Policy specifies user rights offered — this activity creates a new data category\n  the rights process wasn't built for.\n\nIf a direct conflict exists → **STOP**. Not \"proceed with caution\" — the policy\nconflict has to be resolved (policy update or activity redesign) before this\nproceeds.\n\n---\n\n### Step 5: Classification and output\n\n---\n\n### Bottom line\n[PIA required \u002F Mandatory DPIA required \u002F Proceed — one-sentence why]\n\n---\n\n**ACTIVITY:** [State the processing activity as you understand it]\n\n**CLASSIFICATION:** [PROCEED \u002F PIA REQUIRED \u002F DPIA MANDATORY \u002F STOP]\n\n**House trigger met?** [Yes \u002F No]\n**GDPR mandatory DPIA trigger?** [Yes — [trigger] \u002F No \u002F N\u002FA (GDPR not in footprint)]\n**Privacy policy conflict?** [None \u002F Yes — [specific conflict]]\n\n**Reasoning:**\n[1-3 sentences. For PROCEED: what makes it safe under current policy. For PIA\u002FDPIA:\nwhat creates the obligation. For STOP: which specific policy commitment or principle\nis in conflict.]\n\n---\n\n*If PIA REQUIRED or DPIA MANDATORY — conditions before proceeding:*\n\n| Requirement | Owner | Done? |\n|---|---|---|\n| [e.g., Privacy Impact Assessment — full DPIA format] | [Privacy counsel] | ☐ |\n| [e.g., Legitimate interest assessment (if LI basis)] | [Privacy counsel] | ☐ |\n| [e.g., DPO consultation (DPIA mandatory track)] | [DPO] | ☐ |\n| [e.g., Vendor DPA in place] | [Privacy \u002F Legal] | ☐ |\n| [e.g., Privacy policy update before launch] | [Privacy counsel] | ☐ |\n| [e.g., Consent mechanism built and tested] | [Product] | ☐ |\n| [e.g., Data subject rights process covers new data category] | [Privacy \u002F Product] | ☐ |\n\n**Lawful basis (if GDPR in footprint):** [Consent \u002F Contract \u002F Legitimate Interest \u002F\nLegal Obligation — or \"unclear — needs determination in PIA\"]\n\n**Next step — offer to continue:**\n\nAfter presenting a PIA REQUIRED or DPIA MANDATORY result, always end with:\n\n> \"Want me to start the PIA now? I can run the intake questions and produce the\n> assessment document without you needing to run a separate command.\"\n\nIf they say yes, load the `pia-generation` skill and continue in the same\nconversation — pass the activity description and any triggers already identified.\n\nIf they say no, the triage result stands. The PIA can be run any time with:\n`\u002Fprivacy-legal:pia-generation [activity]`\n\n---\n\n*If STOP:*\n\n**Conflict:** [Specific privacy policy commitment or principle in conflict]\n\n**To proceed, one of these has to change:**\n- [Option A — redesign the activity so it doesn't create the conflict]\n- [Option B — update the privacy policy to cover this processing (requires review\n  of whether the update is itself consistent with lawful basis)]\n\nDon't offer a path forward if there isn't one. If the processing simply can't be\nreconciled with stated commitments or lawful basis, say so.\n\n---\n\n### Step 6: Cross-plugin handoffs\n\n**AI governance handoff:** If the activity involves an AI system making or\ninfluencing decisions about individuals:\n\n> \"This activity involves AI decision-making. An AI impact assessment is likely\n> required in addition to a PIA. Use `\u002Fai-governance-legal:aia-generation [activity]`\n> to run that in parallel — they're not substitutes.\"\n\n**Product counsel handoff:** If this is a new product feature or launch:\n\n> \"If this is part of a product launch, loop in product counsel.\n> Use `\u002Fproduct-legal:launch-review` — it will detect the privacy component\n> and route to this plugin.\"\n\nOnly flag handoffs that are actually relevant. Don't append both as boilerplate.\n\n---\n\n## Batch triage\n\nIf the user presents a feature list, roadmap, or backlog — summary table first,\nthen expand each non-PROCEED entry:\n\n| # | Activity | Classification | Key condition \u002F blocker |\n|---|---|---|---|\n| 1 | [activity] | 🟢 Proceed | — |\n| 2 | [activity] | 🟡 PIA required | Lawful-basis assessment needed; vendor DPA not in place |\n| 3 | [activity] | 🟠 DPIA mandatory | Large-scale special category data |\n| 4 | [activity] | 🔴 Stop | Privacy policy conflict — purpose limitation |\n\n---\n\n## Edge cases and failure modes\n\n**\"It's anonymized\" doesn't automatically mean PROCEED.**\nAsk how it's anonymized and whether re-identification is realistically possible\ngiven the data set. Pseudonymized data is still personal data under GDPR.\n\n**\"We already do something similar\" isn't a triage.**\nExisting processing that was never assessed doesn't grandfather new processing.\nIf the new activity is materially different in scale, purpose, or data category,\ntriage it fresh.\n\n**\"Just a pilot\" doesn't skip triage.**\nA pilot that touches real user or employee data is subject to the same triggers.\nApply the same classification; if a PIA is required, the pilot should have one.\n\n**\"The vendor handles all the privacy.\"**\nVendor handles the infrastructure. You're still the controller determining the\npurposes. If personal data flows to the vendor, a DPA is required and triage still\napplies to the purpose.\n\n**Inferred data and derived attributes count.**\nIf the activity generates inferred data about individuals (e.g., a behavioral score,\na predicted preference), treat the inferred attribute as personal data for triage\npurposes. Don't let \"we're just computing a score\" obscure what the score represents.\n\n## Close with the next-steps decision tree\n\nEnd with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.\n",{"name":5,"description":44,"argument-hint":45},"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 perspective\", or describes a new data processing activity, product feature, or vendor relationship.\n","[describe the data processing activity or feature]","main","4a6c651889c97cc9140580363c73e0eb17379c2b","privacy-legal\u002Fskills\u002Fuse-case-triage",1958,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-08 22:42:37",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add anthropics\u002Fclaude-for-legal --skill use-case-triage",{"tool":60,"command":61},"bunx","bunx skills add anthropics\u002Fclaude-for-legal --skill use-case-triage",{"tool":63,"command":64},"pnpm","pnpm dlx skills add anthropics\u002Fclaude-for-legal --skill use-case-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fprivacy-legal\u002Fskills\u002Fuse-case-triage\u002FSKILL.md",true,[],[69,98,120,139,161,174],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":39},"01M718SG9G2R92ECCD0HYK2R5E","reg-feed-watcher","Check regulatory feeds now and report what's new since the last check, filtered by your materiality threshold. Use when the user says \"check the feeds\", \"what's new\", \"regulatory update\", when running from the scheduled agent, or when manually pasting a regulatory development for classification and diff.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Freg-feed-watcher\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[81,82,83,84,85,86,87,88,89,90,37,91,20,92,36,93,94,95,96,97],"reg","watcher","reg feed watcher","running","feeds","filtered","diff","development","for","classification","now","scheduled","check","last","update","report","regulatory",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":39},"01M718SCRTBN55DMTVSPG67A7N","policy-redraft","Produce a proposed marked-up policy redraft that closes a gap found by \u002Fregulatory-legal:gaps or \u002Fregulatory-legal:policy-diff. A first draft for internal review — not for direct application to approved policy documents. Use when the user says \"redraft the policy\", \"draft the policy fix\", \"mark up the policy\", or when gap-surfacer hands off a gap for drafting.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Fpolicy-redraft\u002FSKILL.md",[],[105,106,87,89,107,108,109,20,110,36,111,112,113,114,115,116,117,118,97,119],"policy","policy redraft","up","fix","produce","documents","drafting","gaps","review","draft","id","gap","mark","first","direct",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":39},"01M718S8RV0C4NMVKG078CBFXP","policy-diff","Diff a specific regulatory change against the indexed policy library. Use when a reg has changed and you need to know which policies it touches and what the gap is, when the user says \"diff this reg against our policies\", \"which policy does this affect\", or \"gap analysis\", or when reg-feed-watcher hands off a material item.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Fpolicy-diff\u002FSKILL.md",[],[87,105,127,128,36,129,130,81,131,82,132,133,134,135,20,136,116,137,138,97],"policy diff","which","you","analysis","text","change","paste","library","material","gap analysis","what the","name",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":39},"01M718S6521Y0FT4T24VCFKVG5","matter-workspace","Manage matter workspaces — create, list, switch, close, or detach the active matter (practice-level). Use when working across multiple clients or matters and you need to keep one engagement's context separate from another, or when a substantive skill needs to know which matter it's working in.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Fmatter-workspace\u002FSKILL.md",[],[146,147,128,148,149,150,37,20,36,129,151,152,153,154,155,156,157,158,159,160],"workspace","matter workspace","switch","manage","workspaces","keep","across","create","engagement","close","active","clients","list","it","context",{"skillNo":162,"name":112,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":39},"01M718S3FPEJNQGCMQ1AR8M4HE","Open gaps tracker — what's flagged and not yet closed. Use when the user asks \"what gaps are open\", \"gap tracker\", \"remediation status\", or wants to close (--close GAP-ID) or risk-accept (--accept GAP-ID) a tracked gap.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Fgaps\u002FSKILL.md",[],[112,115,116,167,155,168,169,170,171,20,172,36,173],"risk","tracker","remediation","status","open","accept","user",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":185,"publishedAt":39},"01M718S06WSZ9Y24JKYM0VVPPE","gap-surfacer","Reference: shared gap- and comment-tracker framework backing \u002Fregulatory-legal:gaps and \u002Fregulatory-legal:comments. Tracks open policy gaps with remediation status, ingests gaps from policy-diff, surfaces what's open and aging, routes to owners, and notifies gap owners via Slack with per-send confirmation. Loaded by the gaps and comments skills before doing substantive work.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-for-legal\u002Fblob\u002Fmain\u002Fregulatory-legal\u002Fskills\u002Fgap-surfacer\u002FSKILL.md",[180],{"categoryNo":181,"categoryName":182,"taxonomyType":183,"taxonomyTypeDesc":184},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[116,186,187,188,87,105,189,171,190,191,192,193,112,194,195,196,197,168,169,29],"gap surfacer","shared","tracks","send","confirmation","aging","false","comments","with","work","slack","via"]