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-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] タグを引き継ぎます。 モデルの知識または未確認の情報源に基づく発効日、しきい値、引用、要件には、メモだけでなく改訂案自体にもタグを付けます。

ステップ 1：入力情報を収集する

入力情報は3つ必要です。いずれかが不足している場合は、推測せずに尋ねてください。

1a. ギャップ

次のいずれかを指定します。

• ギャップトラッカーの GAP-ID — ~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml（または案件レベルの同等ファイル）から該当項目を読み込みます。
• ユーザーのメッセージに記載されたギャップ — 要件、規制、影響を受けるポリシーを記録します。
• /regulatory-legal:policy-diff の出力から貼り付けた差分の要約。

1b. 現在のポリシー本文

次のいずれかを指定します。

• ファイルパス — ファイルを読み込んでから、次のように尋ねます。「これは承認済みのポリシーのバージョンで、最新版ですか？ 古いポリシーを基に改訂すると、内容にずれが生じます。」回答をレビュアーノートに記録します。
• 貼り付けた本文 — その内容を信頼しますが、レビュアーノートに次の注意書きを記載します。「ポリシー本文が直接貼り付けられたため、現在の承認済みバージョンであると仮定しました。適用前に確認してください。」
• どちらもない — 提示を求めます。ギャップトラッカーやウェブ検索からポリシー本文を推測してはいけません。

1c. 規則の本文

次のいずれかを指定します。

• 差分の出力（規則がすでに抽出され、タグ付けされています）。
• 取得した規制 — 出典を出所タグとともに記録します。
• ユーザーが貼り付けた規則の本文 — [user provided] を付けます。

規則の本文が一部のみ、または曖昧な場合は、CLAUDE.md の黙って補足しないルールに従います。次の選択肢をユーザーに提示し、返答を待ちます（全文の貼り付け、一次資料の提示、検証タグ付きのウェブ検索、または中止）。

Step 2: 規則が現行か確認する

policy-diff と同じ規則ステータス確認パターンを使用します。規則が施行されていない可能性を示す危険信号は次のとおりです。

• 適用日／遵守期限を30日以上過ぎており、延期されていないことを確認できていない。
• 規則の公表から12か月以上経過している。
• 政治的に議論の的となっている最終規則（主要な規則制定は頻繁に異議申し立てを受けます）。

危険信号が見られた場合は、調査用 MCP、利用可能な場合はウェブ検索、または Federal Register のドケットを通じて、延期、執行停止、差し止め、撤回提案、無効化、または改正を確認します。規則が施行中であると確認できた場合は、先に進みます。確認できない場合は、次のバナーを出力します。

⚠️ RULE STATUS UNVERIFIED — この規則が現在施行中であることを確認できませんでした。最終規則は公表後に執行停止、差し止め、延期、または撤回されることがよくあります。Federal Register のドケットまたは外部弁護士に確認するまで、この改訂案を適用しないでください。

このバナーを成果物のヘッダーの上に表示します。改訂案に含まれるすべての発効日／遵守期限に [effective date per published rule — status unverified] を付けます。

Step 3: 改訂案を作成する

影響を受けるポリシーセクションの変更履歴付きバージョンを作成します。

変更履歴の粒度 — 可能な限り最小限の編集

• 文より先に単語を削除します。
• 段落より先に文を削除します。
• セクションより先に段落を削除します。
• ギャップの影響を受けるセクションのみを編集します。ポリシー全体のスタイルを変更してはいけません。

表記規則

• 削除するテキスト：~~削除するテキスト~~

• 挿入するテキスト：挿入するテキスト

• 変更箇所ごとに、理由（規則、引用、解消するギャップ）を説明するインラインコメントを付けます。

  [Change: COPPA 2025 amendments, 16 CFR 312.2（2026年4月22日発効）に基づき、PII の定義に生体識別子を追加 [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（エスカレーション）の内容を具体化します。

このスキルで行わないこと

• ソースポリシーに再草案を適用すること。これはポリシー担当者の作業です。
• トラッカーでギャップをクローズすること。ギャップがクローズされるのは、再草案が適用され承認されたときです。
• ポリシー全体を書き直すこと。ギャップを解消するために必要な、最小限の変更にとどめます。
• 複数ポリシーの再草案を作成すること。1 つのギャップ、1 つのポリシー、1 つのメモです。複数ポリシーに展開する :package コマンドは、今後のスキルとして予定されています。
• 「適用」ワークフローを作成すること。承認ゲートを備えた :apply コマンドは、今後のスキルとして予定されています。