Проверка договора с поставщиком

Текст

---
name: vendor-agreement-review
description: >
  Справочник: проверка входящего договора с поставщиком по плейбуку команды из
  `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`. Отмечает отклонения, оценивает риск, готовит
  конкретные формулировки правок (redline) и направляет к нужному согласующему.
  Загружается командой /commercial-legal:review, когда обнаружен MSA с поставщиком,
  договор на услуги или подобный документ.
user-invocable: false
---

Проверка договора с поставщиком

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

Контекст дела. Загляни в ## Matter workspaces в CLAUDE.md уровня практики. Если Enabled стоит ✗ (по умолчанию для внутренних юристов компании), пропусти остаток этого абзаца: скиллы используют контекст уровня практики, а механизм дел остаётся невидимым. Если он включён, а активного дела нет, спроси: «Для какого дела это нужно? Запустите /commercial-legal:matter-workspace switch <slug> или скажите practice-level». Загрузи matter.md активного дела: в нём контекст и переопределения для этого дела. Записывай результаты в папку дела ~/.claude/plugins/config/claude-for-legal/commercial-legal/matters/<matter-slug>/. Не читай файлы других дел, если Cross-matter context не равен on.

Проверка адресата

Прежде чем готовить результат, проверь, куда он пойдёт. Если пользователь назвал адресата (канал, список рассылки, контрагента, «всех»), спроси, находится ли он внутри круга привилегии (privilege circle). Публичные каналы, рассылки на всю компанию, контрагент или юрист другой стороны, поставщики и клиенты (для рабочих материалов) снимают защиту. Если адресат выглядит внешним, отметь это и предложи (а) привилегированную версию только для юристов, (б) очищенную версию для более широкого канала или (в) обе версии — не ставь молча привилегированный заголовок, а затем не помогай вставить текст туда, где заголовок его не защитит. См. основной раздел ## Shared guardrails → Destination check в CLAUDE.md этого плагина.

Назначение

Прочитай договор с поставщиком в сравнении с плейбуком, которым эта команда действительно пользуется (он в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md), найди каждое условие, которое от него отклоняется, и скажи юристу, что с каждым делать, — с конкретными формулировками правок, а не расплывчатым «стоит подумать о пересмотре».

Результат — справка по проверке, по которой юрист может действовать за один проход. У каждого вопроса есть степень серьёзности, объяснение влияния на бизнес, предлагаемое исправление и, если нужно, решение об эскалации.

Условие: загрузи плейбук

**Прежде чем читать договор, прочитай ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.** Если его нет или в нём остались незаполненные подстановки, выведи такое сообщение:

Похоже, вы ещё не настроили профиль практики — именно по нему я подстраиваю позиции плейбука, эскалацию и стиль оформления под вашу практику. Два варианта: - Запустите /commercial-legal:cold-start-interview (2 минуты), чтобы настроить профиль, и тогда я проверю договор по ВАШЕМУ плейбуку. - Напишите «provisional», и я проверю по общим настройкам по умолчанию — юрисдикция США, средняя готовность к риску, роль юриста, плейбука нет (отмечу все распространённые риски договоров с поставщиками, исходя из первых принципов) — и помечу каждый результат [PROVISIONAL — configure your profile for tailored output], чтобы вы увидели, что я делаю, прежде чем принимать решение.

Предварительный режим (provisional)

Если пользователь пишет «provisional», проведи проверку как обычно, используя эти общие настройки по умолчанию: средняя готовность к риску, роль юриста, юрисдикция США, плейбука нет (отмечай распространённые риски на стороне поставщика, исходя из первых принципов — неограниченную ответственность, отсутствие исключения для утечки данных, неограниченное возмещение, автопродление без уведомления и т. п., — вместо сопоставления с заданными позициями). Пометь замечание проверяющего и каждый блок находки пометкой [PROVISIONAL]. В конце результата добавь:

«Это был общий прогон по допущениям по умолчанию. Запустите /commercial-legal:cold-start-interview, чтобы получить результат, настроенный под ВАШУ практику — ваш плейбук, вашу юрисдикцию, вашу готовность к риску. 2 минуты».

