Update to Compliance Horizon Scanner

{
  "description": "Build a forward calendar of dated regulatory obligations from scan findings or a compliance profile — comment deadlines, entry-into-force dates, applies-from dates, staged transition milestones, and first reporting dates — each carrying the source link and the quote that establishes it. Use when the user asks what is coming up, what deadlines they face, what to diarise, or wants a compliance calendar or timeline for a quarter, year, or specific regulation.",
  "included_files": [],
  "name": "compliance-calendar",
  "skill_md_contents": "---\nname: compliance-calendar\ndescription: Build a forward calendar of dated regulatory obligations from scan findings or a compliance profile — comment deadlines, entry-into-force dates, applies-from dates, staged transition milestones, and first reporting dates — each carrying the source link and the quote that establishes it. Use when the user asks what is coming up, what deadlines they face, what to diarise, or wants a compliance calendar or timeline for a quarter, year, or specific regulation.\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\nTurn findings into dates the user can diarise, each traceable to the provision that sets it.\n\n**Read `../../references/citation-discipline.md` first.** This skill carries the highest fabrication\nrisk in the plugin: an unsourced date here gets entered in a diary, relied on, and either missed or\nacted on early. **A date with no quotable source is omitted and listed as a gap — never estimated,\nnever interpolated, never carried over from a similar instrument.**\n\n---\n\n## 1. Get the input\n\nEither the findings from a `horizon-scan` run, a specific instrument, or a compliance profile (in\nwhich case run a scan first, or work from the domains in scope).\n\n## 2. Extract every dated obligation\n\nFor each finding, pull out **every** date, not just the headline one. A single instrument commonly\ncarries several, and the one that matters to this user may not be the first:\n\n- consultation or comment deadline\n- adoption date\n- entry into force\n- applies-from / application date\n- staged milestones — by obligation, entity class, or product category\n- first reporting date, and the reporting period it covers\n- transitional or grandfathering cut-offs\n- review or sunset dates\n\n**Each becomes its own calendar entry.** Do not collapse a staged regime into a single date — the\nstaging is usually the operationally important part, and a business may be in scope for one stage\nand not another.\n\n## 3. Source every date individually\n\nEach entry carries the link and the verbatim quote from the provision that sets it. Different dates\nin one instrument usually come from different provisions; cite each to its own.\n\n**Derived dates.** Where a date must be computed — an EU act's \"twentieth day following that of its\npublication,\" a UK SI's \"the day after the day on which these Regulations are made\" — show the\narithmetic, quote the provision, and label it derived:\n\n> **28 September 2026** — entry into force *(derived: 20th day after OJ publication 8 September\n> 2026)* · \"shall enter into force on the twentieth day following that of its publication in the\n> *Official Journal of the European Union*\" · [CELEX 32026R1975](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1975)\n\n**Undated obligations.** These are common and must be represented honestly, not dropped and not\nguessed:\n\n- A proposed US rule has no effective date — `effective_on` is `null`. The comment deadline is the\n  one possible fixed date; hearing, registration, and other procedural dates may also be set.\n- A UK SI may commence \"on such day as the Secretary of State may by regulations appoint,\" which\n  means **no date exists yet**.\n- An EU directive's transposition deadline binds member states, not businesses; the business date\n  comes from national law, which is outside v1 coverage.\n\nPut all of these in an **Undated / pending** section with the reason and what will fix it. This\nsection is often the most useful part of the calendar, because it tells the user what to keep\nwatching rather than implying nothing is coming.\n\n## 4. Flag lead-time mismatches\n\nCompare each entry's `effort` score to the time available. Where effort exceeds lead time, flag it —\nthis is frequently the single most valuable output of the whole plugin:\n\n> ⚠️ **Lead-time risk** — `program_change` due in 41 days. Cross-functional work with under six\n> weeks of runway.\n\nRough guide, to be applied with judgement rather than mechanically: `program_change` needs quarters,\n`policy_change` needs weeks, `documentation_only` needs days.\n\n## 5. Output\n\nGroup by time bucket, soonest first, and make every date checkable:\n\n```\n## Compliance calendar · <profile_name>\nBuilt <date> from a horizon scan covering <window>. Dates are as published; verify before diarising.\n\n### Next 30 days\n| Date | What | Instrument | Effort | Source |\n|---|---|---|---|---|\n| 2026-09-30 | Comment deadline | DOL proposed rule 2026-15717 | — | \"<quote>\" [link] |\n\n### 30–90 days\n### 90–365 days\n### Beyond 12 months\n### Undated / pending\n| What | Why undated | What will fix it |\n|---|---|---|\n| Effective date, DOL 2026-15717 | Proposed rule; no effective date published | Final rule publication — re-scan `labor-department` monthly |\n\n### Lead-time risks\n<entries where effort exceeds available runway>\n\n**Provenance:** N dated entries, N sourced to a quoted provision · N derived (arithmetic shown) ·\nN undated and listed as pending · N coverage gaps\n\n---\nRegulatory intelligence, not legal advice. Verify each date against the cited source before relying\non it or entering it in a diary.\n```\n\n## 6. Self-check — strictly\n\nBefore returning, walk every entry:\n\n- [ ] every date traces to a verbatim quote from a document fetched this session\n- [ ] every derived date shows its arithmetic and the provision it rests on\n- [ ] no date is inferred from a similar instrument, from a typical pattern, or from recall\n- [ ] undated obligations appear in the pending section rather than being dropped or filled\n- [ ] the provenance tally is stated\n\nThen state the tally. If a date failed the check, it is not in the calendar — say so in the gaps\nline rather than including it with a caveat. A caveated date in a table still gets diarised.\n\n---\n\n## Offering it as a file\n\nUsers usually want this in their own calendar or tracker. Offer a CSV they can import, with columns\n`date,what,instrument,official_id,effort,source_url,supporting_quote`.\n\n**Keep `source_url` and `supporting_quote` as columns in the export.** They are what make an entry\ncheckable six months later, when whoever reads the row has forgotten where it came from and is\ndeciding whether to act on it. Stripping them for tidiness defeats the purpose of the calendar.\n"
}