Трекер продлений договоров

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

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

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

Что делает: Ведёт реестр договоров с автопродлением и предупреждает, до какого дня нужно успеть отказаться, чтобы не пропустить окно.
Когда брать: Когда нужно узнать, какие договоры скоро продлятся, не пропущен ли срок отказа, или добавить новый договор в реестр продлений.
Когда не брать: Если нужно найти даты продления в самом тексте договора: скилл их не ищет, их заносят при проверке договора.
Пример запроса: Что у нас продлевается в ближайшие 90 дней и до какого числа нужно отказаться?
Работает лучше с: система управления договорами (CLM), DocuSign

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

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку renewal-tracker в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: renewal-tracker
description: >
  Показывай договоры с приближающимися сроками отказа от продления и предупреждай до закрытия окна уведомления,
  опираясь на ведущийся реестр продлений. Используй, когда пользователь спрашивает «что скоро продлевается»,
  «какие продления на подходе», «не пропустили ли мы окно отказа», «добавь это в трекер продлений», а также
  по расписанию. Принимает передачу данных от saas-msa-review.
argument-hint: "[--days N to change window | --missed for lapsed windows]"
---

/renewal-tracker

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

Инструкции

**Прочитай ~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml** (папка конфигурации: она переживает обновления плагина).

Режим по умолчанию: режим 2 — что наступает в ближайшие 90 дней, с группировкой по срочности. Используются полуоткрытые интервалы, чтобы каждый срок попал ровно в одну полосу: 🔴 0–13 дней, 🟠 14–44 дня, 🟡 45–89 дней. Дни 14, 45 и 90 — границы: каждый относится ровно к одной полосе, а не к двум.

**--days N:** изменить окно.

**--missed:** режим 4 — сроки отказа, которые прошли без зафиксированного отказа.

Если реестр пуст и подключена система [CLM]: предложи режим 3 — просканировать [CLM] на действующие соглашения с датами продления и загрузить их в реестр одним пакетом.

В результат входят рекомендуемые действия: кому написать (владельцу со стороны бизнеса из каждой записи реестра) и у каких договоров цена не ограничена (нужно успеть выбить уступки до закрытия окна).

Примеры

/commercial-legal:renewal-tracker

/commercial-legal:renewal-tracker --days 180

/commercial-legal:renewal-tracker --missed

Назначение

Договор никто не читает дважды. Дата продления извлекается один раз, при проверке договора, а потом живёт где-то ещё — в идеале там, где о ней напомнят за 45 дней до срока отказа, а не через 45 дней после.

Этот скилл ведёт реестр продлений и показывает, что на подходе.

Реестр

Лежит в ~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml (папка конфигурации: она переживает обновления плагина). Каждая запись:

- counterparty: "Acme SaaS Inc."
  agreement: "Acme Platform Subscription Agreement"
  signed_date: 2025-06-15
  initial_term_end: 2026-06-15
  current_term_end: 2026-06-15     # rolls forward after each auto-renewal; compute cancel_by_* from this
  renewal_mechanism: "auto-renew annual"
  notice_period_days: 60
  notice_method: "email"           # email / portal / certified mail / registered post / courier / per contract §X
  transit_buffer_days: 0           # 0 for electronic, 5 for domestic certified mail, 10 for international registered post — or per contract if specified
  cancel_by_calendar: 2026-04-16    # current_term_end minus notice_period_days
  cancel_by_effective: 2026-04-16   # rolled back to last business day if needed
  send_by_effective: 2026-04-16    # cancel_by_effective minus transit_buffer_days — the date you must SEND the notice
  cancel_by_roll_note: ""           # e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"
  cancel_by_provenance: "[model calculation — verify against the notice clause]"
  price_on_renewal: "then-current list (uncapped)"
  annual_value: 48000
  business_owner: "jane@company.com"
  clm_id:        "IC-12345"        # if connected
  docusign_envelope: "abc-123"   # if connected
  status: "active"               # active | cancelled | renewed | lapsed
  notes: "Pricing uncapped — revisit before renewal. Alt vendors: X, Y."

**Время доставки уведомления — отсчитывай оповещения от send_by_effective, а не от cancel_by_effective.** Окно в 60 дней при требовании заказного письма на деле составляет около 55 дней. Трекер, который оповещает по дате получения, — это трекер, который пропускает срок. Вычисляй send_by_effective = cancel_by_effective - transit_buffer_days и запускай оповещения (полосы срочности 🔴 / 🟠 / 🟡 в режиме 2) по send_by_effective. В столбце срочности режима 2 показывается send_by_effective, а в столбце с подробностями — cancel_by_effective, notice_method и transit_buffer_days, чтобы читатель видел разницу и мог оспорить запас времени.

