Правка политики под новую норму

Готовит черновик правок к внутренней политике, закрывающий найденный пробел: минимальные изменения с пометками и объяснением.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Готовит черновик правок к внутренней политике, закрывающий найденный пробел: минимальные изменения с пометками и объяснением.
Когда брать: Когда найден пробел между новой нормой и политикой компании и нужен первый черновик правок для владельца политики.
Когда не брать: Если нужно внести правку в сам документ или закрыть пробел в трекере: скилл только предлагает, а вносит и утверждает владелец политики.
Пример запроса: Подготовь правку политики по пробелу GAP-001.
Нужно подключить: текст действующей утверждённой политики, текст нормы или результат сравнения политик
Работает лучше с: трекер пробелов, инструмент правовых исследований

Входит в плагин regulatory-legal. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Скачайте архив и распакуйте его.
Положите папку policy-redraft в ~/.claude/skills/.
Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: policy-redraft
description: Подготовь предлагаемую новую редакцию политики с пометками правок, которая закрывает пробел, найденный командой /regulatory-legal:gaps или /regulatory-legal:policy-diff. Это первый черновик для внутренней проверки, а не для прямого внесения в утверждённые документы политик. Используй, когда пользователь говорит «перепиши политику», «подготовь правку политики», «размеч политику правками» или когда gap-surfacer передаёт пробел для подготовки правки.
argument-hint: "[GAP-ID или описание пробела]"
---

/policy-redraft

Загрузи ~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md → индекс библиотеки политик + профиль практики.
Используй рабочий процесс ниже.
Собери входные данные: пробел (из вывода /regulatory-legal:gaps или описанный напрямую), текущий утверждённый текст политики, текст нормы.
Проверь, что норма актуальна (по проверке статуса нормы из policy-diff). Если проверить не можешь, выведи баннер ⚠️ СТАТУС НОРМЫ НЕ ПРОВЕРЕН.
Подготовь новую редакцию затронутых разделов политики с пометками правок: минимально возможная правка, метки [verify] перенесены, встроенные комментарии объясняют, ЗАЧЕМ внесено каждое изменение.
Выдай записку о новой редакции политики. Запиши её в новый файл с именем [policy-name]-proposed-redraft-[YYYY-MM-DD].md, никогда не записывай в исходный документ политики.
НЕ закрывай пробел в трекере. Пробел закрывается, когда новая редакция внесена И утверждена, а это действие владельца политики.

Этот скилл готовит предложение, а не правку. Он пишет в новый файл с явно помеченным именем черновика. Он никогда не перезаписывает исходный документ политики и никогда не закрывает пробел в трекере: пробел закрывается, когда владелец политики внёс новую редакцию И утвердил её.

Контекст дела

Контекст дела. Проверь раздел ## Matter workspaces в CLAUDE.md уровня практики. Если 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 называет, что нужно изменить. Этот скилл делает следующий шаг и готовит редакцию затронутого раздела политики с пометками правок: небольшую, конкретную, с отметками, как первый черновик для проверки владельцем политики.

Жёсткие ограничения — прочитай их первыми

Это правила, на которых всё держится. Если какое-то из них было бы нарушено, остановись и спроси.

Это ПРЕДЛОЖЕНИЕ, а не правка. Никогда не пиши напрямую в исходный документ политики. Результат идёт в новый файл [policy-name]-proposed-redraft-[YYYY-MM-DD].md или в рабочее пространство дела. Не в [policy-name].md.
Никогда не закрывай пробел в трекере. Пробелы закрываются, когда новая редакция ВНЕСЕНА И УТВЕРЖДЕНА, а это действие владельца политики, а не твоё. Если пользователь говорит «закрой пробел, раз ты это переписал», откажи: «Я готовлю предложение. Пробел закрывается, когда вы проверите, внесёте и утвердите изменение. Когда это будет сделано, скажите мне, и я обновлю трекер».
«Внеси это за меня» не входит в задачи. Если пользователь просит внести новую редакцию в исходную политику: «Я не вношу изменения в политики: это действие владельца политики после проверки и утверждения. Я готовлю предложение. Когда оно будет проверено и утверждено, скажите мне, и я обновлю трекер пробелов».
Подтверди версию политики до подготовки правки. Если пользователь даёт файл, спроси: «Это утверждённая версия политики и самая последняя? Правка на основе устаревшей политики создаёт расхождение». Если он вставляет текст, поверь, но отметь это в примечании для проверяющего.
Минимально возможная правка. Сначала вычёркивай слово, потом предложение, потом абзац, потом раздел. Трогай только разделы, затронутые пробелом. Не меняй стиль политики.
**Переноси метки [verify].** Любая дата вступления в силу, порог, ссылка или требование, взятые из знаний модели или непроверенного источника, получают метку в самой новой редакции, а не только в записке.

