在发现监管政策缺口后生成供内部审阅的政策修订标记稿（不直接改…

当 /regulatory-legal:gaps 或 /regulatory-legal:policy-diff 发现政策缺口，需要基于当前已批准政策文本与规则文本产出带批注、可审阅的政策修订提案时使用。

适用场景

解决思路

1. 加载 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`，读取 policy library index 和 practice profile。
2. 按本技能 workflow 执行。
3. 收集三类输入：缺口（来自 `/regulatory-legal:gaps` 输出或直接描述）、当前已批准政策文本、规则文本。
4. 验证规则是否为当前有效版本（按 policy-diff 的 rule-status check）。如果无法验证，发出 `⚠️ RULE STATUS UNVERIFIED` banner。
5. 对受影响的政策章节生成 marked-up redraft：最小可能编辑，贯穿保留 `[verify]` 标签，并用 inline comments 解释每处修改 WHY。
6. 输出 Policy Redraft Memo；写入新文件 `[policy-name]-proposed-redraft-[YYYY-MM-DD].md`，绝不写入源政策文档。
7. 不要在 tracker 中关闭缺口；缺口在 redraft 被应用 AND 批准后关闭，这是 policy owner 的行动。
8. 本技能产出 proposal，不是 edit；写入新文件且文件名明确标记为 draft，绝不覆盖源政策文档，绝不关闭 gap；gap 由 policy owner 应用并批准后关闭。
9. 检查 practice-level CLAUDE.md 的 `## Matter workspaces`。如果 `Enabled` 是 `✗`（in-house 用户默认），跳过其余 matter 逻辑，skills 使用 practice-level context，matter machinery 不可见。
10. 如果 matter 已启用且没有 active matter，询问：“Which matter is this for? Run `/regulatory-legal:matter-workspace switch <slug>` or say `practice-level`.”
11. 加载 active matter 的 `matter.md` 获取 matter-specific context 和 overrides。
12. 将输出写到 matter 文件夹 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/matters/<matter-slug>/`。
13. 除非 `Cross-matter context` 为 `on`，绝不读取另一个 matter 的文件。
14. 硬性护栏 1：这是 PROPOSAL，不是 edit。绝不直接写入源政策文档；输出到新文件 `[policy-name]-proposed-redraft-[YYYY-MM-DD].md` 或 matter workspace，而不是 `[policy-name].md`。
15. 硬性护栏 2：绝不在 tracker 中关闭 gap。gap 在 redraft 被 APPLIED AND APPROVED 后关闭——这是 policy owner 的行动。如果用户说“close the gap now that you've redrafted it”，拒绝并回复：“I produce the proposal. The gap closes when you've reviewed, applied, and approved the change. When that's done, tell me and I'll update the tracker.”
16. 硬性护栏 3：“Apply this for me” 不在范围内。如果用户要求把 redraft 应用到源政策，回复：“I don't apply policy changes — that's the policy owner's action after review and approval. I produce the proposal. When it's been reviewed and approved, tell me and I'll update the gap tracker.”
17. 硬性护栏 4：在 redraft 前确认政策版本。如果用户给文件，询问：“Is this the approved version of the policy, and is it the latest? A redraft against an outdated policy creates divergence.” 如果用户粘贴文本，信任但在 reviewer note 中标记。
18. 硬性护栏 5：Smallest-possible edit。先尝试改词而非句子，再改句子而非段落，再改段落而非章节；只触碰受 gap 影响的章节；不要重排/重设整个政策的样式。
19. 硬性护栏 6：贯穿保留 `[verify]` 标签。任何来自 model knowledge 或未验证来源的 effective date、threshold、citation 或 requirement 都要在 redraft 本身中标记，而不仅是在 memo 中。
20. Step 1：三类输入是必需的；缺任何一类都要询问，不要推断。
21. Step 1a：gap 可以是来自 gap tracker 的 `GAP-ID`，从 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml`（或 matter-level equivalent）加载条目。
22. Step 1a：gap 也可以由用户在消息中描述；捕获 requirement、regulation、affected policy。
23. Step 1a：gap 也可以是粘贴自 `/regulatory-legal:policy-diff` 输出的 diff summary。
24. Step 1b：current policy text 可以是文件路径；读取它，然后询问：“Is this the approved version of the policy, and is it the latest? A redraft against an outdated policy creates divergence.” 在 reviewer note 中记录答案。
25. Step 1b：current policy text 可以是粘贴文本；信任但在 reviewer note 中标记：“Policy text was pasted directly; I assumed it was the current approved version. Confirm before applying.”
26. Step 1b：如果既无文件路径也无粘贴文本，向用户要一个；不要从 gap tracker 或 web search 猜测政策文本。
27. Step 1c：rule text 可以是 diff output（已提取并标记规则）。
28. Step 1c：rule text 可以是 fetched regulation；用 provenance tag 记录来源。
29. Step 1c：rule text 可以是用户粘贴的规则文本；标记 `[user provided]`。
30. Step 1c：如果 rule text 不完整或含糊，应用 CLAUDE.md 的 no silent supplement 规则：给用户选项（paste full text、point at primary source、web-search-with-verify-tag、stop），并等待。
31. Step 2：使用与 policy-diff 相同的 rule-status check pattern。
32. Step 2 红旗：applicability/compliance date 已过去超过 30 天且没有确认其未被延迟。
33. Step 2 红旗：规则超过 12 个月。
34. Step 2 红旗：规则是政治上争议大的 final rule（major rulemakings 经常被挑战）。
35. Step 2：看到红旗时，通过 research MCP、web search（若启用）或 Federal Register docket 检查 delays、stays、injunctions、rescission proposals、vacatur 或 amendments。
36. Step 2：如果能验证规则有效，继续。
37. Step 2：如果无法验证，在工作产物 header 上方发出：`⚠️ 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 apply this redraft until you confirm the rule's status at the Federal Register docket or with outside counsel.`
38. Step 2：在 redraft 中把每个 effective/compliance date 标记为 `[effective date per published rule — status unverified]`。
39. Step 3：产出受影响政策章节的 marked-up version。
40. Step 3：redline granularity — smallest possible edit：先 strike a word before a sentence。
41. Step 3：先 strike a sentence before a paragraph。
42. Step 3：先 strike a paragraph before a section。
43. Step 3：只触碰受 gap 影响的章节；不要 restyle 整个 policy。
44. Step 3 convention：删除文本用 `~~struck text~~`。
45. Step 3 convention：插入文本用 **inserted text**。
46. Step 3 convention：每处修改都带 inline comment 解释 WHY——规则、cite、正在关闭的 gap，例如 `[Change: added biometric identifiers to the PII definition per COPPA 2025 amendments, 16 CFR 312.2 (effective Apr 22 2026) [verify]]`。
47. Step 3：任何来自 model knowledge 或未验证来源的 effective date、threshold、citation 或 requirement 都在 inline 处加 `[verify]` 标签，而不只是在 change summary 中。
48. Step 3：从 diff 贯穿保留 source tags：`[Federal Register]`、`[web search — verify]`、`[model knowledge — verify]`、`[user provided]`；从 diff 移到 redraft 时不要剥离。
49. Step 3 scope discipline：如果某章节不受 gap 影响，保持不动。
50. Step 3 scope discipline：如果 redraft 时看到第二个 gap（某 provision 明显与规则不一致但不在原 gap 中），不要静默修复；在 reviewer note 中标记：“While redrafting for [GAP-ID], I noticed [other provision] appears to have a related issue with [requirement]. Not included in this redraft. Consider a follow-on gap.”
51. Step 4：输出 Policy Redraft Memo，包含 work-product header（按 plugin config `## Outputs`，因角色而异；见 `## Who's using this`）。
52. Step 4：reviewer note 包含 Sources：`[Research connector: CourtListener ✓ verified | not connected — cites from training knowledge, verify before relying]`。
53. Step 4：reviewer note 包含 Read：`[sections of the policy reviewed; what wasn't read]`。
54. Step 4：reviewer note 包含 Flagged for your judgment：`[N items marked [review] inline | none]`。
55. Step 4：reviewer note 包含 Currency：`[rule status verified against [source], [date] | unverified — see banner above]`。
56. Step 4：reviewer note 包含 Before relying：确认这是当前已批准版本；验证 rule status 和 effective date；取得 policy owner review；遵循 policy-change approval process；只在 applied and approved 后更新 gap tracker。
57. Step 4：Policy Redraft 部分写 `Policy Redraft: [Policy name]`，列出 Gap、Regulation、Policy、Status: PROPOSAL — not yet reviewed or approved。
58. Step 4：Bottom line 写三句：一句 gap 是什么，一句 redraft 做了什么，一句需要 review 什么。
59. Step 4：写 Marked-up policy section(s)，带 inline `[Change: ...]` comments；只包含受影响章节。
60. Step 4：写 Change summary 表格，列为 #、Provision、Current、Proposed、Why、Verify。
61. Step 4：写 Before applying — checklist：确认这是当前已批准政策版本；验证 rule status 和 effective date（Federal Register docket 或 outside counsel）；取得 policy owner's review；遵循 policy-change approval process；只在 applied and approved 后更新 gap tracker，不能提前。
62. Step 4：写 What next 决策树选项 1：Apply and get sign-off——用户 review、circulate 给 policy owner、走 approval process；批准后告诉并 mark gap closed。
63. Step 4：写 What next 决策树选项 2：Get more info on [X]——如果某个 change 需要更多 grounding（验证 cite、检查 threshold、解决 jurisdiction question），告诉哪一个并深入。
64. Step 4：写 What next 决策树选项 3：Escalate to [owner / GC]——如果 redraft 提出超出 policy-owner 权限的事项，起草短 escalation，包含 facts、proposed change、decision needed。
65. Step 4：写 What next 决策树选项 4：Watch and wait——如果 rule status 不确定或 policy owner 不可用，在 gap tracker 加 revisit note。
66. Step 4：写 What next 决策树选项 5：Something else——让用户说会怎么处理。
67. Step 4：根据 redraft 实际产出定制 next-steps options；如果 rule status unverified，option 2 提前；如果 policy owner 未设置，option 3 要具体。
68. 文件名使用 `[policy-name]-proposed-redraft-[YYYY-MM-DD].md`。
69. 不要用 `[policy-name].md`。
70. 不要用 `[policy-name]-v2.md`。
71. “proposed-redraft” 和日期是 load-bearing，防止草稿被误认为当前版本。
72. 如果有 active matter workspace，写入 matter workspace；否则写入 current working directory 或用户指定位置。
73. 不要写入 policy library source directory。
74. 从 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` 读取 policy library index 和 owners。
75. 当所需值为空或仍为 `[PLACEHOLDER]`：policy owner missing 时，仍然产出 redraft；在 reviewer note 中写：“No policy owner is set for [policy] in `## Policy library`. Assign one with `/regulatory-legal:cold-start-interview --redo` so the approval path is routable.”
76. 当 policy library empty 且 gap 未指定具体 policy 时，停止并询问：“I need the current policy text to redraft. Paste the text of the affected policy, or point me at the file.”
77. 当配置值已填充时，不要提及 config。
78. Upstream inputs 来自 `policy-diff`（per-requirement gap analysis）和 `gap-surfacer`（tracker）；贯穿携带其 source tags 和 `[verify]` flags。
79. Gap tracker state：本技能不改变 tracker；不标记 gap closed，不标记 in-progress，不触碰 `notified`。
80. 如果要有 redraft 存在的 paper trail，policy owner 或用户可以在 redraft applied and approved 后更新 gap entry 的 resolution note——见 `/regulatory-legal:gaps --close`。
81. Severity floor：如果 upstream gap 是 🔴 或 🟠，memo 的 Bottom line 必须携带该 severity；静默降级是 review lawyer 看不到的矛盾。见 CLAUDE.md `## Cross-skill severity floor`。
82. 本技能不 apply redraft 到 source policy；那是 policy owner 的行动。
83. 本技能不 close gap in tracker；gap 在 redraft applied and approved 后关闭。
84. 本技能不 rewrite 整个 policy；只做 smallest-possible edit。
85. 本技能不 produce multi-policy redrafts；一次一个 gap、一个 policy、一个 memo；多政策 fan-out 的 `:package` command 是未来技能。
86. 本技能不 produce “apply” workflow；带 approval gate 的 `:apply` command 是未来技能。

适用边界 · 注意事项

• 不适用于直接修改、应用或覆盖源政策文档；只产出提案，应用需 policy owner 审批。
• 不适用于在 tracker 中关闭缺口；缺口只在 redraft 被应用且批准后由 policy owner 关闭。
• 不适用于多政策批量修订或整套政策重写；一缺口、一政策、一备忘。