Продления по кругу: реестр, который не сдвигается вперёд, верен только один раз. Храни initial_term_end для истории, но вычисляй cancel_by_* от current_term_end. Когда продление сработало (окно отказа прошло, уведомления не было), спроси:

Этот договор автоматически продлился [дата]. Обновить реестр: новый current_term_end — [дата + срок продления], новый cancel_by_effective — [вычисленная дата], новый send_by_effective — [вычисленная дата]. Подтверждаете?

После первого года initial_term_end уже неверен, и правильную дату отказа даёт только current_term_end.

Проверка рабочего дня для каждой даты отказа

Дата отказа в реестре должна быть последним РАБОЧИМ днём, когда уведомление ещё действует, а не календарной датой. Календарная дата, выпавшая на выходной, — самая частая причина пропущенного срока продления. Реестр ловит это заранее.

Когда ты вычисляешь (или загружаешь) дату отказа:

Вычисли календарную дату. cancel_by_calendar = initial_term_end − notice_period_days (или как сказано в пункте договора). Это чистая арифметика.
Сдвиг назад до рабочего дня по применимому праву. Применимое право договора определяет, какие праздники учитываются. США: федеральные праздники плюс праздники штата, если применимо право штата. Англия и Уэльс: банковские праздники. Германия: Feiertage (различаются по землям — спроси, по какой). Канада: федеральные плюс провинциальные. Сингапур: государственные праздники. Если суббота — сдвинь назад на пятницу. Если воскресенье — сдвинь назад на пятницу. Если праздник в юрисдикции применимого права — сдвинь на предыдущий рабочий день. Сдвигай НАЗАД, никогда не вперёд: сдвиг вперёд означает, что уведомление придёт после закрытия окна. Если применимое право не американское и ты не можешь определить календарь праздников, отметь это: «Применимое право — [X]; сдвиг до рабочего дня сделан по федеральным праздникам США как временная замена. Прежде чем полагаться на эффективную дату, сверьте её с календарём праздников в юрисдикции [название]».
Проверь правило подсчёта дней в самом договоре. Ищи «business day» (рабочий день), «received by» (получено до), «deemed received» (считается полученным), «5:00 p.m. [местное время]» или пункт о способе уведомления. Если договор определяет «рабочий день» или задаёт порядок получения (заказное письмо, электронная почта с уведомлением о прочтении), то решает это определение. Отметь любое расхождение между стандартным сдвигом и правилом самого договора.
Запиши в реестр ОБЕ даты. cancel_by_calendar — чистая арифметика; cancel_by_effective — последний рабочий день, когда уведомление действует; cancel_by_roll_note объясняет, почему они различаются (например, «сдвинуто назад с воскресенья 2026-11-01; сверь с определением рабочего дня в договоре»). Каждая вычисленная cancel_by_effective несёт метку cancel_by_provenance со значением [model calculation — verify against the notice clause], чтобы пометка «проверить» ехала вместе с датой, а не с окружающим текстом.
Запускай оповещения от ЭФФЕКТИВНОЙ даты, а не от календарной. Полосы срочности (🔴 / 🟠 / 🟡 в режиме 2) считаются по cancel_by_effective. В результате режима 2 cancel_by_effective стоит в столбце срочности, а cancel_by_calendar и cancel_by_roll_note выводятся в столбце с подробностями там, где был сдвиг назад, чтобы читатель это видел и мог оспорить.

Отчёт режима 2, который печатает cancel_by: 2026-11-01 (воскресенье) без дня недели и без предупреждения, — это молча неверный эффективный срок. Ловить такое нужно в реестре, один раз, при загрузке, а не позже, когда окно уже сдвинулось.

Режимы

Режим 1: загрузка продления (передача данных из проверки)

Когда saas-msa-review или vendor-agreement-review находит пункт о продлении, он передаёт запись. Добавь её в реестр. Если у контрагента уже есть запись, спроси, это замена (продлённое соглашение) или дополнительное соглашение.

Режим 2: что на подходе

Окно просмотра по умолчанию: ближайшие 90 дней.