Шаг 1: Собери входные данные

Нужны три входных данных. Если чего-то нет, спроси, не выводи сам.

1а. Пробел

Что-то одно из:

GAP-ID из трекера пробелов: загрузи запись из ~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml (или аналога на уровне дела).
Пробел, описанный в сообщении пользователя: зафиксируй требование, норму и затронутую политику.
Сводка сравнения, вставленная из вывода /regulatory-legal:policy-diff.

1б. Текущий текст политики

Что-то одно из:

Путь к файлу: прочитай его, затем спроси: «Это утверждённая версия политики и самая последняя? Правка на основе устаревшей политики создаёт расхождение». Запиши ответ в примечание для проверяющего.
Вставленный текст: поверь, но отметь в примечании для проверяющего: «Текст политики был вставлен напрямую; я исходил из того, что это текущая утверждённая версия. Подтвердите, прежде чем вносить».
Ни того ни другого: попроси что-то одно. Не угадывай текст политики по трекеру пробелов или веб-поиску.

1в. Текст нормы

Что-то одно из:

Результат сравнения (в нём норма уже выделена и помечена).
Загруженная норма: укажи источник с меткой происхождения.
Текст нормы, вставленный пользователем: пометь [user provided].

Если текст нормы неполный или неоднозначный, примени правило без тихого дополнения из CLAUDE.md: предложи пользователю варианты (вставить полный текст, указать первоисточник, веб-поиск с меткой verify или остановиться) и жди.

Шаг 2: Проверь, что норма актуальна

Используй ту же схему проверки статуса нормы, что и policy-diff. Тревожные признаки того, что норма может не действовать:

Дата применения или соблюдения прошла больше 30 дней назад без подтверждения, что её не отложили.
Норме больше 12 месяцев.
Норма — политически спорное окончательное правило (крупные нормотворческие акты часто оспариваются).

Заметив тревожный признак, проверь (через MCP-исследования, веб-поиск, если он включён, или дело в Federal Register) наличие: отсрочек, приостановлений, судебных запретов, предложений об отмене, признания недействительным или поправок. Если можешь подтвердить, что норма действует, продолжай. Если проверить не можешь:

⚠️ СТАТУС НОРМЫ НЕ ПРОВЕРЕН — я не смог подтвердить, что эта норма сейчас действует. Окончательные правила часто приостанавливают, запрещают судебным решением, откладывают или отменяют после публикации. Не вносите эту редакцию, пока не подтвердите статус нормы в деле Federal Register или у внешнего юриста.

Выведи этот баннер над шапкой рабочих материалов юриста. Помечай каждую дату вступления в силу и соблюдения в новой редакции как [дата вступления в силу по опубликованной норме — статус не проверен].

Шаг 3: Подготовь новую редакцию

Версия затронутого раздела политики с пометками правок.

Детальность правок — минимально возможная правка

Сначала вычёркивай слово, потом предложение.
Сначала вычёркивай предложение, потом абзац.
Сначала вычёркивай абзац, потом раздел.
Трогай только разделы, затронутые пробелом. Не меняй стиль всей политики.

Условные обозначения

