法务合规
法规变更影响政策库时,做逐需求差距分析并定位需更新的政策
当某法规发生变化,需要判断它触及哪些内部政策、差距在哪、哪些政策要更新时使用。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
法规变更影响政策库时,做逐需求差距分析并特定
解决思路
- 加载 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`,读取政策库索引。
- 按下方工作流执行。
- 从法规变更中提取要求,并匹配到已建索引的政策。
- 输出逐需求差距分析,以及哪些政策需要更新。
- 检查实践级 CLAUDE.md 中的 `## Matter workspaces`。若 `Enabled` 为 `✗`(内部用户默认值),跳过本段其余内容;技能使用实践级上下文,matter 机制不可见。
- 若 matter 机制已启用且没有活动 matter,询问:“Which matter is this for? Run `/regulatory-legal:matter-workspace switch <slug>` or say `practice-level`.”
- 加载活动 matter 的 `matter.md`,获取 matter 特定上下文和覆盖项。
- 将输出写入 matter 文件夹:`~/.claude/plugins/config/claude-for-legal/regulatory-legal/matters/<matter-slug>/`。
- 除非 `Cross-matter context` 为 `on`,绝不读取另一个 matter 的文件。
- 明确用途:法规变了,已有政策;找出变更触及哪些政策,以及“法规现在要求什么”与“政策写了什么”之间的差距。
- 加载 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` 中的政策库索引(政策、位置、负责人)。
- 范围完整性:若用户要求把某政策章节、需求或类别排除出 diff,1) 照做——范围由用户决定。
- 2) 但仍要显眼且永久地标记:“⚠️ 范围限制:应用户要求排除 [X] 节。本 diff 不反映完整政策。被排除区域的差距未被识别。”放在标题上方,并带到每个下游产物。
- 3) 将标记交给 `gap-surfacer`:“本次 diff 已限制范围。不要将其表述为完整的合规图景。”在由此 diff 派生的任何 gap tracker 条目上逐字包含该范围限制横幅。
- 4) 说明排除的含义:“排除 vendor management 意味着 diff 会显示‘没有政策处理 vendor management’——这比展示差距更糟。”
- 记住:建立在未披露范围排除上的合规产物在证据开示中看起来像隐瞒;标记是“我们限定了审查范围”和“我们隐藏了问题”之间的区别。
- Step 0:在 diff 前先核验规则状态,确认规则实际生效。
- 识别红旗:适用/合规日期已过去超过 30 天但无确认其未被延迟;规则超过 12 个月;规则是有政治争议的 final rule(重大规则常被挑战)。
- 出现红旗时,通过 research MCP、web search(若启用)或 Federal Register docket 检查:延迟、暂停、禁令、撤销提案、vacatur 或修订。
- 如果可以检查且确认规则生效,继续。
- 如果无法核验(未连接工具),在任何内容之前、标题上方输出横幅:“⚠️ 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.”
- 给输出中的每个截止日期打标签:`[due date per published rule — status unverified]`。
- 规则状态不确定性要传递到下游。将 gap 交给 `gap-surfacer` 时,把条目标记为 `status_verified: false`,使其不会仅凭已公布日期被路由到 Overdue 桶。
- Step 1:提取新要求。
- 不做静默补充:如果法规变更文本不完整或含糊,且无法从已索引来源取得更完整规则,停下来询问。
- 未经询问,不要用 web search 或模型知识填补空白。
- 按此措辞询问:“I have [what you have]. To extract requirements accurately I'd need [what's missing]. Options: (1) paste the full text, (2) point me at the primary source, (3) search the web for the rule — results will be tagged `[web search — verify]` and should be checked against the issuing authority before relying, or (4) stop here. Which would you like?”
- 是否接受低置信来源由律师决定;Claude 不替其决定。
- 来源归属:给每个引用打标签——法规引用、交叉引用、政策摘录——标明来源:`[<regulator or research tool>]` 用于从一手来源、政策库或 MCP 获取的项目;`[web search — verify]` 用于网页搜索;`[model knowledge — verify]` 用于模型训练知识回忆;`[user provided]` 用于用户粘贴。
- 标记为 `verify` 的项目具有更高捏造风险,应优先核验。
- 在输出中绝不剥离或合并这些标签。
- 阅读法规变更,列出每个独立的新增或变更要求,表格列为:#、Requirement、Effective、Citation。
- 要求要具体:“Enhanced disclosure requirements”不是要求;“Must disclose X in Y format at Z point in the flow”才是。
- Step 2:将每个要求映射到政策,找出已索引政策中最接近的是哪个。
- 直接命中:政策明确覆盖该主题。
- 间接:政策覆盖相关主题,但这是新的子问题。
- 无匹配:没有政策处理该要求——差距为“政策不存在”。
- Step 3:对每个直接或间接命中,阅读政策并比较,使用以下 markdown 模板:`### Requirement [N]: [name]`;`**New rule requires:** [requirement]`;`**Our policy ([name], last updated [date]) says:**`;`> “[relevant excerpt]”`;`**Gap:** [None — policy already covers this | Partial — policy addresses X but not Y | Full — policy contradicts or doesn't address]`;`**Change needed:** [specific — “add a paragraph on X” not “update the policy”]`;`**Policy owner:** [from index]`。
- 差距要具体:写“增加关于 X 的一段”,不要写“更新政策”。
- Step 4:无匹配差距单独列出,使用模板:`### New policy needed`;`Requirement [N]: [requirement]`;`No existing policy covers this. Options:`;`- Draft new policy (suggested owner: [whoever owns the closest topic])`;`- Add to existing [related policy] as a new section`;`- Determine this doesn't need a policy (one-off compliance, not ongoing)`。
- 按监管输入类型分支。
- 预规则分支(ANPR / RFI):如果监管输入是 ANPR 或 RFI(没有施加要求),不要运行完整的差距关闭 diff。
- 改为产出 pre-positioning analysis:列出一旦 final rule 发布后可能需要变更的政策(不是今天)。
- 标记 ANPR 的任何议题领域是否与公司实践相交,以至于值得提交 comment letter。
- 记录 comment deadline 和来自 `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` 的团队 comment-decision owner。
- 不要为 ANPR 产出逐需求 “no gap” 行——没有要求可 diff。产出一段话,说明未来暴露及会触及的政策。
- 负面发现分支(final rule / NPRM diff 到的政策不是正确目标):如果提取列表中的每个需求都得出 “no gap against [the named policy]”,不要产出完整逐需求分析。
- 压缩为一段简短文字:`## Policy Diff: [Regulation name] — [Policy name]`;`[REGULATION] doesn't appear to require a change to [POLICY NAME]. [POLICY NAME] §[X] already covers [Y]. The policies this regulation actually touches are [other-policy-1] and [other-policy-2] — rerun `/regulatory-legal:policy-diff` against those.`;`Review on [next cycle — e.g., “at the next annual policy review”] or if [trigger — e.g., “the rule is finalized or amended”].`
- 一段话、一个建议、一个路由说明。不要为每个需求重复 “no gap” 发现——汇总表已处理。
- 针对错误目标政策的负面发现是路由问题,不是合规分析。
- 差距分支(final rule / NPRM 且对目标政策至少有一个差距):按下方规定进行完整逐需求分析。详细 diff 格式用于确实发现差距的 diff。
- 输出模板:`[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see ## Who's using this]`;`## Policy Diff: [Regulation name]`;`**Regulation:** [name, link]`;`**Effective:** [date]`;`**Requirements extracted:** [N]`;`### Bottom line`;`[N gaps need action by [date] — top 3: X, Y, Z]`;`### Summary`;`| # | Requirement | Policy affected | Gap | Owner |`;`| 1 | [short] | [policy name or “none”] | None/Partial/Full | [name] |`;`### Detailed diffs`;`[Each requirement block from Step 3]`;`### New policies needed`;`[From Step 4, if any]`;`### No-gap requirements`;`[List — useful to know what's already covered]`;`---`。
- 在输出底部加入核验引用免责声明:**在依赖引用前先核验它们。** 上述法规引用和政策引用由 AI 生成,尚未对照一手来源检查。在依据本处任何要求采取行动前,请对照 Westlaw、你所在机构的研究平台或发布机关网站确认规则——检查准确性、生效日期和当前状态。AI 生成的法规引用有时会被捏造、误引或过期。每个要求上的来源标签(例如 `[Federal Register]`、`[web search — verify]`)显示引用来源;带 `verify` 标签的引用捏造风险更高,应优先核验。
- 配置依赖回退:政策库为空时,默认把每个要求标记为 “no policy match”,并在输出后追加:“The policy library in your configuration is empty, so every requirement is flagged as a new-policy gap. If you have policies that address these requirements, add them to the library with `/regulatory-legal:cold-start-interview --redo` or by editing `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`, then re-run the diff.”
- 配置依赖回退:匹配政策的 owner 缺失时,在汇总表中将 Owner 单元格留空,并追加:“Policy owners aren't set for [list]. Assign them with `/regulatory-legal:cold-start-interview --redo` or by editing the policy library in `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` so gap-surfacer can route.”
- 当政策库已填充且 owner 已设置时,不要对配置说任何话。
- Handoff 到 `gap-surfacer`:每个 Partial 或 Full 差距成为带 owner 和 deadline 的跟踪条目。
- 以 next-steps decision tree 收尾:按 CLAUDE.md `## Outputs` 结束,并用本技能刚产出的内容定制选项——五个默认分支(draft the X、escalate、get more facts、watch and wait、something else)只是起点,不是锁定。决策树就是输出;由律师选择。
- 本技能不做:起草政策更新。它识别需要更新的内容;政策起草(或人工)来起草。
- 本技能不做:对含糊监管文本作确定性解释。如果法规可有两种读法,说明这一点并标记给律师。
适用边界 · 注意事项
- 当没有可用的政策库索引或未配置 `claude-for-legal` regulatory-legal 插件/配置时,不要假装能完成真实映射;只能输出配置回退提示。
- 当监管输入是 ANPR 或 RFI 预规则且没有强制要求时,不要运行完整差距关闭 diff,应改用 pre-positioning analysis。
- 当目标政策明显不是该法规实际触及的政策,且所有需求均 no gap 时,不要输出完整逐需求分析,应改为一段路由说明。