Полосы срочности — полуоткрытые интервалы: срок живёт ровно в одной полосе. Считай число дней до срока отказа (cancel_by_effective - today). Дни 14, 45 и 90 относятся ровно к одной полосе, а не к двум; ошибка на единицу кладёт самые срочные пункты в менее срочную корзину.

🔴 0–13 дней (срок отказа меньше чем через 14 дней, включая сегодня)
🟠 14–44 дня
🟡 45–89 дней
(всё, что дальше 90 дней, лежит за пределами окна по умолчанию; включай только если пользователь передал --horizon больше 90)

## Продления — ближайшие 90 дней

### 🔴 Срок отказа через 0–13 дней

| Контрагент | Отказаться до | Дата продления | Годовая сумма, $ | Владелец | Примечания |
|---|---|---|---|---|---|
| [название] | **[дата]** | [дата] | $[n] | [email] | [примечания] |

### 🟠 Срок отказа через 14–44 дня

[та же таблица]

### 🟡 Срок отказа через 45–89 дней

[та же таблица]

---

**Рекомендуемые действия:**
- [ ] [Контрагент] — написать [владельцу со стороны бизнеса]: нужен ли нам этот договор?
- [ ] [Контрагент] — цена не ограничена; получи предложение от альтернативного поставщика, пока мы не потеряли рычаг

