Amendment History

---
name: amendment-history
description: >
  Локализация РФ. Трассировка правок договора: что изменилось между редакциями или
  через допсоглашения — что уступила каждая сторона, не потерялось ли согласованное
  ранее, и не изменила ли правка в одном пункте смысл другого. Используй, когда
  говорят «что изменилось в договоре», «покажи историю правок», «какая редакция
  [пункта] действует сейчас», «пришло допсоглашение», или загружают несколько версий
  договора.
argument-hint: "[базовый договор + допсоглашения | несколько редакций] [--пункт <название>]"
---

<!--
Локализация РФ на основе commercial-legal/skills/amendment-history (anthropics/claude-for-legal,
Apache-2.0). Класс (b) по ADR-002.

Независимое ревью другим провайдером (`codex`/OpenAI) выполнено 2026-08-27 — 1 находка применена:
смягчена категоричность про регистрацию допсоглашения — это не «форма договора» по ст. 452 ГК,
и не каждая правка к зарегистрированному договору подлежит регистрации.
-->

# Трассировка правок договора

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

Проверь `## Ведение дел` в профиле практики и `dela/_sostoyanie.md`. Если режим выключен —
пропусти. Если включён, а активного дела нет — спроси: «По какому делу?
`/vedenie-del:delo pereklyuchit <slug>` или скажите "уровень практики"». Выводы — в папку дела.

## Назначение

К третьему допсоглашению никто не помнит, что было в исходнике и какая редакция пункта
действует сейчас. Скилл читает базовый договор и все допсоглашения по порядку и либо
даёт сводку всех изменений, либо трассирует один пункт через все версии до действующей
редакции. Это историческая справка, а не ревью против плейбука — для ревью действующей
редакции целиком используй `vendor-agreement-review`/`saas-msa-review` отдельно.

## Определи режим

**Режим 1 — сводка всех изменений.** Триггеры: «что изменилось», «история правок», «покажи
изменения», «как выглядит договор сейчас».

**Режим 2 — трассировка пункта.** Триггеры: «где сейчас [пункт]», «как менялась
ответственность/цена/срок», «что сейчас с [условием]».

Если из запроса неясно — один вопрос: «Сводка всех изменений или трассировка одного пункта —
например, ответственности, цены или срока?» Если пункт назван явно — сразу режим 2.

## Шаг 1. Собери, упорядочи и проиндексируй

Прими базовый договор и допсоглашения/приложения/редакции в любом порядке. Установи хронологию
по датам заключения из шапки или преамбулы каждого документа («Дополнительное соглашение № N
от [дата] к Договору № … от …»). Если дат нет ни в файле, ни в тексте, или два документа выглядят
как одна версия — спроси порядок, не угадывай. Затем для каждого документа по порядку зафиксируй:
тип (базовый / допсоглашение № / приложение), дату, стороны (совпадают ли с предыдущими — флагуй
смену стороны или переименование без формальной уступки/перевода долга), перечень явно
изменённых/добавленных/исключённых пунктов. Построй рабочий индекс до вывода, пользователю
не показывай.

## Шаг 2. Проверь формальную сторону каждого допсоглашения

Три проверки, отдельно от сути правок, каждая — со ссылкой на конкретный документ:

- **Форма.** Соглашение об изменении договора совершается в той же форме, что и договор,
  если иное не вытекает из закона, иных правовых актов, договора или обычаев (ст. 452 ГК
  `[проверить формулировку по первоисточнику]`). Если основной договор нотариальный —
  допсоглашение обычно должно повторять нотариальную форму, иначе это дефект. **Регистрация —
  отдельный вопрос, не форма договора в смысле ст. 452 ГК.** Не каждое допсоглашение к
  зарегистрированному договору подлежит обязательной регистрации: это зависит от предмета
  конкретной правки (меняет ли она условие, значимое для третьих лиц или для самого факта
  регистрации — напр. срок или объект в договоре аренды недвижимости) и специального закона,
  регулирующего этот вид договора/объекта. Не пиши категорично «допсоглашение должно быть
  зарегистрировано, иначе дефект» — отметь как вопрос, требующий проверки по специальному закону
  для данного вида договора. `[проверить по специальному закону для вида договора]` [сверено 2026-08-27]
