Чек-лист закрытия сделки

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

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

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

Что делает: Ведёт список условий и документов для закрытия сделки, подтягивает новые пункты из проверки и показывает, что блокирует закрытие.
Когда брать: Когда идёт сделка (M&A, финансирование) и нужно знать, что осталось до закрытия, что на критическом пути и сколько дней в запасе.
Когда не брать: Если договора купли-продажи нет: список строится по нему. Скилл не получает согласия и не готовит документы, только отслеживает.
Пример запроса: Что осталось до закрытия по проекту Falcon и какие пункты под угрозой срыва?
Нужно подключить: договор купли-продажи
Работает лучше с: почта, Slack

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

Как включить

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

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

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

Текст

---
name: closing-checklist
description: >
  Что мешает закрытию — ведёт чек-лист закрытия сделки со статусами, критическим путём и числом
  дней до закрытия. Обновляется сам: подтягивает новые пункты из выводов проверки (diligence)
  и из составления графика, отслеживает статусы, показывает, что блокирует закрытие. Используй,
  когда пользователь говорит «чек-лист закрытия», «что осталось до закрытия», «статус чек-листа»,
  «добавь в чек-лист» или при запуске по расписанию для сводки статусов.
argument-hint: "[optional: item ID + status update]"
---

/closing-checklist

Прочитай ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml и работай по режимам ниже.
Если передано обновление статуса: режим 3 (обновить пункт).
Иначе режим 4: блокирующие пункты, критический путь, дни до закрытия.

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

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

Назначение

Сделки закрываются, когда чек-лист выполнен. Всё в нём сделано. Ничего не пропущено. Этот скилл ведёт список, подтягивает новые пункты по мере того, как они всплывают в проверке (diligence), и сообщает команде, что блокирует закрытие.

Чек-лист

Лежит в ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml. Структура:

deal_code: "Project Falcon"
target_close: [DATE]
signing_date: [DATE]
last_updated: [DATE]

conditions_precedent:
  - id: CP-001
    item: "HSR waiting period expiration"
    category: "Regulatory"
    responsible: "Buyer counsel"
    due: 2026-04-15
    status: "Filed 2026-03-01, waiting period runs"
    blocking: true
    source: "Purchase Agreement §7.1(a)"

  - id: CP-002
    item: "Acme Corp consent to assignment"
    category: "Third-party consents"
    responsible: "Target — Jane Doe"
    due: 2026-04-20
    status: "Request sent 2026-03-10, no response"
    blocking: true
    source: "Schedule 3.12(a)(4); Acme MSA §14.2"

closing_deliverables:
  - id: CD-001
    item: "Certificate of good standing — Target (DE)"
    category: "Corporate"
    responsible: "Target counsel"
    due: 2026-04-28
    status: "Not started"
    blocking: true
    source: "Purchase Agreement §2.3(b)(iv)"

  # ... etc

Режимы

Режим 1: Инициализация по договору купли-продажи

Прочитай подписанный (или почти окончательный) договор купли-продажи. Извлеки:

Каждое отлагательное условие (conditions precedent) — его расположение зависит от договора, читай реальные заголовки разделов
Каждый документ и действие к закрытию (closing deliverable) — в приложении с перечнем таких документов или в соответствующем разделе
Каждое обязательство (covenant) со сроком до закрытия

Каждое из них становится пунктом чек-листа со ссылкой на раздел договора.

Изучи обязательства, прежде чем заполнять пункты о регуляторных разрешениях и согласованиях. У антимонопольных, инвестиционных (иностранные инвестиции) и отраслевых разрешений (например, подачи типа HSR, CFIUS, отраслевые регуляторы) есть механика, пороги и сроки, зависящие от юрисдикции и меняющиеся со временем. Извлеки из договора название каждого регуляторного условия, затем изучи действующую сейчас механику (кто подаёт, когда, что вызывает повторный запрос, какой срок ожидания). Ссылайся на первоисточники и проверяй актуальность. Не заполняй сроки по памяти.