Если в окне больше ~10 продлений, а также в любой момент по просьбе пользователя: предложи дашборд (см. CLAUDE.md, ## Outputs → Dashboard offer for data-heavy outputs). Подгони предложение под этот результат — число записей по уровням срочности (🔴 / 🟠 / 🟡), шкала сроков отказа и сортируемый реестр с контрагентом, датой продления, годовой суммой в $ и владельцем.

Режим 3: просканировать [CLM] / инструмент электронной подписи и заполнить реестр

Если подключены MCP-серверы, а реестр пуст или устарел:

Запроси в [CLM] все соглашения со статусом «Active» и полем даты продления
Запроси в DocuSign завершённые конверты за последние 24 месяца со словами «subscription» / «renewal» / «auto-renew» в метаданных
По каждому найденному вычлени условия продления и добавь в реестр
Отметь все, где дату продления нельзя определить по метаданным: их должен прочитать человек

Это разовая массовая загрузка. Дальше загрузка идёт во время проверки договоров.

Режим 4: пропущенные окна (отчёт с плохими новостями)

## Пропущенные окна отказа

По следующим соглашениям срок отказа прошёл, а отказ не был
зафиксирован:

| Контрагент | Срок отказа был | Дата продления | Статус |
|---|---|---|---|
| [название] | [дата] | [дата] | Будет продлено автоматически [дата] |

**Варианты:**
- Договориться об отказе с опозданием (редко срабатывает, но спросить стоит)
- Принять продление и сразу отметить срок отказа на следующий год
- Проверить, нет ли в соглашении других прав на расторжение (по удобству, по причине)

Барьер: принятие или отклонение продления

Отслеживание даты продления — это изучение. А *действие* по ней — отправка уведомления об отказе от продления, пропуск автоматического продления или подписание формы продления — это значимый юридический шаг.

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

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

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

Интеграция: агент renewal-watcher

Агент renewal-watcher из этого плагина запускает скилл по расписанию (по умолчанию раз в неделю) и публикует отчёт «что на подходе» в канал, указанный в ~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md → ## House style → куда отправлять рабочие материалы. Режим 2 — основной результат агента.

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

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

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

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

---
name: renewal-tracker
description: >
  Show contracts with cancel-by deadlines coming up and warn before notice windows
  close, working from a maintained renewal register. Use when the user asks "what's
  renewing soon", "what renewals are due", "did we miss a cancellation window", "add
  this to the renewal tracker", or on a scheduled basis. Receives handoffs from
  saas-msa-review.
argument-hint: "[--days N to change window | --missed for lapsed windows]"
---

# /renewal-tracker

Surfaces what's renewing and when you have to cancel by.

## Instructions

1. **Read `~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml`** (the config directory — survives plugin updates).

2. **Default mode:** Mode 2 — what's coming up in the next 90 days, grouped by urgency using half-open intervals so each deadline lands in exactly one band: 🔴 0–13 days, 🟠 14–44 days, 🟡 45–89 days. Days 14, 45, and 90 are boundaries — each belongs to exactly one band, not two.

3. **`--days N`:** Change the window.

4. **`--missed`:** Mode 4 — cancel-by deadlines that passed without recorded cancellation.

5. **If register is empty and the [CLM] is connected:** Offer Mode 3 — scan the [CLM] for active agreements with renewal dates and bulk-load.

6. **Output includes recommended actions:** who to ping (the business owner from each register entry), which ones have uncapped pricing (get leverage before window closes).

## Examples

```
/commercial-legal:renewal-tracker
```

```
/commercial-legal:renewal-tracker --days 180
```

```
/commercial-legal:renewal-tracker --missed
```

---

## Purpose

Nobody reads a contract twice. The renewal date is extracted once, at review time, and then it lives somewhere — ideally somewhere that shouts at you 45 days before the cancel-by deadline, not 45 days after.

This skill maintains the renewal register and surfaces what's coming.

## The register

Lives at `~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml` (the config directory — survives plugin updates). Each entry:

```yaml
- counterparty: "Acme SaaS Inc."
  agreement: "Acme Platform Subscription Agreement"
  signed_date: 2025-06-15
  initial_term_end: 2026-06-15
  current_term_end: 2026-06-15     # rolls forward after each auto-renewal; compute cancel_by_* from this
  renewal_mechanism: "auto-renew annual"
  notice_period_days: 60
  notice_method: "email"           # email / portal / certified mail / registered post / courier / per contract §X
  transit_buffer_days: 0           # 0 for electronic, 5 for domestic certified mail, 10 for international registered post — or per contract if specified
  cancel_by_calendar: 2026-04-16    # current_term_end minus notice_period_days
  cancel_by_effective: 2026-04-16   # rolled back to last business day if needed
  send_by_effective: 2026-04-16    # cancel_by_effective minus transit_buffer_days — the date you must SEND the notice
  cancel_by_roll_note: ""           # e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"
  cancel_by_provenance: "[model calculation — verify against the notice clause]"
  price_on_renewal: "then-current list (uncapped)"
  annual_value: 48000
  business_owner: "jane@company.com"
  clm_id:        "IC-12345"        # if connected
  docusign_envelope: "abc-123"   # if connected
  status: "active"               # active | cancelled | renewed | lapsed
  notes: "Pricing uncapped — revisit before renewal. Alt vendors: X, Y."
```

**Notice transit time — alert off `send_by_effective`, not `cancel_by_effective`.** A 60-day window with a certified-mail requirement is really ~55 days. The tracker that alerts on the received-by date is the tracker that misses the deadline. Compute `send_by_effective = cancel_by_effective - transit_buffer_days` and fire alerts (the 🔴 / 🟠 / 🟡 urgency bands in Mode 2) off `send_by_effective`. Mode 2's urgency column shows `send_by_effective`; a detail column surfaces `cancel_by_effective`, `notice_method`, and `transit_buffer_days` so the reader can see the delta and challenge the buffer.

**Rolling renewals — the register that doesn't roll forward is the register that's right once.** Store `initial_term_end` for the record, but compute `cancel_by_*` from `current_term_end`. When a renewal fires (the cancel window passes and no notice was given), prompt:

> This contract auto-renewed on [date]. Update the register: new `current_term_end` is [date + renewal period], new `cancel_by_effective` is [computed], new `send_by_effective` is [computed]. Confirm?

After year one, `initial_term_end` is wrong and only `current_term_end` produces a correct cancel-by date.

## Business-day check on every cancel-by date

**The register's cancel-by date must be the last BUSINESS DAY on which notice
is effective, not the calendar date.** A calendar date that falls on a
weekend is the single most common way a renewal deadline gets missed. The
register catches it.

When you compute (or ingest) a cancel-by date:

1. **Compute the calendar date.** `cancel_by_calendar = initial_term_end − notice_period_days` (or whatever the clause specifies). This is the raw arithmetic.
2. **Business-day roll-back keyed to governing law.** The contract's governing law determines which holidays count. US: federal holidays + the state's holidays if governing law is a state. England & Wales: bank holidays. Germany: Feiertage (vary by Bundesland — ask which). Canada: federal + provincial. Singapore: public holidays. If Saturday, roll back to Friday. If Sunday, roll back to Friday. If a holiday in the governing-law jurisdiction, roll back to the prior business day. Roll BACK, never forward — forward means notice arrives after the window closes. For non-US governing law, if you can't determine the holiday calendar, flag it: "Governing law is [X] — business-day roll-back uses US federal holidays as a placeholder. Verify against the [jurisdiction] holiday calendar before relying on the effective date."
3. **Check the contract's own day-counting rule.** Look for "business day," "received by," "deemed received," "5:00 p.m. [local time]," or a notice-method clause. If the contract defines "business day" or specifies receipt mechanics (certified mail, email with read receipt), that definition controls. Flag any mismatch between the default roll-back and the contract's own rule.
4. **Record BOTH dates in the register.** `cancel_by_calendar` is the raw arithmetic; `cancel_by_effective` is the last business day on which notice is effective; `cancel_by_roll_note` records why they differ (e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"). Every computed `cancel_by_effective` carries a `cancel_by_provenance` tag of `[model calculation — verify against the notice clause]` so the verify flag travels with the date, not with the surrounding prose.
5. **Fire alerts off the EFFECTIVE date, not the calendar date.** Urgency bands (🔴 / 🟠 / 🟡 in Mode 2) use `cancel_by_effective`. Mode 2 output shows `cancel_by_effective` in the urgency column and surfaces `cancel_by_calendar` and `cancel_by_roll_note` in a detail column where the roll-back happened, so the reader can see it and challenge it.

A Mode 2 report that prints `cancel_by: 2026-11-01` (a Sunday) with no weekday and no warning is a silently wrong effective deadline. The register is the place to catch it — once, at ingest — not later, when the window has already moved.

## Modes

### Mode 1: Ingest a renewal (handoff from review)

When saas-msa-review or vendor-agreement-review finds a renewal clause, it hands off a record. Append it to the register. If the counterparty already has an entry, ask whether this is a replacement (renewed agreement) or an additional agreement.

### Mode 2: What's coming up

**Default lookback window:** next 90 days.

**Urgency bands are half-open intervals — a deadline lives in exactly one band.** Use days-until-cancel-by (`cancel_by_effective - today`). Day 14, 45, and 90 each belong to exactly one band, not two; an off-by-one here puts the most-urgent items into the less-urgent bucket.

- 🔴 **0–13 days** (cancel-by in less than 14 days — including today)
- 🟠 **14–44 days**
- 🟡 **45–89 days**
- (everything 90+ days is outside the default lookback window; include only if the user passed `--horizon` beyond 90)

```markdown
## Renewals — next 90 days

### 🔴 Cancel-by deadline in 0–13 days

| Counterparty | Cancel by | Renewal date | Annual $ | Owner | Notes |
|---|---|---|---|---|---|
| [name] | **[date]** | [date] | $[n] | [email] | [notes] |

### 🟠 Cancel-by deadline in 14–44 days

[same table]

### 🟡 Cancel-by deadline in 45–89 days

[same table]

---

**Recommended actions:**
- [ ] [Counterparty] — ping [business owner]: do we want to keep this?
- [ ] [Counterparty] — pricing is uncapped; get a quote from an alternative before we lose leverage
```

If the register has more than ~10 renewals in the window, or any time the user asks: offer the dashboard (see CLAUDE.md `## Outputs → Dashboard offer for data-heavy outputs`). Shape the offer for this output — counts by urgency tier (🔴 / 🟠 / 🟡), a cancel-by timeline, and a sortable register with counterparty, renewal date, annual $, and owner.

### Mode 3: Scan the [CLM] / e-signature tool to populate the register

If MCPs are connected and the register is empty or stale:

1. Query the [CLM] for all agreements with status "Active" and a renewal date field
2. Query DocuSign for completed envelopes in the last 24 months with "subscription" / "renewal" / "auto-renew" in metadata
3. For each hit, extract renewal mechanics and add to register
4. Flag any where the renewal date can't be determined from metadata — those need a human to read the contract

This is a one-time bulk load. After that, ingest happens at review time.

### Mode 4: Missed windows (the bad news report)

```markdown
## Missed cancellation windows

The following agreements had cancel-by deadlines that have passed and no
cancellation was recorded:

| Counterparty | Cancel-by was | Renewal date | Status |
|---|---|---|---|
| [name] | [date] | [date] | Will auto-renew on [date] |

**Options:**
- Negotiate late cancellation (rarely works but worth asking)
- Accept the renewal, mark next year's cancel-by now
- Check the agreement for any other termination rights (for convenience, for cause)
```

## Gate: accepting or declining a renewal

Tracking a renewal date is research. *Acting* on it — sending a notice of non-renewal, letting an auto-renewal fire, or countersigning a renewal form — is a consequential legal step.

**Before proceeding to accept or decline a renewal (including sending a non-renewal notice or letting an auto-renewal run past the cancel-by date):** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md`. If the Role is Non-lawyer:

> This step has legal consequences (you're either committing to another term or terminating the relationship). Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
>
> [Generate a 1-page summary: counterparty, current term end and cancel-by date, renewal price mechanism, what happens if we do nothing, alternative vendors if we want to shop, and the three things to ask the attorney before the window closes.]
>
> If you need to find an attorney, solicitor, barrister, or other authorised legal professional: contact your professional regulator (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent) for a referral service.

Do not proceed past this gate without an explicit yes.

## Integration: renewal-watcher agent

The renewal-watcher agent in this plugin runs this skill on a schedule (weekly by default) and posts the "coming up" report to the channel named in `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` → `## House style` → where work product goes. Mode 2 is the agent's primary output.

## What this skill does not do

- It does not cancel contracts. It tells you when to decide.
- It does not decide whether to renew. It surfaces the deadline and the business owner.
- It does not read contracts to find renewal dates — that happens at review time. If a contract is in the register without a renewal date, it was added manually and someone needs to fill in the gap.

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

---
name: renewal-tracker
description: >
  Показывай договоры с приближающимися сроками отказа от продления и предупреждай до закрытия окна уведомления,
  опираясь на ведущийся реестр продлений. Используй, когда пользователь спрашивает «что скоро продлевается»,
  «какие продления на подходе», «не пропустили ли мы окно отказа», «добавь это в трекер продлений», а также
  по расписанию. Принимает передачу данных от saas-msa-review.
argument-hint: "[--days N to change window | --missed for lapsed windows]"
---

# /renewal-tracker

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

## Инструкции

1. **Прочитай `~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml`** (папка конфигурации: она переживает обновления плагина).

2. **Режим по умолчанию:** режим 2 — что наступает в ближайшие 90 дней, с группировкой по срочности. Используются полуоткрытые интервалы, чтобы каждый срок попал ровно в одну полосу: 🔴 0–13 дней, 🟠 14–44 дня, 🟡 45–89 дней. Дни 14, 45 и 90 — границы: каждый относится ровно к одной полосе, а не к двум.

3. **`--days N`:** изменить окно.

4. **`--missed`:** режим 4 — сроки отказа, которые прошли без зафиксированного отказа.

5. **Если реестр пуст и подключена система [CLM]:** предложи режим 3 — просканировать [CLM] на действующие соглашения с датами продления и загрузить их в реестр одним пакетом.

6. **В результат входят рекомендуемые действия:** кому написать (владельцу со стороны бизнеса из каждой записи реестра) и у каких договоров цена не ограничена (нужно успеть выбить уступки до закрытия окна).

## Примеры

```
/commercial-legal:renewal-tracker
```

```
/commercial-legal:renewal-tracker --days 180
```

```
/commercial-legal:renewal-tracker --missed
```

---

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

Договор никто не читает дважды. Дата продления извлекается один раз, при проверке договора, а потом живёт где-то ещё — в идеале там, где о ней напомнят за 45 дней до срока отказа, а не через 45 дней после.

Этот скилл ведёт реестр продлений и показывает, что на подходе.

## Реестр

Лежит в `~/.claude/plugins/config/claude-for-legal/commercial-legal/renewal-register.yaml` (папка конфигурации: она переживает обновления плагина). Каждая запись:

```yaml
- counterparty: "Acme SaaS Inc."
  agreement: "Acme Platform Subscription Agreement"
  signed_date: 2025-06-15
  initial_term_end: 2026-06-15
  current_term_end: 2026-06-15     # rolls forward after each auto-renewal; compute cancel_by_* from this
  renewal_mechanism: "auto-renew annual"
  notice_period_days: 60
  notice_method: "email"           # email / portal / certified mail / registered post / courier / per contract §X
  transit_buffer_days: 0           # 0 for electronic, 5 for domestic certified mail, 10 for international registered post — or per contract if specified
  cancel_by_calendar: 2026-04-16    # current_term_end minus notice_period_days
  cancel_by_effective: 2026-04-16   # rolled back to last business day if needed
  send_by_effective: 2026-04-16    # cancel_by_effective minus transit_buffer_days — the date you must SEND the notice
  cancel_by_roll_note: ""           # e.g., "rolled back from Sunday 2026-11-01; verify against contract's business-day definition"
  cancel_by_provenance: "[model calculation — verify against the notice clause]"
  price_on_renewal: "then-current list (uncapped)"
  annual_value: 48000
  business_owner: "jane@company.com"
  clm_id:        "IC-12345"        # if connected
  docusign_envelope: "abc-123"   # if connected
  status: "active"               # active | cancelled | renewed | lapsed
  notes: "Pricing uncapped — revisit before renewal. Alt vendors: X, Y."
```

**Время доставки уведомления — отсчитывай оповещения от `send_by_effective`, а не от `cancel_by_effective`.** Окно в 60 дней при требовании заказного письма на деле составляет около 55 дней. Трекер, который оповещает по дате получения, — это трекер, который пропускает срок. Вычисляй `send_by_effective = cancel_by_effective - transit_buffer_days` и запускай оповещения (полосы срочности 🔴 / 🟠 / 🟡 в режиме 2) по `send_by_effective`. В столбце срочности режима 2 показывается `send_by_effective`, а в столбце с подробностями — `cancel_by_effective`, `notice_method` и `transit_buffer_days`, чтобы читатель видел разницу и мог оспорить запас времени.

**Продления по кругу: реестр, который не сдвигается вперёд, верен только один раз.** Храни `initial_term_end` для истории, но вычисляй `cancel_by_*` от `current_term_end`. Когда продление сработало (окно отказа прошло, уведомления не было), спроси:

> Этот договор автоматически продлился [дата]. Обновить реестр: новый `current_term_end` — [дата + срок продления], новый `cancel_by_effective` — [вычисленная дата], новый `send_by_effective` — [вычисленная дата]. Подтверждаете?

После первого года `initial_term_end` уже неверен, и правильную дату отказа даёт только `current_term_end`.

## Проверка рабочего дня для каждой даты отказа

**Дата отказа в реестре должна быть последним РАБОЧИМ днём, когда уведомление ещё
действует, а не календарной датой.** Календарная дата, выпавшая на выходной, —
самая частая причина пропущенного срока продления. Реестр ловит это заранее.

Когда ты вычисляешь (или загружаешь) дату отказа:

1. **Вычисли календарную дату.** `cancel_by_calendar = initial_term_end − notice_period_days` (или как сказано в пункте договора). Это чистая арифметика.
2. **Сдвиг назад до рабочего дня по применимому праву.** Применимое право договора определяет, какие праздники учитываются. США: федеральные праздники плюс праздники штата, если применимо право штата. Англия и Уэльс: банковские праздники. Германия: Feiertage (различаются по землям — спроси, по какой). Канада: федеральные плюс провинциальные. Сингапур: государственные праздники. Если суббота — сдвинь назад на пятницу. Если воскресенье — сдвинь назад на пятницу. Если праздник в юрисдикции применимого права — сдвинь на предыдущий рабочий день. Сдвигай НАЗАД, никогда не вперёд: сдвиг вперёд означает, что уведомление придёт после закрытия окна. Если применимое право не американское и ты не можешь определить календарь праздников, отметь это: «Применимое право — [X]; сдвиг до рабочего дня сделан по федеральным праздникам США как временная замена. Прежде чем полагаться на эффективную дату, сверьте её с календарём праздников в юрисдикции [название]».
3. **Проверь правило подсчёта дней в самом договоре.** Ищи «business day» (рабочий день), «received by» (получено до), «deemed received» (считается полученным), «5:00 p.m. [местное время]» или пункт о способе уведомления. Если договор определяет «рабочий день» или задаёт порядок получения (заказное письмо, электронная почта с уведомлением о прочтении), то решает это определение. Отметь любое расхождение между стандартным сдвигом и правилом самого договора.
4. **Запиши в реестр ОБЕ даты.** `cancel_by_calendar` — чистая арифметика; `cancel_by_effective` — последний рабочий день, когда уведомление действует; `cancel_by_roll_note` объясняет, почему они различаются (например, «сдвинуто назад с воскресенья 2026-11-01; сверь с определением рабочего дня в договоре»). Каждая вычисленная `cancel_by_effective` несёт метку `cancel_by_provenance` со значением `[model calculation — verify against the notice clause]`, чтобы пометка «проверить» ехала вместе с датой, а не с окружающим текстом.
5. **Запускай оповещения от ЭФФЕКТИВНОЙ даты, а не от календарной.** Полосы срочности (🔴 / 🟠 / 🟡 в режиме 2) считаются по `cancel_by_effective`. В результате режима 2 `cancel_by_effective` стоит в столбце срочности, а `cancel_by_calendar` и `cancel_by_roll_note` выводятся в столбце с подробностями там, где был сдвиг назад, чтобы читатель это видел и мог оспорить.

Отчёт режима 2, который печатает `cancel_by: 2026-11-01` (воскресенье) без дня недели и без предупреждения, — это молча неверный эффективный срок. Ловить такое нужно в реестре, один раз, при загрузке, а не позже, когда окно уже сдвинулось.

## Режимы

### Режим 1: загрузка продления (передача данных из проверки)

Когда saas-msa-review или vendor-agreement-review находит пункт о продлении, он передаёт запись. Добавь её в реестр. Если у контрагента уже есть запись, спроси, это замена (продлённое соглашение) или дополнительное соглашение.

### Режим 2: что на подходе

**Окно просмотра по умолчанию:** ближайшие 90 дней.

**Полосы срочности — полуоткрытые интервалы: срок живёт ровно в одной полосе.** Считай число дней до срока отказа (`cancel_by_effective - today`). Дни 14, 45 и 90 относятся ровно к одной полосе, а не к двум; ошибка на единицу кладёт самые срочные пункты в менее срочную корзину.

- 🔴 **0–13 дней** (срок отказа меньше чем через 14 дней, включая сегодня)
- 🟠 **14–44 дня**
- 🟡 **45–89 дней**
- (всё, что дальше 90 дней, лежит за пределами окна по умолчанию; включай только если пользователь передал `--horizon` больше 90)

```markdown
## Продления — ближайшие 90 дней

### 🔴 Срок отказа через 0–13 дней

| Контрагент | Отказаться до | Дата продления | Годовая сумма, $ | Владелец | Примечания |
|---|---|---|---|---|---|
| [название] | **[дата]** | [дата] | $[n] | [email] | [примечания] |

### 🟠 Срок отказа через 14–44 дня

[та же таблица]

### 🟡 Срок отказа через 45–89 дней

[та же таблица]

---

**Рекомендуемые действия:**
- [ ] [Контрагент] — написать [владельцу со стороны бизнеса]: нужен ли нам этот договор?
- [ ] [Контрагент] — цена не ограничена; получи предложение от альтернативного поставщика, пока мы не потеряли рычаг
```

Если в окне больше ~10 продлений, а также в любой момент по просьбе пользователя: предложи дашборд (см. CLAUDE.md, `## Outputs → Dashboard offer for data-heavy outputs`). Подгони предложение под этот результат — число записей по уровням срочности (🔴 / 🟠 / 🟡), шкала сроков отказа и сортируемый реестр с контрагентом, датой продления, годовой суммой в $ и владельцем.

### Режим 3: просканировать [CLM] / инструмент электронной подписи и заполнить реестр

Если подключены MCP-серверы, а реестр пуст или устарел:

1. Запроси в [CLM] все соглашения со статусом «Active» и полем даты продления
2. Запроси в DocuSign завершённые конверты за последние 24 месяца со словами «subscription» / «renewal» / «auto-renew» в метаданных
3. По каждому найденному вычлени условия продления и добавь в реестр
4. Отметь все, где дату продления нельзя определить по метаданным: их должен прочитать человек

Это разовая массовая загрузка. Дальше загрузка идёт во время проверки договоров.

### Режим 4: пропущенные окна (отчёт с плохими новостями)

```markdown
## Пропущенные окна отказа

По следующим соглашениям срок отказа прошёл, а отказ не был
зафиксирован:

| Контрагент | Срок отказа был | Дата продления | Статус |
|---|---|---|---|
| [название] | [дата] | [дата] | Будет продлено автоматически [дата] |

**Варианты:**
- Договориться об отказе с опозданием (редко срабатывает, но спросить стоит)
- Принять продление и сразу отметить срок отказа на следующий год
- Проверить, нет ли в соглашении других прав на расторжение (по удобству, по причине)
```

## Барьер: принятие или отклонение продления

Отслеживание даты продления — это изучение. А *действие* по ней — отправка уведомления об отказе от продления, пропуск автоматического продления или подписание формы продления — это значимый юридический шаг.

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

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

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

## Интеграция: агент renewal-watcher

Агент renewal-watcher из этого плагина запускает скилл по расписанию (по умолчанию раз в неделю) и публикует отчёт «что на подходе» в канал, указанный в `~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md` → `## House style` → куда отправлять рабочие материалы. Режим 2 — основной результат агента.

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

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

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