/policy-diff

1. Load ~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md → policy library index.
2. Use the workflow below.
3. Extract requirements from the reg. Match to indexed policies.
4. Output: per-requirement gap analysis, which policy needs updating.

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

Purpose

A reg changed. You have policies. This skill finds which policies the change touches and what the gap is between "what the reg now requires" and "what the policy says."

Load context

~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md → policy library index (policies, locations, owners).

Scope integrity

If the user asks you to exclude a policy section, requirement, or category from the diff:

1. Do it — the user owns the scope.
2. But flag it, loudly and permanently: "⚠️ SCOPE LIMITATION: Section [X] excluded at user request. This diff does not reflect the full policy. Gaps in the excluded area are NOT identified." Above the header, carried to every downstream artifact.
3. Hand the flag to gap-surfacer: "This diff was scope-limited. Do not represent it as a complete compliance picture." Include the scope-limitation banner verbatim on any gap tracker entry derived from this diff.
4. Note what the exclusion means: "Excluding vendor management means the diff will show 'no policy addresses vendor management' — which is worse than showing the gap."

A compliance artifact built on an undisclosed scope exclusion looks like concealment in discovery. The flag is the difference between "we scoped the review" and "we hid the problem."

Workflow

Step 0: Verify rule status before you diff

Before diffing a rule against policy, confirm the rule is actually in force. Red flags that the rule may not be in force:

• The applicability/compliance date has passed by more than 30 days but you have no confirmation it wasn't delayed
• The rule is more than 12 months old
• The rule is a politically contentious final rule (major rulemakings are frequently challenged)

When you see a red flag, check (via research MCP, web search if enabled, or the Federal Register docket) for: delays, stays, injunctions, rescission proposals, vacatur, or amendments. If you can check and the rule is confirmed in force, proceed. If you cannot verify (no tools connected), emit this banner ABOVE the header, before any content:

⚠️ RULE STATUS UNVERIFIED — I could not confirm this rule is currently in force. Final rules are frequently stayed, enjoined, delayed, or rescinded after publication. Do not treat any compliance date below as binding until you confirm the rule's status at the Federal Register docket or with outside counsel.

Tag every due date in the output: [due date per published rule — status unverified].

Rule-status uncertainty travels downstream. When handing off a gap to gap-surfacer, mark the item status_verified: false so it never gets routed to an Overdue bucket on the strength of a published date alone.

Step 1: Extract the new requirements

…