Условия закрытия о существенном неблагоприятном изменении (MAE/MAC). Возьми определение термина из договора: формулировка MAC/MAE согласуется, а не является стандартом. Прежде чем отмечать событие как возможный триггер MAC, изучи, как применимое право толкует использованную формулировку (Делавэр, Нью-Йорк и другие юрисдикции по-разному относятся к исключениям и количественным критериям).

Извлечение требований о согласии из существенных договоров зависит от правил применимого права по умолчанию и конкретной формулировки о запрете уступки в каждом договоре. Изучай применимое правило по каждому договору, а не предполагай стандартное.

Режим 2: Загрузка из проверки (diligence) — «самообновление»

Режим 2 запускается, когда вышестоящий скилл выдаёт вывод с действием до закрытия. Вышестоящие скиллы и виды результатов, которые принимает этот режим:

**Выводы diligence-issue-extraction** — любой вывод, помеченный для действия при закрытии (согласие, голосование акционеров, решение совета, регуляторная подача, отказ от прав, механика эскроу, письмо о погашении долга). Не только «согласия»: полный список — в разделе Handoffs скилла извлечения.
**Пункты о смене контроля (CoC) и уступке в material-contract-schedule** — положения о смене контроля, запреты на уступку, триггеры MFN, обнаруженные при составлении графика.
**Результат deal-team-summary** — краткая справка для руководства сводит выводы извлечения и иногда выявляет пункт с действием при закрытии, который механическое чтение отдельных справок по извлечению пропустило бы (например, голосование по очищению по §280G, объединяющее несколько трудовых договоров, или составной пакет согласий). Режим 2 читает последний deal-team-summary в папке сделки и сверяет его пункты с действиями при закрытии с чек-листом. Всё, что deal-team-summary отметил как требующее действий до закрытия и чего ещё нет в чек-листе, добавляется.

Схема передачи охватывает весь спектр действий до закрытия, а не только согласия:

handoff:
  # Required fields
  item: "[Counterparty or action, one line]"
  category: "[Third-party consents | Shareholder / board action | Regulatory filing | Release / termination | Escrow / holdback | Closing deliverable]"
  source: "[Contract name / statutory section / VDR path + Bates]"
  blocking: true  # unless the agreement has a materiality qualifier
  severity: "[🔴 / 🟠 / 🟡 / 🟢 — carried from upstream, see severity-floor rule in CLAUDE.md]"

  # Consent / third-party action fields
  counterparty: "[e.g., Dunmore Holdings LLC]"
  guarantor: "[e.g., Buyer parent guaranty required, or N/A]"
  conditions: "[any substantive condition the counterparty attached — e.g., 'replacement guaranty from buyer parent required before consent effective']"
  notice_deadline: "[e.g., 30 days prior to closing, or specific date]"

  # Corporate action fields
  approval_body: "[Shareholders | Board | Committee | Regulator]"
  approval_threshold: "[e.g., 75% disinterested stockholder vote for §280G cleansing]"
  statutory_or_charter_source: "[e.g., IRC §280G(b)(5)(B); Charter Art. IV §2]"

  # Timing
  estimated_time_to_complete: "[e.g., 30 days]"
  must_occur_before: "[e.g., closing | signing | end of hiatus period]"

Сохраняй каждое поле, которое заполнил вышестоящий скилл. Запись «требуется согласие Dunmore с условием о замещающей гарантии и уведомлением за 30 дней» должна появиться в чек-листе со всеми тремя элементами (согласие, гарант, уведомление), а не свернуться до «согласие Dunmore на смену контроля». Если вышестоящий скилл указал серьёзность, перенеси её — см. правило минимальной серьёзности между скиллами в ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md.

Добавляй в чек-лист. Убирай дубли по паре (контрагент + тип действия), а не по свободному названию пункта: согласие Dunmore и освобождение Dunmore — разные пункты, хотя оба называют Dunmore. При удалении дублей объединяй поля, а не перезаписывай: если одна передача заполнила guarantor, а более поздняя — notice_deadline, строка чек-листа несёт оба.

Режим 3: Обновление статуса

Пользователь (или агент dataroom-watcher) присылает обновление статуса. Найди пункт, обнови статус и дату последнего обновления.

/corporate-legal:closing-checklist
CP-002: Acme ответил, форма согласия приложена, нужна встречная подпись

Режим 4: Что блокирует