Какая сторона? Перед применением плейбука определи, на какой стороне в этом договоре находится компания. Обычно это очевидно: если контрагент — поставщик, предоставляющий товары или услуги, ты на стороне закупки. Если контрагент — клиент, покупающий твой продукт или услугу, ты на стороне продаж. Если неочевидно (договор с реселлером, партнёрство, разделение выручки), спроси: «На какой стороне [компания] в этом соглашении — поставщик или заказчик?» Прочитай нужный раздел плейбука (### Sales-side playbook или ### Purchasing-side playbook) в конфигурации. Укажи в результате, какая сторона, чтобы проверяющий знал, какой плейбук применялся. Если для нужной стороны стоит [Not configured], остановись и скажи пользователю запустить /commercial-legal:cold-start-interview --side <side>, без этого проверку продолжать нельзя.

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

Плейбук в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md — источник истины. Он сообщает:

• Каковы стандартные позиции этой команды (не рыночный стандарт, а *их* стандарт)
• Какие запасные варианты они принимали раньше
• Что они не принимают никогда
• Кто что согласует
• Единственный недопустимый пункт (deal-breaker), который проверяется первым

Если в договоре есть deal-breaker, отметь это в начале справки и остановись, не углубляясь в детали. Нет смысла тратить 30 минут на потолки ответственности, если соглашение даёт поставщику право использовать данные клиента для обучения.

Рабочий процесс

Шаг 1: Ориентация

Быстро прочитай соглашение целиком один раз. Ответь:

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

В самом MSA годовая стоимость договора (ACV) не указана. Цена прописана в форме заказа. Ваш порог эскалации — $[X из матрицы]. Прежде чем я направлю договор по маршруту, мне нужна ACV. Варианты: 1. Вставьте сумму из формы заказа (предпочтительно — я использую её для маршрутизации и в справке). 2. Скажите, выше она или ниже $[порог], и я направлю соответственно; в справке будет отмечено, что маршрутизация исходила из [выше/ниже порога] без известной ACV. 3. Направьте осторожно к более высокому согласующему в любом случае — надёжнее для проверки, по которой цена не установлена.

НЕ принимай молча какую-то сумму и не используй принятую сумму для маршрутизации. Допущение перетекает в решение о согласовании, а проверка не должна гадать в этом месте.

Как обращаться с DPA, данным по ссылке. Если основное соглашение включает DPA «доступно по адресу [URL]» или «в редакции по адресу [URL]» или подобным образом по ссылке, DPA входит в договор, но перед тобой его нет. Прямо отметь это в таблице ориентации и в справке по проверке:

Это соглашение включает DPA по ссылке [URL]. В DPA лежат настоящие условия о данных — права на субпроцессоров, сроки уведомления об утечке, механика возврата данных, стандартные договорные положения, права на аудит. Не прочитав его, анализ защиты данных ниже будет неполным. Предложи передать DPA в /privacy-legal:dpa-review (если установлен) для отдельной проверки либо загрузить и прочитать его сразу, прежде чем завершать анализ защиты данных в шаге 3.

Если у пользователя установлен privacy-legal, предложи прямо:

Передать ссылку на DPA в /privacy-legal:dpa-review, когда будете готовы? Этот скилл создан для работы с DPA и поймает вопросы по субпроцессорам / SCC / уведомлению об утечках, которые этот скилл лишь отмечает на входе.

Не продолжай молча так, будто DPA нет, если он включён по ссылке. Отсутствующий DPA и непрочитанный DPA — разные пробелы: обозначай их по-разному.

Шаг 2: Проверка на недопустимый пункт (deal-breaker)

Сначала проверь «главное» из ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Если оно есть:

## ⛔ DEAL-BREAKER PRESENT

**Раздел [X.X]** содержит [недопустимый пункт]. По плейбуку команды это
однозначный отказ. Рекомендация:

- [ ] Возразить — предложить [конкретную альтернативную формулировку]
- [ ] Отказаться — если контрагент не уступит, мы не подписываем

Подробная проверка ниже приводится для полноты, но не имеет смысла, пока это
не решено.

Шаг 3: Сравнение по условиям

По каждой категории плейбука из ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md найди соответствующий раздел договора и сравни.

По каждому отклонению подготовь:

### [Раздел X.X]: [Название вопроса]

**В плейбуке:** [наша стандартная позиция, цитата из `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`]

**В договоре:**
> "[точная цитата из договора]"

**Разрыв:** [Условия нет | Слабее стандарта | Слабее запасного варианта | Нестандартная структура | Неприемлемо]

**Юридический риск:** 🔴 Критичный | 🟠 Высокий | 🟡 Средний | 🟢 Низкий
**Бизнес-трение:** 🔴 Блокирует сделки | 🟠 Замедляет сделки | 🟡 Сбивает клиентов с толку | 🟢 Незаметно

**Почему это важно:** [одно-два предложения простым языком — что пойдёт не так
для бизнеса, если условие останется как есть]

**Предлагаемая правка (redline):**
> "[конкретная формулировка замены — готовая для вставки в разметку]"

**Если они не уступят:** [запасной вариант из `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` или «эскалировать к [человек]»,
если запасного варианта нет]

Калибровка серьёзности:

Серьёзность всегда определяется *по ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md*. Если условие не ложится чётко на позицию плейбука, спроси пользователя, к какой категории его отнести, и предложи записать ответ в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

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

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

1. Прямые и косвенные/сопутствующие убытки. Относится ли потолок ко ВСЕЙ ответственности или только к прямым убыткам? Потолок в 12 месяцев на прямые убытки при неограниченных сопутствующих убытках — совершенно иная позиция, чем общий совокупный потолок в 12 месяцев. Укажи оба режима явно.

1. База потолка — процитируй дословно. «Потолок в 12 месяцев» может означать: (a) платежи, внесённые за 12 месяцев до предъявления требования, (b) платежи, подлежащие уплате в текущем 12-месячном периоде, (c) платежи за последние 12 месяцев использования, (d) платежи по текущей форме заказа, (e) все когда-либо внесённые платежи. Разница может быть на порядок. Процитируй точную формулировку. Если она двусмысленна, отметь: «База потолка неоднозначна — [процитированная формулировка] — может означать [X] или [Y]. Уточните до подписания».

1. Взаимодействие потолка и исключений. Потолок в $100 тыс. при неограниченном возмещении за утечку данных, нарушение прав на ИС и нарушение конфиденциальности фактически не ограничивает те требования, которые реально возникают в SaaS-спорах. Перечисли, что стоит ВЫШЕ потолка (исключения), что НИЖЕ (что реально ограничено), и оцени, насколько значима ограниченная часть: «Потолок охватывает [общее нарушение договора]. Утечка данных, возмещение за нарушение прав на ИС и конфиденциальность выведены из-под потолка и не ограничены. Для профиля рисков этого поставщика ограниченная часть [значима / номинальна]».

1. Позиция плейбука по каждому измерению. В профиле практики должны быть позиции по: прямому потолку (кратность платежей), косвенным убыткам (исключены / ограничены / не ограничены), перечню исключений (что допустимо выше потолка) и базе потолка (какое определение ты принимаешь). Если в плейбуке одно поле «стандартная позиция», отметь: «В вашем плейбуке одна позиция по потолку — рассмотрите разделение на прямые убытки / косвенные убытки / исключения / базу для более точной проверки».

Проверка расхождений в юрисдикциях

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

• Запреты на переманивание сотрудников и конкуренцию (non-solicit/non-compete): не исполняются в Калифорнии (Bus. & Prof. Code §16600). Ограничены во многих юрисдикциях ЕС. В других местах исполнимы с оговорками. [jurisdiction — verify]
• Автопродление: CA GBL §17600-17606, NY GBL §527-a, IL 815 ILCS 601 содержат специальные требования к уведомлению для потребителей и B2B. В других штатах по-разному. [jurisdiction — verify]
• Исключения ответственности: правила ЕС и Великобритании о несправедливых условиях договора (UCTA 1977, Consumer Rights Act 2015) ограничивают исключения для потребителей. Некоторые штаты США ограничивают исключение ответственности за грубую небрежность или умышленные нарушения. [jurisdiction — verify]
• Возмещение убытков: в некоторых штатах возмещение за собственную небрежность возмещаемого недействительно. [jurisdiction — verify]
• Срок конфиденциальности: в некоторых юрисдикциях «бессрочную» конфиденциальность ограничивают разумным периодом. [jurisdiction — verify]

Когда позиция плейбука противоречит исполнимости по применимому праву договора, отметь: «Ваш плейбук предпочитает [X], но этот договор подчиняется праву [Y], где [X] [не исполняется / ограничено / подлежит обязательной норме закона]. [jurisdiction — verify]»

Шаг 4: Выгодные условия и пробелы

Два коротких списка:

Лучше нашего стандарта: условия, по которым поставщик дал нам больше, чем мы попросили бы. Отметь их: это разменная монета, если придётся уступить где-то ещё.

Отсутствует полностью: стандартные положения, которых просто нет. Чаще всего: ограничения на уступку прав, права на аудит (если они нам нужны), форс-мажор, требования к страхованию.

Шаг 5: Маршрутизация эскалации

Сверь матрицу эскалации из ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md со следующим:

• Сумма договора
• Наличие любых критичных вопросов 🔴
• Любые триггеры автоматической эскалации (неограниченная ответственность, передача прав на ИС и т. п.)

Чётко укажи, кто должен это согласовать:

## Маршрут согласования

С учётом [суммы / серьёзности вопросов] это соглашение требует:

- [ ] Согласования **[имя/роль]** — [причина]
- [ ] **Подтверждения владельца со стороны бизнеса** по [конкретному коммерческому условию, по которому ему стоит высказаться]

**Рекомендуемый следующий шаг:** [Отправить правки контрагенту | Эскалировать к главному
юрисконсульту до ответа | Получить мнение бизнеса по коммерческому условию X до ответа юристов]

Прежде чем отправлять правки контрагенту: прочитай ## Who's using this в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Если роль — не юрист:

Отправка правок — юридический акт: контрагент будет считать каждую правку нашей переговорной позицией. Вы показывали это юристу? Если да, продолжайте. Если нет, вот справка, которую стоит принести ему: [Составь сводку на одну страницу: контрагент, тип соглашения, конкретные предлагаемые правки, позиции плейбука за каждой, запасные варианты и что спросить у юриста до отправки пакета.] Если нужно найти юриста (attorney, solicitor, barrister) или другого уполномоченного юридического специалиста: обратитесь в профессиональный регулятор (коллегия адвокатов штата в США, SRA/Bar Standards Board в Англии и Уэльсе, Law Society в Шотландии, Северной Ирландии, Ирландии, Канаде и Австралии или аналог в вашей юрисдикции) — там есть служба рекомендаций.

Не проходи этот барьер без явного «да».

Детализация правок (redline)

Правь на минимально возможном уровне детализации. Redline — это инструмент переговоров, а не переписывание. Полная замена пункта сообщает «мы выбросили вашу редакцию»: это агрессивно, заставляет контрагента перечитывать пункт целиком и отбрасывает те части их текста, которые были в порядке. Точечные правки — вычеркнуть слово, вставить фразу, перестроить подпункт — сообщают «у нас конкретные пожелания» и читаются, понимаются и принимаются быстрее.

По умолчанию делай самую маленькую правку, которая достигает позиции плейбука:

• Сначала заменяй слово, а не фразу. («двенадцати (12)» → «двадцати четырёх (24)»)
• Сначала заменяй фразу, а не предложение. («оплачиваются Покупателем» → «оплачены и подлежат оплате Покупателем»)
• Сначала перестраивай подпункт, а не заменяй предложение. (Добавь «(a)» и «(b)», чтобы разбить составное условие.)
• Сначала заменяй предложение, а не пункт.
• Заменяй пункт целиком только тогда, когда версия контрагента так далека от твоей позиции, что точечные правки читались бы тяжелее нового текста, — и в таком случае скажи об этом в сопроводительном письме: «Мы заменили §8.2 целиком, а не правили его, потому что изменения были обширными. Готовы разобрать разницу вместе с вами».

Сомневаешься — делай меньше. Клиент, получивший точечный redline, верит, что ты читал внимательно. Клиент, получивший полную замену, задумывается, читал ли ты вообще.

Шаг 6: Сборка справки

Поставь в начало заголовок рабочего материала из ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md ## Outputs (он зависит от роли пользователя — см. ## Who's using this).

Эта справка и лежащее в её основе соглашение могут быть привилегированными, конфиденциальными или и тем и другим. Результат наследует этот статус от источника. Распространяй только внутри круга привилегии; маркируй и храни там, где хранятся привилегированные материалы; убирай заголовок рабочего материала перед любой передачей вовне (например, правки для контрагента, краткие изложения для заинтересованных лиц).

Позиции плейбука, применяемые ниже, отражают юрисдикцию, записанную в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → Governing law and venue. Правовые нормы и исполнимость существенно различаются по юрисдикциям. Если сделка затрагивает другое применимое право или вопрос выбора права, отметь это в справке: анализ может не подходить без изменений.

Без тихого дополнения. Если запрос к настроенному инструменту правовых исследований возвращает мало результатов или не возвращает их вовсе по норме, нужной справке (исполнимость пункта об ограничении, объём возмещения убытков, выбор применимого права), сообщи, что найдено, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели, не спросив. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [норма / юрисдикция], похоже, слабое. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент исследования, (3) поискать в интернете: результаты будут помечены [web search — verify], и их нужно сверить с первоисточником, прежде чем полагаться, или (4) отметить как непроверенное и остановиться. Что выберете?» Решать, принимать ли менее надёжные источники, должен юрист. Указание источника. Если в справке цитируется закон, подзаконный акт или судебное дело, помечай цитату: [Westlaw], [statute / regulator site] или названием инструмента MCP для цитат, полученных из коннектора правовых исследований; [web search — verify] для цитат из веб-поиска; [model knowledge — verify] для цитат, восстановленных по памяти из обучающих данных; [user provided] для цитат из проекта контрагента или внутренних файлов. Цитаты с пометкой verify несут повышенный риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай эти пометки.

[ЗАГОЛОВОК РАБОЧЕГО МАТЕРИАЛА — по настройкам плагина ## Outputs]

# Проверка договора с поставщиком: [Контрагент] [Тип соглашения]

**Проверено:** [дата]
**Сумма договора:** $[сумма] / [срок]
**Наша роль:** Заказчик

---

## Вывод

[Два предложения. Можно ли подписывать? Что должно измениться в первую очередь?]

**Вопросы (юридический риск):** [N]🔴 [N]🟠 [N]🟡 [N]🟢
**Вопросы (бизнес-трение):** [N]🔴 [N]🟠 [N]🟡 [N]🟢

**Нужно согласование:** [имя]

---

## Проверка на недопустимый пункт

[✅ Чисто | ⛔ Есть — см. выше]

---

## Вопросы по серьёзности

[Все блоки отклонений из шага 3, сгруппированные от критичных к низким]

---

## Выгодные условия

[список]

## Отсутствующие положения

[список]

---

## Маршрут согласования

[из шага 5]

---

## Пакет правок

[Если запрошено: сводные формулировки, готовые к разметке, по всем предлагаемым изменениям]

Интеграция: [CLM]

Если подключён MCP-сервер [CLM], после проверки:

• Проверь, есть ли у этого контрагента другие соглашения с нами (это может повлиять на переговорную позицию: «в прошлой сделке мы уже согласились на потолок в 24 месяца»)
• Подтяни шаблон рабочего процесса, подходящий этому типу соглашения
• Предложи создать запись в [CLM] с приложенной справкой и заранее направленными согласующими

Интеграция: DocuSign

Если подключён MCP-сервер DocuSign и соглашение готово к подписанию (всё зелёное или все вопросы приняты), предложи:

• Сформировать конверт
• Направить подписантам в правильном порядке по матрице эскалации

Не отправляй ничего на подпись без явного указания. Решать, что «готово к подписанию», должен юрист, а не ты.

Прежде чем формировать конверт на подпись или направлять на встречную подпись: прочитай ## Who's using this в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md. Если роль — не юрист:

У этого шага есть юридические последствия (подписание связывает компанию всем соглашением целиком). Вы показывали это юристу? Если да, продолжайте. Если нет, вот справка, которую стоит принести ему: [Составь сводку на одну страницу: контрагент, сумма договора, найденные вопросы и как они решились, любой риск, принятый юристом, и что спросить у юриста до отправки конверта.] Если нужно найти юриста (attorney, solicitor, barrister) или другого уполномоченного юридического специалиста: обратитесь в профессиональный регулятор (коллегия адвокатов штата в США, SRA/Bar Standards Board в Англии и Уэльсе, Law Society в Шотландии, Северной Ирландии, Ирландии, Канаде и Австралии или аналог в вашей юрисдикции) — там есть служба рекомендаций.

Не проходи этот барьер без явного «да».

Форматы результата

Полная справка (по умолчанию): как выше. Попадает в запись [CLM] или в папку Drive из раздела house style файла ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md.

Краткое изложение размером со Slack-сообщение: две строки и ссылка. Для случая, когда в канале спрашивают «это нормально?».

[Контрагент] [тип] — ТРЕБУЕТ ДОРАБОТКИ. 1🔴 (неограниченная ответственность §8.2), 2🟠. Полная проверка: [ссылка]. Нужно согласование [главного юрисконсульта].

Документ с правками: по просьбе пользователя выдай .docx с отслеживаемыми изменениями. Используй скилл docx. Комментарии к каждой правке ссылаются на позицию плейбука.

Проверки качества перед выдачей

• [ ] ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md загружен и процитирован, а не общие рыночные позиции
• [ ] Недопустимый пункт (deal-breaker) проверен первым
• [ ] У каждого вопроса есть конкретная формулировка замены
• [ ] Уровни риска откалиброваны (не всё критично)
• [ ] Согласующий назван по имени, а не «эскалировать юристам»
• [ ] Учтён контекст контрагента (крупная корпорация или стартап — от этого зависит, за что стоит бороться)

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

Закончи деревом следующих шагов по CLAUDE.md ## Outputs. Подгони варианты под то, что только что выдал этот скилл: пять стандартных веток (подготовить X, эскалировать, получить больше фактов, ждать и наблюдать, что-то другое) — это отправная точка, а не жёсткая рамка. Дерево и есть результат; выбирает юрист.

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