amendment-history

name	amendment-history
description	Trace как договор изменился — базовый договор + все дополнительные соглашения (allows на русском "доп.соглашения"). Либо summary всех изменений по времени, либо провижн-трейс конкретного пункта. Используй когда пользователь говорит "что изменилось в договоре за время", "покажи историю дополнительных соглашений", "где последняя редакция [пункта]", "как изменился [пункт]", или загружает несколько версий договора.
argument-hint	[file(s) | путь к папке] [--provision <название-пункта>]
user-invocable	true
ported_from	commercial-legal/amendment-history
ported_at	"2026-05-17T00:00:00.000Z"
adaptation_category	A
last_legislative_update	2026-05

/amendment-history

Загружает базовый договор и все доп.соглашения, потом либо summary'ит что изменилось по времени, либо trace'ит конкретный пункт до текущего controlling language.

Инструкции

1. Получи документы: из файлового upload, [CLM integration coming soon], или локальной папки. Принимаем несколько файлов за один вызов. Если ничего не предоставлено — спроси.

2. Определи режим парсингом запроса по правилам в "Mode detection" ниже. Если provision name явно указан — сразу Mode 2. Если provision не упомянут — Mode 1. Спрашивай только если genuinely ambiguous.

3. Выполни workflow ниже. Полностью.

4. Предложи follow-ups после output:

   • "Хочешь trace ещё один пункт?"
   • "Хочешь полный playbook review текущего договора с учётом доп.соглашений?" (routes to /contract-law:contract-review)
   • "Хочешь stakeholder summary ключевых изменений?" (routes to /contract-law:stakeholder-summary)

Примеры

/contract-law:amendment-history acme-msa.pdf ds-1.pdf ds-2.pdf

/contract-law:amendment-history --provision indemnity

/contract-law:amendment-history
[вставь текст договора и доп.соглашений]

---

Назначение

Договоры copит дополнительные соглашения. К третьему допсогу никто не помнит, что было в оригинале или какая версия пункта controls. Этот skill читает базовый договор и все доп.соглашения в хронологическом порядке и либо summary'ит изменения по договору в целом, либо trace'ит конкретный пункт через каждую версию чтобы найти текущее controlling language.

Mode detection

Парси user request чтобы определить режим. Не спрашивай какой режим, если запрос не genuinely ambiguous.

Mode 1 — Summary (specific provision не упомянут) Trigger фразы: "что изменилось", "история доп.соглашений", "покажи изменения по времени", "summary доп.соглашений", "как выглядит договор сейчас"

Mode 2 — Provision trace (конкретный пункт или тема названы) Trigger фразы: "где [пункт]", "последняя редакция [пункта]", "как изменился [пункт]", "найди indemnity", "что сейчас написано про [тема]"

Маппинг типичных пунктов

• "indemnity" / "indemnification" / "возмещение убытков" → секция возмещения убытков
• "liability" / "LoL" / "ограничение ответственности" → ограничение ответственности (часто отдельная статья в РФ договорах)
• "termination" / "расторжение" → срок действия и порядок прекращения
• "data" / "privacy" / "DPA" / "ПДн" → положения об обработке персональных данных (152-ФЗ)
• "IP" / "intellectual property" / "ИС" / "интеллектуальные права" → права на результаты работ (ст.1295, 1370 ГК РФ)
• "price" / "цена" / "fees" / "вознаграждение" → стоимость и порядок расчётов
• "auto-renewal" / "пролонгация" / "автоматическое продление" → механика продления
• "force-majeure" / "форс-мажор" / "обстоятельства непреодолимой силы" → ст.401 ГК
• "сторона / parties" → стороны и реквизиты

Если term ambiguous и маппится к более чем одной секции — list candidates:

"Я нашёл [N] пунктов, связанных с [term] — [список]. Какой именно?"

Если overall request ambiguous между режимами — задай один вопрос:

"Summary всех изменений по договору, или trace конкретного пункта — например indemnity, ограничение ответственности, или расторжение?"

---

Step 1: Загрузить и упорядочить документы

Accept документы из любого из источников:

[CLM integration coming soon] (если подключён): Search по имени контрагента или названию договора. Pull базовый договор и все доп.соглашения. Metadata обычно содержит даты заключения — use them для chronological order.

[Document repository coming soon] (если подключён): Search по имени контрагента или filename. Look for файлы matching patterns: "Дополнительное соглашение", "Доп.соглашение", "ДС №1", "ДС-1", "Первое дополнительное", или нумерованные suffixes ("dogovor-ds-1.pdf"). Pull all matches и sort by file date or numbering.