[ЗАГОЛОВОК РАБОЧЕГО МАТЕРИАЛА — по настройкам плагина ## Outputs — зависит от роли; см. `## Who's using this`]

> Этот отчёт о статусе составлен на основе договора купли-продажи, выводов проверки и внутренних документов сделки. Он наследует их статус привилегии и конфиденциальности: распространение за пределами круга привилегии (контрагент, более широкие бизнес-команды) может снять привилегию. Подтверди список рассылки перед отправкой.

## Статус чек-листа закрытия — [код сделки] — [дата]

**Целевая дата закрытия:** [дата] (через [N] дн.)
**Пунктов:** всего [N] — выполнено [N], в работе [N], не начато [N]

### 🔴 Блокирующие и под угрозой

| ID | Пункт | Срок | Статус | Дней до срока |
|---|---|---|---|---|
| [CP-XXX] | [пункт] | [дата] | [статус] | **[N]** |

### 🟡 Блокирующие, идут по плану

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

### ✅ Выполнено

[N] пунктов — [свёрнутый список]

### Не блокируют (после закрытия, для сведения)

[N] пунктов

---

**Критический путь:** [пункт(ы), от задержки которых сдвинется дата закрытия]

Анализ критического пути

Не все блокирующие пункты равны. Согласие, на получение которого уходит 30 дней, лежит на критическом пути. Справка о благонадёжности (good standing), на которую уходит 2 дня, — нет, хотя оба блокируют.

По каждому блокирующему пункту оцени время до завершения. Те, где (срок - сегодня) < оценочное время, под угрозой. Они идут наверх каждого отчёта о статусе.

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

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

Агент ежедневно проверяет чек-лист, подтягивает обновления статусов из почты/Slack, если они подключены, и публикует отчёт «что блокирует» в канале команды по сделке. Режим 4 — результат агента.

Барьер значимого действия (подтверждение закрытия)

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

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

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

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

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

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

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

---
name: closing-checklist
description: >
  What's blocking close — maintain the closing checklist with status, critical
  path, and days to close. Self-updating: ingests new items from diligence
  findings and schedule builds, tracks status, surfaces what's blocking. Use
  when user says "closing checklist", "what's left to close", "checklist
  status", "add to the checklist", or on a scheduled status pull.
argument-hint: "[optional: item ID + status update]"
---

# /closing-checklist

1. Read `~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml` and use the modes below.
2. If status update provided: Mode 3 (update item).
3. Otherwise Mode 4: blocking items, critical path, days to close.

---

## 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 `/corporate-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/corporate-legal/matters/<matter-slug>/`. Never read another matter's files unless `Cross-matter context` is `on`.

---

## Purpose

Deals close when the checklist is done. Everything on it, done. Nothing missing. This skill maintains the list, ingests new items as they surface from diligence, and tells the team what's blocking.

## The checklist

Lives at `~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml`. Structure:

```yaml
deal_code: "Project Falcon"
target_close: [DATE]
signing_date: [DATE]
last_updated: [DATE]

conditions_precedent:
  - id: CP-001
    item: "HSR waiting period expiration"
    category: "Regulatory"
    responsible: "Buyer counsel"
    due: 2026-04-15
    status: "Filed 2026-03-01, waiting period runs"
    blocking: true
    source: "Purchase Agreement §7.1(a)"

  - id: CP-002
    item: "Acme Corp consent to assignment"
    category: "Third-party consents"
    responsible: "Target — Jane Doe"
    due: 2026-04-20
    status: "Request sent 2026-03-10, no response"
    blocking: true
    source: "Schedule 3.12(a)(4); Acme MSA §14.2"

closing_deliverables:
  - id: CD-001
    item: "Certificate of good standing — Target (DE)"
    category: "Corporate"
    responsible: "Target counsel"
    due: 2026-04-28
    status: "Not started"
    blocking: true
    source: "Purchase Agreement §2.3(b)(iv)"

  # ... etc
```

## Modes

### Mode 1: Initialize from the purchase agreement

Read the signed (or near-final) purchase agreement. Extract:

- Every condition precedent (location varies by agreement — read the actual section headings)
- Every closing deliverable (closing deliverables schedule or corresponding section)
- Every covenant with a pre-closing deadline

Each becomes a checklist item with a source cite to the agreement section.

**Research obligations before populating regulatory/approval items.** Antitrust, foreign-investment, and sector-specific approvals (for example, HSR-style filings, CFIUS, industry regulators) have jurisdiction-specific mechanics, thresholds, and timing windows that change. Extract the name of each regulatory condition from the PA, then research the currently operative mechanics (who files, when, what triggers a second request, what the waiting period is). Cite primary sources and verify currency. Do not populate a timing assumption from memory.

**Material-adverse-effect / material-adverse-change closing conditions.** Pull the defined term from the PA — MAC/MAE framing is negotiated, not a standard. Research the governing-law interpretation of the specific language used (Delaware, New York, and other jurisdictions treat carve-outs and quantitative tests differently) before flagging an event as a potential MAC trigger.

**Consent-requirement extraction from material contracts** depends on governing-law default rules and the specific anti-assignment language in each contract. Research the applicable rule per contract rather than assuming a default.

### Mode 2: Ingest from diligence (the "self-updating" part)

Mode 2 is triggered when an upstream skill produces a finding with a pre-closing action. The upstream skills and output types this mode ingests:

- **`diligence-issue-extraction` findings** — any finding flagged for a closing action (consent, shareholder vote, board resolution, regulatory filing, release, escrow mechanic, pay-off letter). Not just "consents" — see the extraction skill's Handoffs section for the full list.
- **`material-contract-schedule` CoC / assignment items** — change-of-control provisions, anti-assignment clauses, MFN triggers surfaced during schedule build.
- **`deal-team-summary` output** — the exec-tier brief aggregates extraction findings and sometimes surfaces a closing-action item that a mechanical read of the individual extraction memos would miss (e.g., a §280G cleansing vote rolled up across multiple employment agreements, or a composite consent package). Mode 2 reads the latest deal-team-summary in the deal folder and reconciles its closing-action items against the checklist. Anything flagged by deal-team-summary as requiring pre-closing action that is not already on the checklist is appended.

The handoff schema covers the full range of pre-closing actions, not just consents:

```yaml
handoff:
  # Required fields
  item: "[Counterparty or action, one line]"
  category: "[Third-party consents | Shareholder / board action | Regulatory filing | Release / termination | Escrow / holdback | Closing deliverable]"
  source: "[Contract name / statutory section / VDR path + Bates]"
  blocking: true  # unless the agreement has a materiality qualifier
  severity: "[🔴 / 🟠 / 🟡 / 🟢 — carried from upstream, see severity-floor rule in CLAUDE.md]"

  # Consent / third-party action fields
  counterparty: "[e.g., Dunmore Holdings LLC]"
  guarantor: "[e.g., Buyer parent guaranty required, or N/A]"
  conditions: "[any substantive condition the counterparty attached — e.g., 'replacement guaranty from buyer parent required before consent effective']"
  notice_deadline: "[e.g., 30 days prior to closing, or specific date]"

  # Corporate action fields
  approval_body: "[Shareholders | Board | Committee | Regulator]"
  approval_threshold: "[e.g., 75% disinterested stockholder vote for §280G cleansing]"
  statutory_or_charter_source: "[e.g., IRC §280G(b)(5)(B); Charter Art. IV §2]"

  # Timing
  estimated_time_to_complete: "[e.g., 30 days]"
  must_occur_before: "[e.g., closing | signing | end of hiatus period]"
```

Preserve every field the upstream skill populated. A "Dunmore consent required, with replacement guaranty condition and 30-day notice" should surface on the checklist with all three elements (consent, guarantor, notice), not collapse to "Dunmore consent to change of control." When the upstream skill provides a severity, carry it — see the cross-skill severity floor rule in `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`.

Append to the checklist. De-dupe on (counterparty + action type), not on the freeform item name — a Dunmore consent and a Dunmore release are different items even though both name Dunmore. When de-duping, merge fields rather than overwrite: if one handoff populated `guarantor` and a later handoff populated `notice_deadline`, the checklist row carries both.

### Mode 3: Status update

User (or dataroom-watcher agent) provides a status update. Find the item, update status and last-updated.

```
/corporate-legal:closing-checklist
CP-002: Acme responded, consent form attached, needs countersignature
```

### Mode 4: What's blocking

```markdown
[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

> This status report is derived from the purchase agreement, diligence findings, and internal deal records. It inherits their privilege and confidentiality status — distribution beyond the privilege circle (counterparty, broader business teams) can waive privilege. Confirm the distribution list before sending.

## Closing Checklist Status — [Deal code] — [date]

**Target close:** [date] ([N] days out)
**Items:** [N] total — [N] done, [N] in progress, [N] not started

### 🔴 Blocking and at risk

| ID | Item | Due | Status | Days to due |
|---|---|---|---|---|
| [CP-XXX] | [item] | [date] | [status] | **[N]** |

### 🟡 Blocking, on track

[same table]

### ✅ Complete

[N] items — [collapsed list]

### Not blocking (post-closing, informational)

[N] items

---

**Critical path:** [The item(s) that, if they slip, push the close date]
```

## Critical path analysis

Not all blocking items are equal. A consent that takes 30 days to get is critical path. A good-standing certificate that takes 2 days is not, even though both are blocking.

For each blocking item, estimate time-to-complete. The ones where `(due date - today) < estimated time` are at risk. Those go at the top of every status report.

If the checklist has more than ~10 items, 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 status (done / in progress / not started / at risk), a critical-path view grouped by workstream, and a sortable grid with item, owner, due date, and days-to-due.

## Integration: dataroom-watcher agent

The agent checks the checklist daily, pulls any status updates from email/Slack if connected, and posts the "what's blocking" report to the deal team channel. Mode 4 is the agent's output.

## Consequential-action gate (certify closing)

**Before producing a "ready to close / all CPs satisfied" certification or closing memo:** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`. If the Role is **Non-lawyer**:

> Certifying that closing conditions have been satisfied (or producing a closing memo asserting this) has legal consequences — it's the signal that drives funds flow and post-closing obligations. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
>
> - The full CP list with status (what's done, what's in progress, what's not started)
> - Anything where evidence of completion is weak or missing
> - Any waivers or side letters needed for items that won't close in time
> - Open questions (counterparty consents still pending, any MAC/bring-down risk)
> - What to ask the attorney (is this ready to call closed; are any conditions being walked past that shouldn't be; what needs to go on a schedule of exceptions)
>
> 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 produce a final "ready to close" certification past this gate without an explicit yes. Status tracking and "what's blocking" reports do not require the gate.

---

## What this skill does not do

- It doesn't obtain consents, file forms, or draft documents. It tracks that they need to happen.
- It doesn't decide what's blocking — the purchase agreement decides that. This skill reads the agreement.
- It doesn't close the deal. It tells you when you can.

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

---
name: closing-checklist
description: >
  Что мешает закрытию — ведёт чек-лист закрытия сделки со статусами, критическим путём и числом
  дней до закрытия. Обновляется сам: подтягивает новые пункты из выводов проверки (diligence)
  и из составления графика, отслеживает статусы, показывает, что блокирует закрытие. Используй,
  когда пользователь говорит «чек-лист закрытия», «что осталось до закрытия», «статус чек-листа»,
  «добавь в чек-лист» или при запуске по расписанию для сводки статусов.
argument-hint: "[optional: item ID + status update]"
---

# /closing-checklist

1. Прочитай `~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml` и работай по режимам ниже.
2. Если передано обновление статуса: режим 3 (обновить пункт).
3. Иначе режим 4: блокирующие пункты, критический путь, дни до закрытия.

---

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

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

---

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

Сделки закрываются, когда чек-лист выполнен. Всё в нём сделано. Ничего не пропущено. Этот скилл ведёт список, подтягивает новые пункты по мере того, как они всплывают в проверке (diligence), и сообщает команде, что блокирует закрытие.

## Чек-лист

Лежит в `~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/closing-checklist.yaml`. Структура:

```yaml
deal_code: "Project Falcon"
target_close: [DATE]
signing_date: [DATE]
last_updated: [DATE]

conditions_precedent:
  - id: CP-001
    item: "HSR waiting period expiration"
    category: "Regulatory"
    responsible: "Buyer counsel"
    due: 2026-04-15
    status: "Filed 2026-03-01, waiting period runs"
    blocking: true
    source: "Purchase Agreement §7.1(a)"

  - id: CP-002
    item: "Acme Corp consent to assignment"
    category: "Third-party consents"
    responsible: "Target — Jane Doe"
    due: 2026-04-20
    status: "Request sent 2026-03-10, no response"
    blocking: true
    source: "Schedule 3.12(a)(4); Acme MSA §14.2"

closing_deliverables:
  - id: CD-001
    item: "Certificate of good standing — Target (DE)"
    category: "Corporate"
    responsible: "Target counsel"
    due: 2026-04-28
    status: "Not started"
    blocking: true
    source: "Purchase Agreement §2.3(b)(iv)"

  # ... etc
```

## Режимы

### Режим 1: Инициализация по договору купли-продажи

Прочитай подписанный (или почти окончательный) договор купли-продажи. Извлеки:

- Каждое отлагательное условие (conditions precedent) — его расположение зависит от договора, читай реальные заголовки разделов
- Каждый документ и действие к закрытию (closing deliverable) — в приложении с перечнем таких документов или в соответствующем разделе
- Каждое обязательство (covenant) со сроком до закрытия

Каждое из них становится пунктом чек-листа со ссылкой на раздел договора.

**Изучи обязательства, прежде чем заполнять пункты о регуляторных разрешениях и согласованиях.** У антимонопольных, инвестиционных (иностранные инвестиции) и отраслевых разрешений (например, подачи типа HSR, CFIUS, отраслевые регуляторы) есть механика, пороги и сроки, зависящие от юрисдикции и меняющиеся со временем. Извлеки из договора название каждого регуляторного условия, затем изучи действующую сейчас механику (кто подаёт, когда, что вызывает повторный запрос, какой срок ожидания). Ссылайся на первоисточники и проверяй актуальность. Не заполняй сроки по памяти.

**Условия закрытия о существенном неблагоприятном изменении (MAE/MAC).** Возьми определение термина из договора: формулировка MAC/MAE согласуется, а не является стандартом. Прежде чем отмечать событие как возможный триггер MAC, изучи, как применимое право толкует использованную формулировку (Делавэр, Нью-Йорк и другие юрисдикции по-разному относятся к исключениям и количественным критериям).

**Извлечение требований о согласии из существенных договоров** зависит от правил применимого права по умолчанию и конкретной формулировки о запрете уступки в каждом договоре. Изучай применимое правило по каждому договору, а не предполагай стандартное.

### Режим 2: Загрузка из проверки (diligence) — «самообновление»

Режим 2 запускается, когда вышестоящий скилл выдаёт вывод с действием до закрытия. Вышестоящие скиллы и виды результатов, которые принимает этот режим:

- **Выводы `diligence-issue-extraction`** — любой вывод, помеченный для действия при закрытии (согласие, голосование акционеров, решение совета, регуляторная подача, отказ от прав, механика эскроу, письмо о погашении долга). Не только «согласия»: полный список — в разделе Handoffs скилла извлечения.
- **Пункты о смене контроля (CoC) и уступке в `material-contract-schedule`** — положения о смене контроля, запреты на уступку, триггеры MFN, обнаруженные при составлении графика.
- **Результат `deal-team-summary`** — краткая справка для руководства сводит выводы извлечения и иногда выявляет пункт с действием при закрытии, который механическое чтение отдельных справок по извлечению пропустило бы (например, голосование по очищению по §280G, объединяющее несколько трудовых договоров, или составной пакет согласий). Режим 2 читает последний deal-team-summary в папке сделки и сверяет его пункты с действиями при закрытии с чек-листом. Всё, что deal-team-summary отметил как требующее действий до закрытия и чего ещё нет в чек-листе, добавляется.

Схема передачи охватывает весь спектр действий до закрытия, а не только согласия:

```yaml
handoff:
  # Required fields
  item: "[Counterparty or action, one line]"
  category: "[Third-party consents | Shareholder / board action | Regulatory filing | Release / termination | Escrow / holdback | Closing deliverable]"
  source: "[Contract name / statutory section / VDR path + Bates]"
  blocking: true  # unless the agreement has a materiality qualifier
  severity: "[🔴 / 🟠 / 🟡 / 🟢 — carried from upstream, see severity-floor rule in CLAUDE.md]"

  # Consent / third-party action fields
  counterparty: "[e.g., Dunmore Holdings LLC]"
  guarantor: "[e.g., Buyer parent guaranty required, or N/A]"
  conditions: "[any substantive condition the counterparty attached — e.g., 'replacement guaranty from buyer parent required before consent effective']"
  notice_deadline: "[e.g., 30 days prior to closing, or specific date]"

  # Corporate action fields
  approval_body: "[Shareholders | Board | Committee | Regulator]"
  approval_threshold: "[e.g., 75% disinterested stockholder vote for §280G cleansing]"
  statutory_or_charter_source: "[e.g., IRC §280G(b)(5)(B); Charter Art. IV §2]"

  # Timing
  estimated_time_to_complete: "[e.g., 30 days]"
  must_occur_before: "[e.g., closing | signing | end of hiatus period]"
```

Сохраняй каждое поле, которое заполнил вышестоящий скилл. Запись «требуется согласие Dunmore с условием о замещающей гарантии и уведомлением за 30 дней» должна появиться в чек-листе со всеми тремя элементами (согласие, гарант, уведомление), а не свернуться до «согласие Dunmore на смену контроля». Если вышестоящий скилл указал серьёзность, перенеси её — см. правило минимальной серьёзности между скиллами в `~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md`.

Добавляй в чек-лист. Убирай дубли по паре (контрагент + тип действия), а не по свободному названию пункта: согласие Dunmore и освобождение Dunmore — разные пункты, хотя оба называют Dunmore. При удалении дублей объединяй поля, а не перезаписывай: если одна передача заполнила `guarantor`, а более поздняя — `notice_deadline`, строка чек-листа несёт оба.

### Режим 3: Обновление статуса

Пользователь (или агент dataroom-watcher) присылает обновление статуса. Найди пункт, обнови статус и дату последнего обновления.

```
/corporate-legal:closing-checklist
CP-002: Acme ответил, форма согласия приложена, нужна встречная подпись
```

### Режим 4: Что блокирует

```markdown
[ЗАГОЛОВОК РАБОЧЕГО МАТЕРИАЛА — по настройкам плагина ## Outputs — зависит от роли; см. `## Who's using this`]

> Этот отчёт о статусе составлен на основе договора купли-продажи, выводов проверки и внутренних документов сделки. Он наследует их статус привилегии и конфиденциальности: распространение за пределами круга привилегии (контрагент, более широкие бизнес-команды) может снять привилегию. Подтверди список рассылки перед отправкой.

## Статус чек-листа закрытия — [код сделки] — [дата]

**Целевая дата закрытия:** [дата] (через [N] дн.)
**Пунктов:** всего [N] — выполнено [N], в работе [N], не начато [N]

### 🔴 Блокирующие и под угрозой

| ID | Пункт | Срок | Статус | Дней до срока |
|---|---|---|---|---|
| [CP-XXX] | [пункт] | [дата] | [статус] | **[N]** |

### 🟡 Блокирующие, идут по плану

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

### ✅ Выполнено

[N] пунктов — [свёрнутый список]

### Не блокируют (после закрытия, для сведения)

[N] пунктов

---

**Критический путь:** [пункт(ы), от задержки которых сдвинется дата закрытия]
```

## Анализ критического пути

Не все блокирующие пункты равны. Согласие, на получение которого уходит 30 дней, лежит на критическом пути. Справка о благонадёжности (good standing), на которую уходит 2 дня, — нет, хотя оба блокируют.

По каждому блокирующему пункту оцени время до завершения. Те, где `(срок - сегодня) < оценочное время`, под угрозой. Они идут наверх каждого отчёта о статусе.

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

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

Агент ежедневно проверяет чек-лист, подтягивает обновления статусов из почты/Slack, если они подключены, и публикует отчёт «что блокирует» в канале команды по сделке. Режим 4 — результат агента.

## Барьер значимого действия (подтверждение закрытия)

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

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

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

---

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

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

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