policy-redraft

/policy-redraft

1. 加载 ~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md → 政策库索引 + 实务配置文件。
2. 使用以下工作流。
3. 收集输入：差距（来自 /regulatory-legal:gaps 的输出，或直接描述）、当前已批准的政策文本、规则文本。
4. 根据 policy-diff 的规则状态检查，确认规则仍然有效。如果无法确认，请输出 ⚠️ RULE STATUS UNVERIFIED 横幅。
5. 对受影响的政策部分进行修订并标注——尽可能少地修改，保留 [verify] 标签，并添加行内注释，说明每项修改的原因。
6. 输出一份 Policy Redraft Memo。将其写入名为 [policy-name]-proposed-redraft-[YYYY-MM-DD].md 的新文件——绝不要写入源政策文档。
7. 不要在跟踪器中关闭差距。只有在修订内容已应用并获批后，差距才会关闭；这是政策所有者的职责。

---

此技能生成的是一份提案，而非修改稿。它会将内容写入一个明确标注为草稿的新文件，绝不会覆盖源政策文档，也绝不会在跟踪器中关闭差距——只有在政策所有者应用并批准修订内容后，差距才会关闭。

事项背景

事项背景。 检查实务级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（这是内部用户的默认设置），请跳过本段其余内容——技能会使用实务级背景，事项机制不可见。如果已启用且没有活动事项，请询问：“这是哪个事项？运行 /regulatory-legal:matter-workspace switch <slug> 或输入 practice-level。”加载活动事项的 matter.md，以获取事项专属背景和覆盖项。将输出写入 ~/.claude/plugins/config/claude-for-legal/regulatory-legal/matters/<matter-slug>/ 下的事项文件夹。除非 Cross-matter context 为 on，否则绝不要读取其他事项的文件。

---

目的

Gap-surfacer 找出差距。Policy-diff 指明需要更改的内容。此技能负责下一步：对受影响的政策部分进行修订并标注，做到改动小、内容具体、标记清晰，作为供政策所有者审阅的初稿。

严格防护规则——请先阅读

这些是不可妥协的规则。如有任何规则可能被违反，请停止并询问。

1. 这是提案，不是修改。 绝不要直接写入源政策文档。输出应写入名为 [policy-name]-proposed-redraft-[YYYY-MM-DD].md 的新文件，或写入事项工作区。不要写入 [policy-name].md。
2. 绝不要在跟踪器中关闭差距。 只有修订内容已应用并获批后，差距才会关闭——这是政策所有者的职责，不是你的。如果用户说“既然你已经修订了，就现在关闭差距”，请婉拒：“我负责生成提案。只有在你审阅、应用并批准更改后，差距才会关闭。完成后告诉我，我会更新跟踪器。”
3. 不在职责范围内代为应用。 如果用户要求将修订内容应用到源政策中，请回复：“我不会应用政策更改——审阅并批准后，这是政策所有者的职责。我负责生成提案。审阅并批准后告诉我，我会更新差距跟踪器。”
4. 修订前确认政策版本。 如果用户提供了文件，请询问：“这是已批准且最新版本的政策吗？依据过时的政策进行修订会造成内容偏差。”如果用户粘贴的是文本，则予以采信，但要在审阅者备注中注明。
5. 尽可能少地修改。 优先删除单词，而不是句子；优先修改句子，而不是段落；优先修改段落，而不是章节。只修改受差距影响的部分。不要重新调整政策的整体风格。
6. 保留 [verify] 标签。 任何来自模型知识或未经核实来源的生效日期、阈值、引用或要求，都必须在修订稿中标注 [verify]，不能只在备忘录中标注。

第 1 步：收集输入

需要提供三项输入。如果缺少任何一项，请询问，不要自行推断。

1a. 差距

以下之一：

• 来自差距跟踪器的 GAP-ID —— 从 ~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml（或事项级对应文件）中加载该条目。
• 用户消息中描述的差距 —— 记录要求、法规和受影响的政策。
• 从 /regulatory-legal:policy-diff 输出中粘贴的差异摘要。

1b. 当前政策文本

以下之一：