Direct upload: Пользователь даёт файлы напрямую. В большинстве случаев ordering self-explanatory из document titles ("ДС №1", "Дополнительное соглашение №2", "Допсог 3") или дат видимых в filename или document header — proceed без вопросов.

Спрашивай confirm ordering только если:

• Filenames не дают indication of sequence (например "договор-final.pdf", "договор-v2.pdf", "договор-правки.pdf")
• Даты отсутствуют и в filenames, и в document headers
• Два документа выглядят как одна и та же версия

Если ordering inferred (не confirmed), отметь confidence в top of output только там где uncertain:

"Порядок выведен из titles документов — один пункт, в котором я был less certain: [конкретный документ]. Confirm если это влияет на review."

Правила упорядочения

• Всегда устанавливай chronological order перед чтением content.
• Если даты заключения доступны в metadata — use them.
• Если нет — ищи даты в document header или recitals ("Настоящее Дополнительное соглашение от [дата]").
• Доп.соглашения часто ссылаются на договор, который they modify ("настоящее дополнительное соглашение к Договору №[X] от [дата]") — use these references to confirm chain.

---

Privilege inheritance

Этот skill читает базовый договор и доп.соглашения — часто конфиденциальные сами по себе, и typically used для конфиденциального анализа.

Output inherits privilege/confidentiality status источников. Prepend маркировку из ~/.ru-legal/profiles/contract-law/PROFILE.md ## Стиль работы → "Маркировка документов" (например КОНФИДЕНЦИАЛЬНО) к каждому output. Distribute только внутри привилегированного круга (см. stakeholder-summary для определения круга в РФ контексте). Store там где конфиденциальные материалы живут. Strip header перед любой external delivery.

Step 2: Прочитать и проиндексировать

Прочитай каждый документ в chronological order. Для каждого extract:

• Тип документа (базовый договор, доп.соглашение №N, addendum, протокол разногласий)
• Дата заключения
• Стороны (confirm они match across documents — флаг если new party added или party name changed; в РФ это часто означает соглашение о замене стороны по ст. 391-392 ГК и требует отдельной check)
• List of пунктов, которые explicitly modified, added, or deleted

Build working index перед output. Use it internally — не показывай пользователю.

---

Mode 1: Summary всех изменений

Section reference rule

Каждый finding должен содержать inline section reference чтобы reader мог verify без поиска:

"Право расторжения в одностороннем порядке (п. 12.3): Добавлено. Заказчик может расторгнуть с уведомлением за 90 дней без штрафа после начального срока."

Если provision spans multiple sections или section number changed across доп.соглашений — cite all references:

"Возмещение убытков (п. 9.1 в базе; п. 9.1 переизложен в ДС №5)"

Output format

# История изменений: [Контрагент] — [Тип договора]

**Базовый договор:** [дата]
**Доп.соглашений:** [N] ([дата первого] → [дата последнего])
**Последнее изменение:** [дата]

---

## Что изменилось — хронология

### ДС №1 — [дата]
**Цель:** [одно предложение — зачем заключали, из recitals или ясно из контекста.
Если не указано — пропусти, не угадывай.]

**Существенные изменения:**
- [Пункт] (п. [X.X]): [что было → что стало, plain Russian]
- [Новый пункт добавлен] (п. [X.X]): [что делает]
- [Пункт удалён] (п. [X.X]): [что убрали и почему важно]

### ДС №2 — [дата]
[та же структура]

[повтори для каждого доп.соглашения]

---

## Текущее net состояние

| Пункт | Текущая позиция | §Ref | Последнее изменение |
|-------|----------------|------|---------------------|
| [пункт] | [plain Russian summary] | п. [X.X] | ДС №N, [дата] |
| [пункт] | [не изменён с базового] | п. [X.X] | Базовый договор |

---

## Watch items (на что обратить внимание)

[Флагни всё что выглядит inconsistent — например, доп.соглашение, изменяющее пункт
который был уже удалён; противоречия между ДС; party name которое сменилось без
формального соглашения о замене стороны (ст. 391 ГК); пункт, где section number
смещён across documents. Включай section references в каждом флаге.]

---

Mode 2: Provision trace

Output format

Показывай только то что изменилось. Не list'и доп.соглашения, где provision untouched — skip их полностью.

# Provision Trace: [Название пункта]
## [Контрагент] — [Тип договора]

---

### Оригинал — [Дата базового договора], п. [X.X]
> "[точная цитата]"

*Plain Russian:* [одно предложение]

---

### ДС №[N] — [дата], п. [X.X]

**Было:**
> "[точная цитата предыдущей редакции]"

**Стало:**
> "[точная цитата новой редакции]"

*Что изменилось:* [одно предложение — практический эффект для сторон]

---

[Только последующие ДС, которые затрагивали этот пункт, появляются здесь.
Остальные omitted.]