Вычеркнутый текст: ~~вычеркнутый текст~~
Вставленный текст: вставленный текст
К каждому изменению прилагается встроенный комментарий, объясняющий, ЗАЧЕМ оно сделано: правило, ссылка, закрываемый пробел:

> [Изменение: в определение PII добавлены биометрические идентификаторы по поправкам к COPPA 2025 года, 16 CFR 312.2 (вступает в силу 22 апр. 2026) [verify]]

Любая дата вступления в силу, порог, ссылка или требование, взятые из знаний модели или непроверенного источника, получают метку [verify] прямо в тексте, а не только в сводке изменений.
Переноси метки источников из сравнения: [Federal Register], [web search — verify], [model knowledge — verify], [user provided]. Не убирай их при переходе от сравнения к новой редакции.

Дисциплина охвата

Если раздел политики пробелом не затронут, оставь его в покое. Новая редакция, которая трогает разделы за пределами пробела, выглядит так, будто ИИ высказался о том, о чём его не спрашивали, и усложняет проверку.

Если при подготовке правки ты заметил второй пробел (положение явно расходится с нормой, но не входило в исходный пробел), не исправляй его молча. Отметь в примечании для проверяющего: «При подготовке правки по [GAP-ID] я заметил, что у [другого положения], по-видимому, есть связанная проблема с требованием [требование]. В эту редакцию не включено. Рассмотрите дополнительный пробел».

Шаг 4: Результат — записка о новой редакции политики