- **Полномочия подписанта.** Тот же критерий, что у основного договора: устав, доверенность,
  ЕГРЮЛ, МЧД, — проверенные на дату конкретного допсоглашения, а не один раз на весь пакет.
- **Дата действия и обратная сила.** С какого момента правки действуют: с даты подписания,
  с даты, указанной отдельно, или задним числом. Обратная сила допустима по соглашению сторон,
  но флагуй её отдельно — она меняет период применения новой редакции и может задеть исполненное.

## Шаг 3. Ищи тихие изменения

Самое дорогое, что теряется при поверхностном чтении, — правка одного пункта, меняющая
смысл другого без его формального изменения. Классический пример: допсоглашение меняет
определение термина (например, «Отчётный период» или «Стоимость услуг») — а лимит
ответственности или порядок расчёта неустойки продолжает ссылаться на этот термин и
меняется вместе с ним, хотя формально его никто не трогал.

**Проверяй перекрёстно:** для каждого изменённого определения или пункта — где ещё в
договоре и допсоглашениях он упомянут или на него сделана отсылка. Если отсылающий пункт
не был явно переоформлен — это не значит, что он не изменился по существу; отметь как
находку с обеими ссылками («§X изменён Допсоглашением N; §Y ссылается на определение из §X
и не переоформлялся — проверить, изменился ли его смысл»).

## Формат вывода — Режим 1 (сводка)

```markdown
# История правок: [Контрагент] — [тип договора]

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

## Что менялось — по порядку

### Допсоглашение N — [дата]
**Формальная проверка:** форма [та же / отличается] · полномочия [проверены/нет] ·
действует с [дата] [обратная сила: да/нет]
**Изменения:** [пункт]: было → стало, простым языком

## Действующая редакция (сводно)

| Пункт | Действующая позиция | Когда и чем изменён |
|---|---|---|
| [пункт] | [суть] | [Допсоглашение N, дата / базовый договор — не менялся] |

## Тихие изменения
[Найденные перекрёстные эффекты — п. «Шаг 3», с обеими ссылками]

## Дефекты формы
[Из «Шаг 2», по документам]
```

## Формат вывода — Режим 2 (трассировка пункта)

Показывай только версии, где пункт менялся; остальные пропускай.

```markdown
# Трассировка: [пункт]
## [Контрагент] — [тип договора]

### Исходная редакция — [дата базового договора]
> «[точная цитата]»

### Допсоглашение N — [дата]
**Было:** «[цитата]» → **Стало:** «[цитата]»
*Смысл изменения:* [одна фраза]

## Действующая редакция
**[документ, дата]**
> «[точная цитата]»

## Тихие изменения по этому пункту
[если определение/пункт, от которого зависит трассируемый, менялся отдельно — см. «Шаг 3»]
```

Если пункт не менялся после базового договора: «Пункт не изменён ни одним допсоглашением.
Действует исходная редакция, [дата], [место в тексте].»

## Ценность для спора — коротко

Хронология правок — не только справка на будущее: она может быть доказательством того, о чём
стороны фактически договаривались, и полезна при толковании неоднозначного условия (ст. 431 ГК).
Следы недобросовестного ведения переговоров между версиями (внезапный отказ от согласованного
без объяснения, затягивание) — область ст. 434.1 ГК; скилл её не разворачивает, только отмечает,
если видна из дат и содержания документов.

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

- Не решает, какой документ имеет приоритет при коллизии между базовым договором и
  допсоглашением — это вопрос юридического толкования. Флагует коллизию и направляет юристу.
- Не готовит проект нового допсоглашения.
- Не сверяет действующую редакцию против плейбука — это `vendor-agreement-review`/
  `saas-msa-review`. Этот скилл — только история.
- Не домысливает смысл неоднозначной правки — цитирует точно и флагует юристу.

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

Заверши деревом опций из `## Выводы` профиля, скорректировав под этот вывод: например
«прогнать действующую редакцию через ревью» (→ `vendor-agreement-review`), «сделать сводку
для бизнеса о том, что изменилось» (→ `stakeholder-summary`).