• 文件路径 —— 读取文件，然后询问：“这是已批准的政策版本吗？也是最新版本吗？基于过时政策重新起草会造成偏差。”在审阅者备注中记录回答。
• 粘贴的文本 —— 予以采信，但在审阅者备注中标注：“政策文本由用户直接粘贴；我假定这是当前已批准的版本。应用前请确认。”
• 两者都没有 —— 请用户提供。不要根据差距跟踪器或网络搜索猜测政策文本。

1c. 规则文本

以下之一：

• 差异输出（已提取规则并添加标签）。
• 已获取的法规 —— 添加来源出处标签，注明来源。
• 用户粘贴的规则文本 —— 添加标签 [user provided]。

如果规则文本不完整或含糊，请遵循 CLAUDE.md 中的不得静默补充规则：向用户提供以下选项（粘贴完整文本、提供主要来源、使用网络搜索并标注待验证，或停止），然后等待回复。

步骤 2：核实规则是否仍然有效

使用与 policy-diff 相同的规则状态检查模式。以下情况是规则可能尚未生效的警示信号：

• 适用日期／合规日期已过 30 天以上，且未确认延期。
• 规则发布已超过 12 个月。
• 规则是存在政治争议的最终规则（重大规则制定常遭到质疑）。

发现警示信号时，请通过 research MCP、（如果已启用的）网络搜索或《联邦公报》案卷核查是否存在延期、暂缓执行、禁令、撤销提案、废止或修订。如果能核实规则仍然有效，则继续。如果无法核实：

⚠️ 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.

在工作成果标题上方输出该横幅。将重拟文本中的每个生效日期／合规日期标记为 [effective date per published rule — status unverified]。

步骤 3：生成重拟文本

对受影响政策章节进行带修订标记的修改。

修订粒度——尽可能小的修改

• 删除词语前，先考虑删除整句。
• 删除句子前，先考虑删除整段。
• 删除段落前，先考虑删除整节。
• 只修改受差距影响的章节。不要对整份政策重新排版。

约定

• 删除文本：~~struck text~~

• 插入文本：inserted text

• 每处修改都附带行内注释，说明原因——适用规则、引用依据及要弥补的差距：

  [Change: added biometric identifiers to the PII definition per COPPA 2025 amendments, 16 CFR 312.2 (effective Apr 22 2026) [verify]]

• 任何来自模型知识或未经核实来源的生效日期、门槛、引用或要求，都要在行内添加 [verify] 标签——不能只在修改摘要中标注。

• 保留从差异内容继承的来源标签：[Federal Register]、[web search — verify]、[model knowledge — verify]、[user provided]。从差异内容移至重拟文本时，不要删除这些标签。

范围控制

如果某个政策条款不受该差距影响，就不要改动。重拟草案时修改差距以外的条款，会让人觉得 AI 对未被要求评议的事项发表了意见，也会增加审核难度。

如果重拟草案时发现第二处差距——某项条款明显不符合该规则，但不属于原始差距——不要悄悄修正。在审核者备注中标明：“为处理 [GAP-ID] 重拟草案时，我注意到 [other provision] 似乎与 [requirement] 存在相关问题。本次草案未纳入此项。请考虑另行提出一项差距。”

