Сравнение новой нормы с внутренними политиками
Находит, каких политик компании касается изменившаяся норма, и показывает пробел между требованием и текстом политики.
- Что делает
- Находит, каких политик компании касается изменившаяся норма, и показывает пробел между требованием и текстом политики.
- Когда брать
- Когда норма изменилась или вышла новая и нужно понять, какие внутренние политики придётся обновить.
- Когда не брать
- Если нет проиндексированной библиотеки политик: скилл тогда отметит все требования как пробелы. Он также не пишет сами правки политик.
- Пример запроса
- Сравни эту норму с нашими политиками и покажи, какие нужно обновить.
- Нужно подключить
- библиотека политик компании (индекс в настройках плагина)
- Работает лучше с
- инструмент правовых исследований, доступ в интернет
Входит в плагин regulatory-legal. В Cowork и Claude Code можно поставить плагин целиком.
Как включить
- Скачайте архив и распакуйте его.
- Положите папку
policy-diffв~/.claude/skills/. - Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.
Текст
---
name: policy-diff
description: Сравни конкретное регуляторное изменение с проиндексированной библиотекой политик. Используй, когда норма изменилась и нужно узнать, каких политик это касается и в чём пробел, когда пользователь говорит «сравни эту норму с нашими политиками», «какую политику это затрагивает» или «анализ пробелов», либо когда reg-feed-watcher передаёт существенный пункт.
argument-hint: "[название нормы или вставь текст/резюме нормы]"
---
/policy-diff
- Загрузи
~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.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.
Назначение
Норма изменилась. У тебя есть политики. Скилл находит, каких политик касается изменение и каков пробел между «что норма теперь требует» и «что говорит политика».
Загрузи контекст
~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md → индекс библиотеки политик (политики, где лежат, владельцы).
Целостность охвата
Если пользователь просит исключить из сравнения раздел политики, требование или категорию:
- Сделай это: охват определяет пользователь.
- Но отметь это громко и навсегда: «⚠️ ОГРАНИЧЕНИЕ ОХВАТА: раздел [X] исключён по просьбе пользователя. Это сравнение не отражает политику полностью. Пробелы в исключённой области НЕ выявлены». Над заголовком, с переносом в каждый последующий документ.
- Передай отметку в
gap-surfacer: «Это сравнение ограничено по охвату. Не выдавай его за полную картину соответствия». Включай баннер об ограничении охвата дословно в каждую запись трекера пробелов, полученную из этого сравнения. - Объясни, что значит исключение: «Исключение управления поставщиками означает, что сравнение покажет “ни одна политика не касается управления поставщиками”, что хуже, чем показать пробел».
Документ о соответствии, построенный на нераскрытом исключении охвата, при раскрытии доказательств выглядит как сокрытие. Отметка — это разница между «мы ограничили проверку» и «мы скрыли проблему».
Рабочий процесс
Шаг 0: Проверь статус нормы до сравнения
Прежде чем сравнивать норму с политикой, убедись, что норма действительно действует. Тревожные признаки того, что норма может не действовать:
- Дата применения или соблюдения прошла больше 30 дней назад, но нет подтверждения, что её не отложили
- Норме больше 12 месяцев
- Норма — политически спорное окончательное правило (крупные нормотворческие акты часто оспариваются)
Заметив тревожный признак, проверь (через MCP-исследования, веб-поиск, если он включён, или дело в Federal Register) наличие: отсрочек, приостановлений, судебных запретов, предложений об отмене, признания недействительным или поправок. Если проверить можно и норма подтверждённо действует, продолжай. Если проверить нельзя (инструменты не подключены), выведи этот баннер НАД заголовком, до любого содержимого:
⚠️ СТАТУС НОРМЫ НЕ ПРОВЕРЕН — я не смог подтвердить, что эта норма сейчас действует. Окончательные правила часто приостанавливают, запрещают судебным решением, откладывают или отменяют после публикации. Не считайте ни одну из дат соблюдения ниже обязательной, пока не подтвердите статус нормы в деле Federal Register или у внешнего юриста.
Помечай каждый срок в результате: [срок по опубликованной норме — статус не проверен].
Неопределённость статуса нормы идёт дальше по цепочке. Передавая пробел в gap-surfacer, помечай пункт status_verified: false, чтобы он никогда не попал в группу «Просрочено» только на основании опубликованной даты.
Шаг 1: Выдели новые требования
Без тихого дополнения. Если текст регуляторного изменения неполный или неоднозначный, а более полного текста нормы в проиндексированном источнике нет, остановись и спроси. НЕ заполняй пробел веб-поиском или знаниями модели, не спросив. Скажи: «У меня есть [что есть]. Чтобы точно выделить требования, мне нужно [чего не хватает]. Варианты: (1) вставьте полный текст, (2) укажите первоисточник, (3) поискать норму в интернете: результаты будут помечены [web search — verify], и их нужно сверить с органом, издавшим акт, прежде чем полагаться, или (4) остановиться на этом. Что выберете?» Решать, принимать ли менее надёжные источники, должен юрист; Claude за него не решает.
Указание источника. Помечай каждую цитату (регуляторную ссылку, любые перекрёстные ссылки, любые выдержки из политик) тем, откуда она взята: [<регулятор или инструмент исследования>] для пунктов, полученных из первоисточника, библиотеки политик или MCP; [web search — verify] для пунктов из веб-поиска; [model knowledge — verify] для пунктов, вспомненных из обучающих данных модели; [user provided] для пунктов, вставленных пользователем. Пункты с пометкой verify несут повышенный риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай метки в результате.
Прочитай регуляторное изменение. Перечисли каждое отдельное новое или изменённое требование:
| # | Требование | Вступает в силу | Ссылка |
|---|---|---|---|
| 1 | [что требует] | [дата] | [раздел] |
Будь конкретен. «Усиленные требования к раскрытию» — это не требование. «Нужно раскрыть X в формате Y в момент Z процесса» — требование.
Шаг 2: Сопоставь с политиками
Для каждого требования: какая из проиндексированных политик ближе всего?
- Прямое попадание: политика прямо покрывает эту тему
- Косвенное: политика покрывает смежную тему, а это — новый подвопрос
- Нет совпадения: ни одна политика этого не касается; пробел в том, что «политики не существует»
Шаг 3: Сравни
Для каждого прямого или косвенного попадания прочитай политику и сравни:
### Требование [N]: [название]
**Новая норма требует:** [требование]
**Наша политика ([название], обновлена [дата]) говорит:**
> "[релевантная выдержка]"
**Пробел:** [Нет — политика уже это покрывает | Частичный — политика касается X, но не Y | Полный — политика противоречит или это не затрагивает]
**Нужное изменение:** [конкретно — «добавить абзац про X», а не «обновить политику»]
**Владелец политики:** [из индекса]
Шаг 4: Пробелы без совпадения
Требования, для которых не нашлось политики, выделяй отдельно:
### Нужна новая политика
Требование [N]: [требование]
Ни одна существующая политика этого не покрывает. Варианты:
- Написать новую политику (предлагаемый владелец: [тот, кто отвечает за ближайшую тему])
- Добавить как новый раздел в существующую [смежную политику]
- Определить, что политика не нужна (разовое соответствие, не постоянное)
Ветви по типу регуляторного материала
Ветвь до принятия правила (ANPR / RFI)
Если регуляторный материал — ANPR или RFI (обязательств он не налагает), НЕ проводи полное сравнение для закрытия пробелов. Вместо этого подготовь анализ предварительного позиционирования:
- Назови политики, которые, вероятно, придётся менять после выхода окончательного правила (не сегодня).
- Отметь, пересекаются ли области вопросов ANPR с практикой компании так, что стоит подать письмо с комментарием.
- Укажи срок комментария и ответственного команды за решение о комментариях из
~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md. - НЕ делай для ANPR строки «пробела нет» по каждому требованию: сравнивать не с чем. Сделай один абзац, называющий будущий риск и политики, которых он коснётся.
Ветвь отрицательного вывода (окончательное правило / NPRM, сравниваемые с политикой, которая не является нужной целью)
Если каждое выделенное требование оказывается «пробела против [названной политики] нет», НЕ делай полный анализ по каждому требованию: сожми до одного короткого абзаца:
## Сравнение с политикой: [название нормы] — [название политики]
[НОРМА], по-видимому, не требует менять [НАЗВАНИЕ ПОЛИТИКИ]. [НАЗВАНИЕ ПОЛИТИКИ]
§[X] уже покрывает [Y]. Политики, которых эта норма действительно касается, —
[другая-политика-1] и [другая-политика-2]; запусти `/regulatory-legal:policy-diff` снова против них.
Пересмотр: [в следующем цикле — например, «при следующем ежегодном пересмотре политик»] или если
[триггер — например, «правило будет принято в окончательном виде или изменено»].
Один абзац, одна рекомендация, пометка о маршрутизации. Не повторяй вывод «пробела нет» для каждого требования: это покрывает сводная таблица. Отрицательный вывод против неверной целевой политики — проблема маршрутизации, а не анализ соответствия.
Ветвь с пробелом (окончательное правило / NPRM, где против целевой политики есть хотя бы один пробел)
Полный анализ по каждому требованию, как описано ниже. Подробный формат сравнения нужен для сравнений, которые действительно находят пробелы.
Результат
[ШАПКА РАБОЧИХ МАТЕРИАЛОВ — по настройкам плагина ## Outputs — зависит от роли; см. `## Who's using this`]
## Сравнение с политиками: [название нормы]
**Норма:** [название, ссылка]
**Вступает в силу:** [дата]
**Выделено требований:** [N]
### Итог
[N пробелов требуют действий к [дата] — топ-3: X, Y, Z]
### Сводка
| # | Требование | Затронутая политика | Пробел | Ответственный |
|---|---|---|---|---|
| 1 | [коротко] | [название политики или «нет»] | Нет/Частичный/Полный | [имя] |
### Подробные сравнения
[Каждый блок требования из шага 3]
### Нужные новые политики
[Из шага 4, если есть]
### Требования без пробелов
[Список: полезно знать, что уже покрыто]
---
**Проверь цитаты, прежде чем на них полагаться.** Регуляторные ссылки и ссылки на политики выше сгенерированы ИИ и не сверены с первоисточником. Прежде чем действовать по любому требованию отсюда, подтверди норму по Westlaw, исследовательской платформе вашей фирмы или сайту органа, издавшего акт: проверь точность, дату вступления в силу и текущий статус. Регуляторные ссылки, сгенерированные ИИ, иногда бывают выдуманными, искажёнными или устаревшими. Метки источников у каждого требования (например, `[Federal Register]`, `[web search — verify]`) показывают, откуда взята ссылка; метки `verify` несут повышенный риск выдумки, и проверять их нужно в первую очередь.
Запасные варианты, зависящие от настроек
Этот скилл читает индекс библиотеки политик из ~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md. Если индекс пуст или в нём всё ещё [PLACEHOLDER]:
- Библиотека политик пуста: по умолчанию отметь каждое требование как «нет совпадения с политикой» и добавь в конец результата: «Библиотека политик в ваших настройках пуста, поэтому каждое требование отмечено как пробел из-за отсутствия политики. Если у вас есть политики, которые отвечают этим требованиям, добавьте их в библиотеку через
/regulatory-legal:cold-start-interview --redoили правкой~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md, затем повторите сравнение». - Нет владельца у найденной политики: оставь ячейку «Ответственный» в сводке пустой и добавь: «Владельцы политик не заданы для [список]. Назначьте их через
/regulatory-legal:cold-start-interview --redoили правкой библиотеки политик в~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md, чтобы gap-surfacer мог направлять».
Если библиотека заполнена и владельцы заданы, о настройках не говори ничего.
Передача дальше
В gap-surfacer: каждый частичный или полный пробел становится отслеживаемым пунктом с ответственным и сроком.
Закрой деревом следующих шагов
Закончи ответ деревом следующих шагов по разделу ## Outputs в CLAUDE.md. Подстрой варианты под то, что скилл только что подготовил: пять веток по умолчанию (подготовить документ X, эскалировать, собрать больше фактов, наблюдать и ждать, что-то другое) — это отправная точка, а не жёсткая рамка. Дерево и есть результат; выбирает юрист.
Чего этот скилл не делает
- Не пишет обновления политик. Он определяет, что нужно обновить; пишет policy-drafting (или человек).
- Не толкует неоднозначный регуляторный текст окончательно. Если норму можно прочесть двумя способами, скажи об этом и отметь для юриста.
Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/regulatory-legal/skills/policy-diff, лицензия Apache-2.0. Изменения: перевод на русский язык.
Оригинал на английском
--- name: policy-diff description: Diff a specific regulatory change against the indexed policy library. Use when a reg has changed and you need to know which policies it touches and what the gap is, when the user says "diff this reg against our policies", "which policy does this affect", or "gap analysis", or when reg-feed-watcher hands off a material item. argument-hint: "[reg name, or paste reg text/summary]" --- # /policy-diff 1. Load `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` → policy library index. 2. Use the workflow below. 3. Extract requirements from the reg. Match to indexed policies. 4. Output: per-requirement gap analysis, which policy needs updating. --- ## 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 A reg changed. You have policies. This skill finds which policies the change touches and what the gap is between "what the reg now requires" and "what the policy says." ## Load context `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md` → policy library index (policies, locations, owners). ## Scope integrity If the user asks you to exclude a policy section, requirement, or category from the diff: 1. Do it — the user owns the scope. 2. But flag it, loudly and permanently: "⚠️ SCOPE LIMITATION: Section [X] excluded at user request. This diff does not reflect the full policy. Gaps in the excluded area are NOT identified." Above the header, carried to every downstream artifact. 3. Hand the flag to `gap-surfacer`: "This diff was scope-limited. Do not represent it as a complete compliance picture." Include the scope-limitation banner verbatim on any gap tracker entry derived from this diff. 4. Note what the exclusion means: "Excluding vendor management means the diff will show 'no policy addresses vendor management' — which is worse than showing the gap." A compliance artifact built on an undisclosed scope exclusion looks like concealment in discovery. The flag is the difference between "we scoped the review" and "we hid the problem." ## Workflow ### Step 0: Verify rule status before you diff Before diffing a rule against policy, confirm the rule is actually in force. Red flags that the rule may not be in force: - The applicability/compliance date has passed by more than 30 days but you have 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 check and the rule is confirmed in force, proceed. If you cannot verify (no tools connected), emit this banner ABOVE the header, before any content: > `⚠️ 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.` Tag every due date in the output: `[due date per published rule — status unverified]`. Rule-status uncertainty travels downstream. When handing off a gap to `gap-surfacer`, mark the item `status_verified: false` so it never gets routed to an Overdue bucket on the strength of a published date alone. ### Step 1: Extract the new requirements **No silent supplement.** If the regulatory change text is partial or ambiguous and the fuller rule isn't available from the indexed source, stop and ask. Do NOT fill the gap from web search or model knowledge without asking. Say: "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?" A lawyer decides whether to accept lower-confidence sources; Claude does not decide for them. **Source attribution.** Tag every citation — the regulatory citation, any cross-references, any policy excerpts — with where it came from: `[<regulator or research tool>]` for items retrieved from a primary source, policy library, or MCP; `[web search — verify]` for items pulled from web search; `[model knowledge — verify]` for items recalled from the model's training data; `[user provided]` for items pasted in by the user. Items tagged `verify` carry higher fabrication risk and should be checked first. Never strip or collapse the tags in the output. Read the regulatory change. List each discrete new or changed requirement: | # | Requirement | Effective | Citation | |---|---|---|---| | 1 | [what it requires] | [date] | [section] | Be specific. "Enhanced disclosure requirements" is not a requirement. "Must disclose X in Y format at Z point in the flow" is. ### Step 2: Map to policies For each requirement, which indexed policy is closest? - Direct hit: policy explicitly covers this topic - Indirect: policy covers a related topic, this is a new sub-issue - No match: no policy addresses this — gap is "policy doesn't exist" ### Step 3: Diff For each direct or indirect hit, read the policy and compare: ```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] ``` ### Step 4: No-match gaps Requirements with no policy match get called out separately: ```markdown ### 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) ``` ## Branches by regulatory input type ### Pre-rule branch (ANPR / RFI) If the regulatory input is an ANPR or RFI (no imposed requirements), do NOT run a full gap-closure diff. Instead, produce a **pre-positioning analysis**: - Name the policies that will likely need to change once a final rule issues (not today). - Flag whether any of the ANPR's issue areas intersect with the company's practice in a way that warrants a comment letter. - Note the comment deadline and the team's comment-decision owner from `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`. - Do NOT produce per-requirement "no gap" rows for an ANPR — there are no requirements to diff against. Produce one paragraph naming the future exposure and the policies it would touch. ### Negative-finding branch (final rule / NPRM diffed against a policy that isn't the right target) If every requirement in the extracted list comes out as "no gap against [the named policy]," do NOT produce the full per-requirement analysis — compress to a single short paragraph: ```markdown ## 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"]. ``` One paragraph, one recommendation, routing note. Don't repeat the "no gap" finding for every requirement — the summary table handles that. A negative finding against the wrong target policy is a routing problem, not a compliance analysis. ### Gap branch (final rule / NPRM with at least one gap against the target policy) Full per-requirement analysis as specified below. The detailed diff format is for diffs that actually find gaps. ## Output ```markdown [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] --- **Verify citations before relying on them.** The regulatory citations and policy references above were AI-generated and have not been checked against a primary source. Before acting on any requirement here, confirm the rule against Westlaw, your firm's research platform, or the issuing authority's website — check accuracy, effective date, and current status. AI-generated regulatory citations are sometimes fabricated, misquoted, or stale. Source tags on each requirement (e.g., `[Federal Register]`, `[web search — verify]`) show where the citation came from; `verify` tags carry higher fabrication risk and should be checked first. ``` ## Config-dependent fallbacks This skill reads the policy library index from `~/.claude/plugins/config/claude-for-legal/regulatory-legal/CLAUDE.md`. When the index is empty or still `[PLACEHOLDER]`: - **Policy library empty:** flag every requirement as "no policy match" by default and append to the output: "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 missing for a matched policy:** leave the Owner cell blank in the summary and append: "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." Say nothing about config when the library is populated and owners are set. ## Handoff To gap-surfacer: every Partial or Full gap becomes a tracked item with owner and deadline. ## Close with the next-steps decision tree End with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks. ## What this skill does not do - Draft the policy updates. It identifies what needs updating; policy-drafting (or a human) drafts. - Interpret ambiguous regulatory text definitively. If the reg could be read two ways, say so and flag for counsel.
Источник: anthropics/claude-for-legal / regulatory-legal / policy-diff ↗. Ссылка проверена 2026-10-10.