[ШАПКА РАБОЧИХ МАТЕРИАЛОВ — по настройкам плагина ## Outputs — зависит от роли; см. `## Who's using this`]

> **⚠️ Примечание для проверяющего**
> - **Источники:** [коннектор исследований: CourtListener ✓ проверено | не подключён — ссылки по обучающим знаниям, проверьте, прежде чем полагаться]
> - **Прочитано:** [какие разделы политики просмотрены; что не читалось]
> - **Отмечено для вашего суждения:** [N пунктов с пометкой `[review]` в тексте | нет]
> - **Актуальность:** [статус нормы проверен по [источнику], [дата] | не проверен — см. баннер выше]
> - **Прежде чем полагаться:** подтвердите, что это текущая утверждённая версия политики; проверьте статус нормы и дату вступления в силу; получите проверку владельца политики; пройдите ваш процесс утверждения изменений политики; обновляйте трекер пробелов только после внесения и утверждения.

## Новая редакция политики: [название политики]

**Пробел:** [GAP-ID или короткое описание]
**Норма:** [название, ссылка, дата вступления в силу]
**Политика:** [название, дата последнего обновления]
**Статус:** ПРЕДЛОЖЕНИЕ — ещё не проверено и не утверждено

### Итог

[Одно предложение: в чём пробел. Одно предложение: что делает новая редакция. Одно предложение: что требует проверки.]

### Размеченные разделы политики

[Текст с пометками правок и встроенными комментариями `[Изменение: ...]`. Только затронутые разделы.]

### Сводка изменений

| # | Положение | Сейчас | Предлагается | Почему | Проверить |
|---|---|---|---|---|---|
| 1 | §2.1 Определение PII | "…имена, адреса, номера соцстрахования…" | "…имена, адреса, номера соцстрахования, биометрические идентификаторы…" | Поправки к COPPA 2025 расширяют PII на биометрию | [Federal Register] |
| 2 | §4.3 Срок хранения | "30 дней" | "14 дней" | Новая норма вводит предел в 14 дней | `[verify — model knowledge]` |

### Перед внесением — чек-лист

- [ ] Подтвердите, что это текущая утверждённая версия переписываемой политики.
- [ ] Проверьте статус нормы и дату вступления в силу (дело в Federal Register или внешний юрист).
- [ ] Получите проверку владельца политики.
- [ ] Пройдите ваш процесс утверждения изменений политики.
- [ ] Обновите трекер пробелов после внесения и утверждения, не раньше.

---

**Что дальше? Выберите один пункт, и я помогу его развернуть:**

1. **Внести и получить согласование** — вы проверяете, передаёте владельцу политики, проводите через ваш процесс утверждения. Когда утвердят, скажите мне, и я отмечу пробел закрытым.
2. **Узнать больше о [X]** — если для какого-то изменения нужно больше оснований (проверить ссылку, уточнить порог, решить вопрос юрисдикции), скажите какое, и я разберусь.
3. **Эскалировать [владельцу / главному юристу]** — если новая редакция поднимает вопрос выше полномочий владельца политики, я подготовлю короткую эскалацию с фактами, предлагаемым изменением и тем, какое решение нужно.
4. **Наблюдать и ждать** — если статус нормы неясен или владельца политики нет на месте, я добавлю в трекер пробелов пометку о пересмотре.
5. **Что-то другое** — скажите, что бы вы с этим сделали.

Имя файла

Имя выходного файла ясно показывает, что это черновик. Используй:

[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 не указан владелец. Назначьте его через /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 с барьером утверждения — будущий скилл.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/regulatory-legal/skills/policy-redraft, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: policy-redraft
description: Produce a proposed marked-up policy redraft that closes a gap found by /regulatory-legal:gaps or /regulatory-legal:policy-diff. A first draft for internal review — not for direct application to approved policy documents. Use when the user says "redraft the policy", "draft the policy fix", "mark up the policy", or when gap-surfacer hands off a gap for drafting.
argument-hint: "[GAP-ID or gap description]"
---

# /policy-redraft

1. Load `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` → policy library index + practice profile.
2. Use the workflow below.
3. Gather inputs: the gap (from `/regulatory-legal:gaps` output or described directly), the current approved policy text, the rule text.
4. Verify the rule is current (per the policy-diff rule-status check). If you can't verify, emit the `⚠️ RULE STATUS UNVERIFIED` banner.
5. Produce a marked-up redraft of the affected policy section(s) — smallest-possible edit, `[verify]` tags carried through, inline comments explaining WHY each change was made.
6. Output a Policy Redraft Memo. Write it to a new file named `[policy-name]-proposed-redraft-[YYYY-MM-DD].md` — never write to the source policy document.
7. Do NOT close the gap in the tracker. The gap closes when the redraft is applied AND approved, which is the policy owner's action.

---

> This skill produces a **proposal**, not an edit. It writes to a new file with a clearly-marked draft filename. It never writes over a source policy document, and it never closes a gap in the tracker — the gap closes when the redraft is applied AND approved by the policy owner.

## 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

Gap-surfacer finds the gap. Policy-diff names what needs to change. This skill takes the next step and produces a marked-up redraft of the affected policy section — small, specific, flagged — as a first draft for the policy owner's review.

## Hard guardrails — read these first

These are the load-bearing rules. If any of them would be violated, stop and ask.

1. **This is a PROPOSAL, not an edit.** Never write directly to a source policy document. The output goes to a new file at `[policy-name]-proposed-redraft-[YYYY-MM-DD].md`, or into the matter workspace. Not `[policy-name].md`.
2. **Never close the gap in the tracker.** Gaps close when the redraft is APPLIED AND APPROVED — that is the policy owner's action, not yours. If the user says "close the gap now that you've redrafted it," decline: "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."
3. **"Apply this for me" is not in scope.** If the user asks you to apply the redraft to the source policy: "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."
4. **Confirm the policy version before redrafting.** If the user gives you a file, ask: "Is this the approved version of the policy, and is it the latest? A redraft against an outdated policy creates divergence." If they paste text, trust but flag in the reviewer note.
5. **Smallest-possible edit.** Strike a word before a sentence, a sentence before a paragraph, a paragraph before a section. Only touch sections affected by the gap. Don't restyle the policy.
6. **Carry `[verify]` tags through.** Any effective date, threshold, citation, or requirement that came from model knowledge or an unverified source gets tagged in the redraft itself, not just in the memo.

## Step 1: Gather inputs

Three inputs are required. If any is missing, ask — don't infer.

### 1a. The gap

One of:
- A `GAP-ID` from the gap tracker — load the entry from `~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml` (or the matter-level equivalent).
- A gap described in the user's message — capture the requirement, the regulation, and the affected policy.
- A diff summary pasted from `/regulatory-legal:policy-diff` output.

### 1b. The current policy text

One of:
- A file path — read it, then ask: "Is this the approved version of the policy, and is it the latest? A redraft against an outdated policy creates divergence." Note the answer in the reviewer note.
- Pasted text — trust but flag in the reviewer note: "Policy text was pasted directly; I assumed it was the current approved version. Confirm before applying."
- Neither — ask for one. Do not guess at the policy text from the gap tracker or from web search.

### 1c. The rule text

One of:
- The diff output (already has the rule extracted and tagged).
- A fetched regulation — note the source with a provenance tag.
- Pasted rule text from the user — tag `[user provided]`.

If the rule text is partial or ambiguous, apply the **no silent supplement** rule from CLAUDE.md: offer the user the options (paste full text, point at primary source, web-search-with-verify-tag, or stop), and wait.

## Step 2: Verify the rule is current

Use the same rule-status check pattern as `policy-diff`. Red flags that the rule may not be in force:

- The applicability/compliance date has passed by more than 30 days with 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 verify the rule is in force, proceed. If you cannot verify:

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

Emit that banner above the work-product header. Tag every effective/compliance date in the redraft as `[effective date per published rule — status unverified]`.

## Step 3: Produce the redraft

A marked-up version of the affected policy section.

### Redline granularity — smallest possible edit

- Strike a word before a sentence.
- Strike a sentence before a paragraph.
- Strike a paragraph before a section.
- Only touch sections affected by the gap. Don't restyle the whole policy.

### Conventions

- Struck text: `~~struck text~~`
- Inserted text: **inserted text**
- Each change carries an inline comment explaining WHY — the rule, the cite, the gap being closed:

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

- Any effective date, threshold, citation, or requirement that came from model knowledge or an unverified source gets a `[verify]` tag inline — not just in the change summary.
- Carry source tags through from the diff: `[Federal Register]`, `[web search — verify]`, `[model knowledge — verify]`, `[user provided]`. Don't strip them when moving from the diff to the redraft.

### Scope discipline

If a section of the policy isn't affected by the gap, leave it alone. A redraft that touches sections outside the gap looks like the AI opined on things it wasn't asked to opine on, and makes the review harder.

If you see a second gap while redrafting — a provision that's clearly out of step with the rule but wasn't in the original gap — don't silently fix it. Flag it in the 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."

## Step 4: Output — Policy Redraft Memo

```markdown
[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.
```

## Filename

The output file name makes clear it's a draft. Use:

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

Not `[policy-name].md`. Not `[policy-name]-v2.md`. The word "proposed-redraft" and the date are load-bearing — they prevent the draft from being mistaken for the current version.

Write to the matter workspace if one is active; otherwise to the current working directory or a location the user names. Do not write to the policy library source directory.

## Config-dependent fallbacks

This skill reads the policy library index and owners from `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`. When a value it needs is empty or still `[PLACEHOLDER]`:

- **Policy owner missing:** still produce the redraft. Note in the 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."
- **Policy library empty and the gap doesn't name a specific policy:** stop and ask: "I need the current policy text to redraft. Paste the text of the affected policy, or point me at the file."

Say nothing about config when the values are populated.

## Interactions with other skills

- **Upstream inputs** come from `policy-diff` (per-requirement gap analysis) and `gap-surfacer` (the tracker). Carry their source tags and `[verify]` flags through.
- **Gap tracker state:** this skill does NOT change the tracker. It doesn't mark the gap closed, doesn't mark it in-progress, doesn't touch `notified`. If you want a paper trail that a redraft exists, the policy owner or the user can update the gap entry with a resolution note when the redraft is applied and approved — see `/regulatory-legal:gaps --close`.
- **Severity floor:** if the upstream gap is 🔴 or 🟠, the memo's Bottom line carries that severity. Silent demotion is a contradiction a reviewing lawyer cannot see. See CLAUDE.md `## Cross-skill severity floor`.

## Close with the next-steps decision tree

Included in the output template above. Customize the options to what the redraft actually produced — if the rule status is unverified, option 2 (get more info) moves up; if the policy owner isn't set, option 3 (escalate) gets specific.

## What this skill does not do

- Apply the redraft to the source policy. That's the policy owner's action.
- Close the gap in the tracker. Gaps close when the redraft is applied and approved.
- Rewrite the whole policy. Smallest-possible edit to close the gap.
- Produce multi-policy redrafts. One gap, one policy, one memo. A `:package` command for multi-policy fan-out is a future skill.
- Produce the "apply" workflow. An `:apply` command with an approval gate is a future skill.

Источник: anthropics/claude-for-legal / regulatory-legal / policy-redraft ↗. Ссылка проверена 2026-10-10.

---
name: policy-redraft
description: Подготовь предлагаемую новую редакцию политики с пометками правок, которая закрывает пробел, найденный командой /regulatory-legal:gaps или /regulatory-legal:policy-diff. Это первый черновик для внутренней проверки, а не для прямого внесения в утверждённые документы политик. Используй, когда пользователь говорит «перепиши политику», «подготовь правку политики», «размеч политику правками» или когда gap-surfacer передаёт пробел для подготовки правки.
argument-hint: "[GAP-ID или описание пробела]"
---

# /policy-redraft

1. Загрузи `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` → индекс библиотеки политик + профиль практики.
2. Используй рабочий процесс ниже.
3. Собери входные данные: пробел (из вывода `/regulatory-legal:gaps` или описанный напрямую), текущий утверждённый текст политики, текст нормы.
4. Проверь, что норма актуальна (по проверке статуса нормы из policy-diff). Если проверить не можешь, выведи баннер `⚠️ СТАТУС НОРМЫ НЕ ПРОВЕРЕН`.
5. Подготовь новую редакцию затронутых разделов политики с пометками правок: минимально возможная правка, метки `[verify]` перенесены, встроенные комментарии объясняют, ЗАЧЕМ внесено каждое изменение.
6. Выдай записку о новой редакции политики. Запиши её в новый файл с именем `[policy-name]-proposed-redraft-[YYYY-MM-DD].md`, никогда не записывай в исходный документ политики.
7. НЕ закрывай пробел в трекере. Пробел закрывается, когда новая редакция внесена И утверждена, а это действие владельца политики.

---

> Этот скилл готовит **предложение**, а не правку. Он пишет в новый файл с явно помеченным именем черновика. Он никогда не перезаписывает исходный документ политики и никогда не закрывает пробел в трекере: пробел закрывается, когда владелец политики внёс новую редакцию И утвердил её.

## Контекст дела

**Контекст дела.** Проверь раздел `## Matter workspaces` в CLAUDE.md уровня практики. Если `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: Собери входные данные

Нужны три входных данных. Если чего-то нет, спроси, не выводи сам.

### 1а. Пробел

Что-то одно из:
- `GAP-ID` из трекера пробелов: загрузи запись из `~/.claude/plugins/config/claude-for-legal/regulatory-legal/gap-tracker.yaml` (или аналога на уровне дела).
- Пробел, описанный в сообщении пользователя: зафиксируй требование, норму и затронутую политику.
- Сводка сравнения, вставленная из вывода `/regulatory-legal:policy-diff`.

### 1б. Текущий текст политики

Что-то одно из:
- Путь к файлу: прочитай его, затем спроси: «Это утверждённая версия политики и самая последняя? Правка на основе устаревшей политики создаёт расхождение». Запиши ответ в примечание для проверяющего.
- Вставленный текст: поверь, но отметь в примечании для проверяющего: «Текст политики был вставлен напрямую; я исходил из того, что это текущая утверждённая версия. Подтвердите, прежде чем вносить».
- Ни того ни другого: попроси что-то одно. Не угадывай текст политики по трекеру пробелов или веб-поиску.

### 1в. Текст нормы

Что-то одно из:
- Результат сравнения (в нём норма уже выделена и помечена).
- Загруженная норма: укажи источник с меткой происхождения.
- Текст нормы, вставленный пользователем: пометь `[user provided]`.

Если текст нормы неполный или неоднозначный, примени правило **без тихого дополнения** из CLAUDE.md: предложи пользователю варианты (вставить полный текст, указать первоисточник, веб-поиск с меткой verify или остановиться) и жди.

## Шаг 2: Проверь, что норма актуальна

Используй ту же схему проверки статуса нормы, что и `policy-diff`. Тревожные признаки того, что норма может не действовать:

- Дата применения или соблюдения прошла больше 30 дней назад без подтверждения, что её не отложили.
- Норме больше 12 месяцев.
- Норма — политически спорное окончательное правило (крупные нормотворческие акты часто оспариваются).

Заметив тревожный признак, проверь (через MCP-исследования, веб-поиск, если он включён, или дело в Federal Register) наличие: отсрочек, приостановлений, судебных запретов, предложений об отмене, признания недействительным или поправок. Если можешь подтвердить, что норма действует, продолжай. Если проверить не можешь:

> `⚠️ СТАТУС НОРМЫ НЕ ПРОВЕРЕН — я не смог подтвердить, что эта норма сейчас действует. Окончательные правила часто приостанавливают, запрещают судебным решением, откладывают или отменяют после публикации. Не вносите эту редакцию, пока не подтвердите статус нормы в деле Federal Register или у внешнего юриста.`

Выведи этот баннер над шапкой рабочих материалов юриста. Помечай каждую дату вступления в силу и соблюдения в новой редакции как `[дата вступления в силу по опубликованной норме — статус не проверен]`.

## Шаг 3: Подготовь новую редакцию

Версия затронутого раздела политики с пометками правок.

### Детальность правок — минимально возможная правка

- Сначала вычёркивай слово, потом предложение.
- Сначала вычёркивай предложение, потом абзац.
- Сначала вычёркивай абзац, потом раздел.
- Трогай только разделы, затронутые пробелом. Не меняй стиль всей политики.

### Условные обозначения

- Вычеркнутый текст: `~~вычеркнутый текст~~`
- Вставленный текст: **вставленный текст**
- К каждому изменению прилагается встроенный комментарий, объясняющий, ЗАЧЕМ оно сделано: правило, ссылка, закрываемый пробел:

  > `[Изменение: в определение PII добавлены биометрические идентификаторы по поправкам к COPPA 2025 года, 16 CFR 312.2 (вступает в силу 22 апр. 2026) [verify]]`

- Любая дата вступления в силу, порог, ссылка или требование, взятые из знаний модели или непроверенного источника, получают метку `[verify]` прямо в тексте, а не только в сводке изменений.
- Переноси метки источников из сравнения: `[Federal Register]`, `[web search — verify]`, `[model knowledge — verify]`, `[user provided]`. Не убирай их при переходе от сравнения к новой редакции.

### Дисциплина охвата

Если раздел политики пробелом не затронут, оставь его в покое. Новая редакция, которая трогает разделы за пределами пробела, выглядит так, будто ИИ высказался о том, о чём его не спрашивали, и усложняет проверку.

Если при подготовке правки ты заметил второй пробел (положение явно расходится с нормой, но не входило в исходный пробел), не исправляй его молча. Отметь в примечании для проверяющего: «При подготовке правки по [GAP-ID] я заметил, что у [другого положения], по-видимому, есть связанная проблема с требованием [требование]. В эту редакцию не включено. Рассмотрите дополнительный пробел».

## Шаг 4: Результат — записка о новой редакции политики

```markdown
[ШАПКА РАБОЧИХ МАТЕРИАЛОВ — по настройкам плагина ## Outputs — зависит от роли; см. `## Who's using this`]

> **⚠️ Примечание для проверяющего**
> - **Источники:** [коннектор исследований: CourtListener ✓ проверено | не подключён — ссылки по обучающим знаниям, проверьте, прежде чем полагаться]
> - **Прочитано:** [какие разделы политики просмотрены; что не читалось]
> - **Отмечено для вашего суждения:** [N пунктов с пометкой `[review]` в тексте | нет]
> - **Актуальность:** [статус нормы проверен по [источнику], [дата] | не проверен — см. баннер выше]
> - **Прежде чем полагаться:** подтвердите, что это текущая утверждённая версия политики; проверьте статус нормы и дату вступления в силу; получите проверку владельца политики; пройдите ваш процесс утверждения изменений политики; обновляйте трекер пробелов только после внесения и утверждения.

## Новая редакция политики: [название политики]

**Пробел:** [GAP-ID или короткое описание]
**Норма:** [название, ссылка, дата вступления в силу]
**Политика:** [название, дата последнего обновления]
**Статус:** ПРЕДЛОЖЕНИЕ — ещё не проверено и не утверждено

### Итог

[Одно предложение: в чём пробел. Одно предложение: что делает новая редакция. Одно предложение: что требует проверки.]

### Размеченные разделы политики

[Текст с пометками правок и встроенными комментариями `[Изменение: ...]`. Только затронутые разделы.]

### Сводка изменений

| # | Положение | Сейчас | Предлагается | Почему | Проверить |
|---|---|---|---|---|---|
| 1 | §2.1 Определение PII | "…имена, адреса, номера соцстрахования…" | "…имена, адреса, номера соцстрахования, биометрические идентификаторы…" | Поправки к COPPA 2025 расширяют PII на биометрию | [Federal Register] |
| 2 | §4.3 Срок хранения | "30 дней" | "14 дней" | Новая норма вводит предел в 14 дней | `[verify — model knowledge]` |

### Перед внесением — чек-лист

- [ ] Подтвердите, что это текущая утверждённая версия переписываемой политики.
- [ ] Проверьте статус нормы и дату вступления в силу (дело в Federal Register или внешний юрист).
- [ ] Получите проверку владельца политики.
- [ ] Пройдите ваш процесс утверждения изменений политики.
- [ ] Обновите трекер пробелов после внесения и утверждения, не раньше.

---

**Что дальше? Выберите один пункт, и я помогу его развернуть:**

1. **Внести и получить согласование** — вы проверяете, передаёте владельцу политики, проводите через ваш процесс утверждения. Когда утвердят, скажите мне, и я отмечу пробел закрытым.
2. **Узнать больше о [X]** — если для какого-то изменения нужно больше оснований (проверить ссылку, уточнить порог, решить вопрос юрисдикции), скажите какое, и я разберусь.
3. **Эскалировать [владельцу / главному юристу]** — если новая редакция поднимает вопрос выше полномочий владельца политики, я подготовлю короткую эскалацию с фактами, предлагаемым изменением и тем, какое решение нужно.
4. **Наблюдать и ждать** — если статус нормы неясен или владельца политики нет на месте, я добавлю в трекер пробелов пометку о пересмотре.
5. **Что-то другое** — скажите, что бы вы с этим сделали.
```

## Имя файла

Имя выходного файла ясно показывает, что это черновик. Используй:

`[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` не указан владелец. Назначьте его через `/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` с барьером утверждения — будущий скилл.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/regulatory-legal/skills/policy-redraft, лицензия Apache-2.0. Изменения: перевод на русский язык.

Правка политики под новую норму

Как включить

Текст

/policy-redraft

Контекст дела

Назначение

Жёсткие ограничения — прочитай их первыми

Шаг 1: Собери входные данные

1а. Пробел

1б. Текущий текст политики

1в. Текст нормы

Шаг 2: Проверь, что норма актуальна

Шаг 3: Подготовь новую редакцию

Детальность правок — минимально возможная правка

Условные обозначения

Дисциплина охвата

Шаг 4: Результат — записка о новой редакции политики

Имя файла

Запасные варианты, зависящие от настроек

Взаимодействие с другими скиллами

Закрой деревом следующих шагов

Чего этот скилл не делает

Похожие