步骤 4：输出 — 政策重拟备忘录

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> **⚠️ Reviewer note**
> - **Sources:** [Research connector: CourtListener ✓ verified | not connected — cites from training knowledge, verify before relying]
> - **Read:** [sections of the policy reviewed; what wasn't read]
> - **Flagged for your judgment:** [N items marked `[review]` inline | none]
> - **Currency:** [rule status verified against [source], [date] | unverified — see banner above]
> - **Before relying:** confirm this is the current approved version of the policy; verify rule status and effective date; get the policy owner's review; follow your policy-change approval process; update the gap tracker only when applied and approved.

## Policy Redraft: [Policy name]

**Gap:** [GAP-ID or short description]
**Regulation:** [name, citation, effective date]
**Policy:** [name, last-updated date]
**Status:** PROPOSAL — not yet reviewed or approved

### Bottom line

[One sentence: what the gap is. One sentence: what the redraft does. One sentence: what needs review.]

### Marked-up policy section(s)

[The redlined text, with inline `[Change: ...]` comments. Only the affected sections.]

### Change summary

| # | Provision | Current | Proposed | Why | Verify |
|---|---|---|---|---|---|
| 1 | §2.1 PII definition | "…names, addresses, SSNs…" | "…names, addresses, SSNs, biometric identifiers…" | COPPA 2025 amendments expand PII to cover biometrics | [Federal Register] |
| 2 | §4.3 Retention period | "30 days" | "14 days" | New rule imposes 14-day cap | `[verify — model knowledge]` |

### Before applying — checklist

- [ ] Confirm this is the current approved version of the policy being redrafted.
- [ ] Verify the rule status and effective date (Federal Register docket, or outside counsel).
- [ ] Get the policy owner's review.
- [ ] Follow your policy-change approval process.
- [ ] Update the gap tracker when applied and approved — not before.

---

**What next? Pick one and I'll help you build it out:**

1. **Apply and get sign-off** — you review, circulate to the policy owner, walk it through your approval process. When approved, tell me and I'll mark the gap closed.
2. **Get more info on [X]** — if a specific change needs more grounding (a cite verified, a threshold checked, a jurisdiction question resolved), tell me which one and I'll dig in.
3. **Escalate to [owner / GC]** — if the redraft raises something above the policy-owner's authority, I'll draft a short escalation with the facts, the proposed change, and what decision is needed.
4. **Watch and wait** — if the rule's status is uncertain or the policy owner is unavailable, I'll add a revisit note to the gap tracker.
5. **Something else** — tell me what you'd do with it.

文件名

输出文件名应明确表明这是一份草案。请使用：

[policy-name]-proposed-redraft-[YYYY-MM-DD].md

不要使用 [policy-name].md，也不要使用 [policy-name]-v2.md。“proposed-redraft”和日期至关重要，可避免草案被误认为是当前版本。

如果当前有事项工作区，请写入该工作区；否则写入当前工作目录或用户指定的位置。不要写入政策库源目录。

依赖配置的备用处理方式

此技能会从 ~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md 读取政策库索引和负责人信息。当所需值为空或仍为 [PLACEHOLDER] 时：

• **缺少政策负责人：**仍须生成重拟草案。在审核者备注中注明：“## Policy library 中未设置 [policy] 的政策负责人。请使用 /regulatory-legal:cold-start-interview --redo 指定负责人，以便审批流程能够正常进行。”
• **政策库为空且差距未指出具体政策：**停止并询问：“我需要当前政策文本才能重拟草案。请粘贴受影响政策的文本，或告诉我文件所在位置。”

如果配置项均已填写，则不要提及配置。

与其他技能的交互

• 上游输入来自 policy-diff（按要求进行的差距分析）和 gap-surfacer（跟踪器）。保留其来源标签和 [verify] 标记。
• **差距跟踪器状态：**此技能不会更改跟踪器。不会将差距标记为已关闭或处理中，也不会改动 notified。如果希望留存草案记录，政策负责人或用户可在应用并批准草案后，为差距条目添加解决说明 — 参见 /regulatory-legal:gaps --close。
• **严重程度下限：**如果上游差距为 🔴 或 🟠，备忘录的结论必须保留相应严重程度。悄然降低严重程度会造成矛盾，审核律师无法察觉。参见 CLAUDE.md ## Cross-skill severity floor。

结尾使用后续步骤决策树

上述输出模板中已包含该决策树。请根据实际重拟草案结果调整选项 — 如果规则状态尚未核实，应将选项 2（获取更多信息）提前；如果尚未指定政策负责人，应明确选项 3（升级处理）的对象。

此技能不执行的操作

• 将重拟草案应用到政策源文件。这是政策负责人的工作。
• 在跟踪器中关闭差距。只有应用并批准重拟草案后，差距才会关闭。
• 重写整份政策。仅进行关闭差距所需的最小改动。
• 为多项政策生成重拟草案。一个差距、一项政策、一份备忘录。用于处理多项政策的 :package 命令是未来计划中的技能。
• 执行“应用”工作流。带审批关卡的 :apply 命令是未来计划中的技能。