Update to Compliance Horizon Scanner

{
  "description": "Build or update the compliance profile that scopes every horizon scan — the business's legal entities, operating jurisdictions, sector, headcount, data and AI exposure, supply chain, and materiality thresholds. Use when the user is setting up for the first time, has no profile yet, or needs to change one after a business change such as a new jurisdiction, product line, or headcount shift. Emits a portable YAML block the user saves and supplies to later scans.",
  "included_files": [],
  "name": "compliance-profile",
  "skill_md_contents": "---\nname: compliance-profile\ndescription: Build or update the compliance profile that scopes every horizon scan — the business's legal entities, operating jurisdictions, sector, headcount, data and AI exposure, supply chain, and materiality thresholds. Use when the user is setting up for the first time, has no profile yet, or needs to change one after a business change such as a new jurisdiction, product line, or headcount shift. Emits a portable YAML block the user saves and supplies to later scans.\n---\n\nRead `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.\n\n\nThe profile is the plugin's only memory. It scopes the scan to one business and carries the scan\nstate that makes later runs incremental. Getting it right is what separates a relevant scan from a\ngeneric one.\n\nRead `../../references/profile-schema.md` for the full field reference and vocabulary.\n\n---\n\n## 1. Establish whether this is new or an update\n\nAsk for an existing profile block first. If there is one, go to §5.\n\n## 2. Interview — ask only what you cannot infer\n\nWork through the schema, but do not read it out as a form. Ask in the order below, group related\nquestions, and infer what you reasonably can from what the user has already said — then state your\ninference so they can correct it.\n\n**Identity and footprint** (needed)\n- Legal entities and where each is incorporated\n- Where the business actually operates — use the `operating_jurisdictions` vocabulary\n- For US coverage, offer federal-only (default) or federal plus selected states. Ask which\n  states matter, accept names or postal codes, and save them in `coverage.us_states` using\n  the schema. Explain state research is bounded by reachable official sources. Ask only\n  if the preference is not already clear; never enable every state automatically.\n- Sector, in the user's own words; add NAICS/SIC if they know them\n- Headcount per jurisdiction, roughly\n- Public company? If so, listing venues\n- Revenue band, roughly\n\n**Exposure** (this is what makes the scan specific — worth the time)\n- What personal data: customer, employee, health, biometric, children, financial, location\n- AI anywhere: in the product, in hiring, in credit decisions, internal only\n- Consumer-facing? Payments?\n- Regulated products\n- Export-controlled items; any touchpoints with sanctioned jurisdictions\n- Physical sites, and how far the supply chain is mapped\n- Unionised workforce\n\n**Thresholds**\n- Report at `medium` and above (default), or a different cut\n- Anything to always surface regardless of score — default is criminal liability, personal\n  liability for directors and officers, and licence conditions\n\n### How to ask well\n\n**Don't ask what you can infer, but do confirm it.** If they say \"we're a UK SaaS business selling\nto consumers in Europe,\" set `consumer_facing: true`, `sector` to software, and propose `UK` and\n`EU` — then say what you assumed and let them correct it.\n\n**Headcount matters more than it looks.** Several employment and reporting obligations turn on\nthresholds, so an approximate number per jurisdiction is worth pressing for gently. \"Roughly how\nmany people in the UK — under 50, under 250, or more?\" gets there without an interrogation.\n\n**Push a little on the exposure flags, and only there.** These are where a wrong value produces\nconfidently irrelevant results. `biometric` and `children` in particular pull in materially\ndifferent regimes, and users often don't volunteer them — face unlock, age-gated sign-up, or a\nphoto feature all count. Ask directly.\n\n**Don't guess an exposure flag to be safe.** Setting `biometric: true` on a hunch floods every\nlater scan with irrelevant high-impact findings and trains the user to ignore the output. If you\ndon't know, ask; if the user doesn't know, record it as unknown and say the next scan may miss or\nover-report in that area.\n\n## 3. Set the scan-state fields\n\n- `last_scan_date` → **90 days before today**, and say so\n- `reported_ledger` → empty\n- `profile_version: 1`, and a `profile_name` the user will recognise\n\n## 4. Emit the block and explain what to do with it\n\nOutput the complete YAML block, then, in two or three sentences:\n\n- **Save it** — in a project file or notes. Supply it at the start of each scan.\n- **Each scan returns an updated block. Save that one too.** This is how \"what's new since last\n  time\" works; skip it and every scan re-reports the same items.\n- Echo selected states (or “state coverage off”). Name unselected profile states, local law,\n  and EU member-state implementation as exclusions. Use the pending baseline rules when\n  adding or removing states; preserve the existing global scan date and ledger.\n\nThen offer to run the first scan, noting it will be a 90-day baseline rather than a delta.\n\n## 5. Updating an existing profile\n\nAccept a partial change without re-interviewing. Keep `last_scan_date` and `reported_ledger`\nexactly as they are — an update is not a reset, and clearing the ledger would re-report everything.\n\nChange only what the user asked for, then re-emit the whole block so they have one current artifact\nto save.\n\nFor scope-expanding changes, also create `coverage.pending_scope_baselines` entries under the\nschema rules. Explain that the next scan checks earlier developments and standing obligations\nrelevant to the change, not only publications since the last scan. Preserve pending work and all\nsaved rule snapshots. Do not promise coverage of unsupported countries or silently select states.\n\n**Say when a change alters what will be in scope.** Adding `biometric` to `personal_data`, crossing\na headcount threshold, or adding a jurisdiction changes what the next scan surfaces, and the user\nshould hear that from you rather than be surprised by a scan that suddenly looks different:\n\n> Added `biometric`. That engages special-category data rules and, with `in_product` AI, high-risk\n> AI classification — your next scan will likely surface materially more in `privacy_ai`.\n\n**Never silently correct a field the user set.** If something looks wrong — headcount inconsistent\nwith revenue band, a jurisdiction with no entity or staff — raise it as a question. The profile is\ntheir artifact and counsel may have set a value deliberately.\n"
}