---

## Текущая controlling редакция

**п. [X.X] — [источник, дата]**
> "[точная цитата]"

*Plain Russian:* [одно предложение]

---

## Watch items

[Флаги, inconsistencies, open questions — с section references. Типичные пункты
для проверки: подпадает ли provision под лимит ответственности или carved out;
сместился ли section number across доп.соглашений; противоречит ли язык доп.соглашения
другому пункту.]

Если provision никогда не изменялся после базового договора:

"Этот пункт не был изменён ни одним доп.соглашением. Controlling — оригинальная редакция. п. [X.X], базовый договор, [дата]."

---

Close с next-steps decision tree

Закончи next-steps decision tree из PROFILE.md ## Стиль работы → Outputs. Customize options под то что только что produced — 5 default branches (drафти X, эскалировать, get more facts, watch and wait, что-то ещё) — starting point, не lock-in. Tree — output; lawyer выбирает.

---

Что этот skill НЕ делает

• Не определяет какой документ controls в случае conflict между базовым договором и доп.соглашением — это legal interpretation question. Флагнёт conflicts и routes к Legal.
• Не drафтит новые доп.соглашения.
• Не сравнивает против playbook в PROFILE.md — это работа contract-review skill. Этот skill — purely historical.
• Не infers что доп.соглашение означает, если язык ambiguous — quotes exactly и флагнёт ambiguity для Legal.
• Не проверяет валидность доп.соглашений по форме (например, что подписаны полномочными лицами, что есть все реквизиты) — отдельный compliance check, не historical trace.

---

Специфика для РФ контекста

Термины и форма

• В РФ "amendment" / "amend the contract" по букве ГК — это "дополнительное соглашение" (ст. 452 ГК РФ; форма must совпадать с формой основного договора).
• "Addendum" в US ≠ "приложение" в РФ. Приложение — это integral часть базового договора, а не subsequent изменение. Не путать.
• "Restated agreement" в US часто аналог "новой редакции" в РФ. Имеет различные юридические последствия — особенно для contracts со state contractors / госкорпорациями.

Проверка валидности

При traceе обращай внимание на:

• Форма соглашения — ст. 452 ГК требует, чтобы изменение договора было в той же форме, что и сам договор (письменно если основной письменно). Изменение договора устным соглашением или через email exchange может быть unenforceable.
• Согласие всех сторон — если в договоре участвуют 3+ сторон, все должны подписать ДС.
• Государственная регистрация — для договоров, требующих регистрации (например аренда недвижимости >1 года), доп.соглашение тоже требует регистрации.

Особый case: smartcontracts / EDM

Электронный документооборот (ЭДО) через Контур.Сайн, СБИС, DiDoc — это валидная форма по ФЗ-63 "Об электронной подписи" (квалифицированная ЭП = собственноручная). Если документы загружены из ЭДО — упорядочивай по timestamp подписания, не по filename.

---

Attribution

Adapted from commercial-legal/amendment-history by Anthropic (Apache 2.0).

Изменения от оригинала:

• Practice profile path: → ~/.ru-legal/profiles/contract-law/PROFILE.md
• Термин "amendment" заменён на "дополнительное соглашение" (российская юридическая терминология)
• Mapping таблица пунктов расширена для РФ: ИС → ст.1295/1370 ГК, ПДн → 152-ФЗ, форс-мажор → ст.401 ГК
• Добавлена секция про форму соглашения по ст.452 ГК — критично для РФ (unenforceable если не соблюдена форма)
• Добавлена проверка на государственную регистрацию для договоров, требующих регистрации
• Добавлена секция про ЭДО (Контур.Сайн, СБИС, DiDoc) — российская специфика digital signing
• Privilege inheritance уточнено для РФ (см. stakeholder-summary)
• Матter workspaces убран

Original copyright: © 2026 Anthropic PBC, licensed under Apache License 2.0. Adapted by: ru-legal contributors, 2026-05-17.

---

Disclaimer

Этот skill производит historical analysis. Не legal advice про какая редакция controls в случае conflict. Все ambiguity flags требуют разрешения квалифицированным юристом перед action.

---

⚠ Юридический disclaimer

Данный skill — техническая платформа, не оказывает юридических услуг по ст.2 ФЗ-63 «Об адвокатской деятельности». Outputs не заменяют консультацию лицензированного юриста / адвоката ФПА.

AI может галлюцинировать, выдавать устаревшие нормы, неверно интерпретировать факты. Material decisions (увольнение, M&A, налоговый спор, IP litigation) — обязательно engage outside-адв ФПА с релевантной специализацией.

Проект ru-legal и его contributors не несут ответственности за решения, принятые на основе outputs системы. Использование — на свой риск.