iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Разбор входящей претензии

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

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется
Что делает
Разбирает полученную претензию: извлекает требования, сверяет с портфелем дел, оценивает обоснованность и предлагает варианты ответа с рекомендацией.
Когда брать
Когда компания получила претензионное письмо и нужно понять, насколько оно серьёзно, какие сроки и как лучше ответить.
Когда не брать
Если нужно самим составить и отправить претензию: для этого demand-intake и demand-draft. Скилл не выносит окончательного суждения по существу.
Пример запроса
Нам пришла претензия от ООО «Ромашка»: разбери её и скажи, как лучше ответить.
Нужно подключить
доступ к файлам (папка настроек плагина), входящее письмо (файл)
Работает лучше с
журнал дел (_log.yaml), правовая база (Westlaw, CourtListener и др.)

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

Как включить

  1. Скачайте архив и распакуйте его.
  2. Положите папку demand-received в ~/.claude/skills/.
  3. Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: demand-received
description: Разбирает входящее претензионное письмо — извлекает поля, сверяет с портфелем дел, оценивает обоснованность, предлагает варианты ответа с рекомендацией и при необходимости эскалации передаёт в matter-intake или demand-intake. Используй, когда пользователь говорит «нам пришла претензия», «разбери эту претензию» или присылает входящую претензию для оценки.
argument-hint: "[path-to-incoming] [--slug=custom-slug]"
---

/demand-received

  1. Прочитай входящий документ по указанному пути.
  2. Загрузи ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml для сверки с портфелем.
  3. Загрузи ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → калибровка рисков, ландшафт, практика претензионных писем.
  4. Следуй рабочему процессу и справочнику ниже.
  5. Извлеки поля; сверь с портфелем; оцени обоснованность; предложи варианты с рекомендацией.
  6. Запиши ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md. Скопируй входящий документ или сделай ссылку на него в ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/incoming.[ext].
  7. Передай дальше по выбору пользователя:
  8. Создать дело → matter-intake с предзаполненными полями
  9. Ответить встречным требованием → demand-intake с предзаполненными полями
  10. Связать с существующим делом → обнови related_matters в журнале
  11. Отдельно → дальнейших действий нет

Входящая претензия

Назначение

Входящие претензионные письма — хлеб с маслом судебной практики внутри компании. Лишь небольшая доля требует эскалации; большинство можно закрыть структурированным ответом или промежуточным письмом. Типичная ошибка — относиться ко всем одинаково. Этот скилл проводит разбор, сверяет с портфелем и предлагает варианты.

Загрузка контекста

  • Входящий документ (пользователь указывает путь или присылает в сессии)
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml — найди связанные дела (тот же контрагент, пересекающиеся контрагенты через связи между юридическими лицами или тип дела + недавняя дата)
  • ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → калибровка рисков (для оценки обоснованности), ландшафт (отправитель — частый противник?), практика претензионных писем (принятый тон и стандартные ответы)

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

Шаг 1: Прочитай претензию

Извлеки из входящего документа:

  • Отправитель — юридическое лицо, подписант, юрист (если подписано внешней фирмой)
  • Получатель — какое юридическое лицо / какой человек в нашей компании
  • Доставка — заказным письмом, электронной почтой, курьером (важно для расчёта сроков)
  • Дата получения и дата подписания
  • Тип претензии — оплата, нарушение/устранение, C&D (требование прекратить нарушение), сохранение документов, урегулирование, другое
  • Конкретные требования — чего они хотят и к какому сроку
  • Заявленные факты — их версия событий
  • Правовое основание — законы, положения договора, теории, на которые они ссылаются
  • Угрозы — что они обещают сделать, если мы не исполним
  • Подача как переписка в рамках урегулирования — изучи защиту переписки в рамках урегулирования, применимую в суде (FRE 408 в федеральной системе, аналог штата — в остальных случаях). Отметь, помечена ли претензия как переписка об урегулировании, но помни: защита возникает из поведения и контекста, а не только из пометки. Зафиксируй и пометку (если есть), и первичную оценку того, является ли содержание на самом деле обсуждением компромисса.

Шаг 2: Сверка с портфелем

Найди в _log.yaml:

  • Прямое совпадение — дело с тем же контрагентом (их ярлык (slug) совпадает с отправителем)
  • Совпадение по типу — похожее дело с этим контрагентом в прошлом (закрытые дела тоже считаются — они подсказывают шаблон)
  • Пересечение по предмету — дела, где предмет может быть тем же спором (например, тот же договор, тот же продукт, тот же проект)

Представь результаты:

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

Шаг 3: Оценка обоснованности

Это не юридическое заключение, а структурированная оценка:

  • Факты — совпадают ли заявленные факты с тем, что мы знаем? Где расхождение?
  • Правовое основание — действительно ли применимы указанные положения/законы? (Отметь ссылки для проверки пользователем — не пытайся проверять право самостоятельно.)
  • Сила их стороны — если бы они завтра пошли в суд, какова их история?
  • Сила нашей стороны — каковы наши вероятные возражения?
  • Заявленные убытки и вероятные — соразмерно ли требование тому, что присудил бы суд при их победе?
  • Рычаги и давление — готовы ли они всерьёз подавать в суд? Есть ли у них возможности? Они постоянный противник в судах по ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md?

Дай рейтинг разбора: существенные основания (substantial merit) / спорно (debatable) / слабо (weak) / необоснованно (frivolous). Говори прямо. Пользователь сортирует дела, а не пишет бриф.

Шаг 4: Варианты ответа

Представь 3–4 варианта с компромиссами:

Вариант A — ответ по существу

  • Когда: в их требовании есть основания или оно по крайней мере спорное; обоснованный ответ защищает материалы дела
  • Компромисс: фиксирует нашу позицию письменно
  • Следующий шаг: /demand-intake с предзаполненными полями для ответного письма

Вариант B — промежуточное письмо (holding letter)

  • Когда: нужно время на проверку; не хотим ничего признавать или запускать их расчёт сроков
  • Компромисс: ничего не решает; выигрывает 2–4 недели
  • Следующий шаг: короткий черновик подтверждения получения

Вариант C — ответ в порядке урегулирования

  • Когда: ранняя договорённость дешевле суда; готовы обсуждать без признания
  • Компромисс: требуется позиция по переписке в рамках урегулирования — изучи применимое правило (FRE 408 или аналог штата) и построй ответ так, чтобы содержание, а не только пометка, квалифицировалось как обсуждение компромисса. Нужно быть осторожным, чтобы не отказаться от требований.
  • Следующий шаг: /demand-intake с type: settlement-response

Вариант D — игнорировать + сохранить документы

  • Когда: претензия необоснованна или срок не создаёт правового ущерба
  • Компромисс: молчание в некоторых контекстах можно использовать против нас (например, подтверждённый счёт, account stated); уведомление о сохранении документов всё равно требуется
  • Следующий шаг: выпусти уведомление о сохранении документов через /legal-hold --issue, если ещё не выпущено; зафиксируй претензию и иди дальше

Порекомендуй один. Конкретно объясни почему.

Шаг 5: Разбор сроков

  • Их заявленный срок — отметь, но он нас не связывает
  • Наш внутренний срок — когда мы должны решить (часто: заявленный срок минус 5 рабочих дней на составление и согласование)
  • Правовые сроки — срок исковой давности, договорные сроки устранения, процессуальные требования

Отметь жёсткие правовые сроки. Внеси их в календарь.

Никаких молчаливых дополнений. Если входящая претензия ссылается на правила, дела или законы, которые требуют проверки, а запрос к настроенному инструменту правового поиска (Westlaw, CourtListener, Trellis, Descrybe или платформа фирмы) по какой-то норме возвращает мало результатов или ни одного, сообщи, что найдено, и остановись. НЕ заполняй пробел из веб-поиска или знаний модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Охват по [ссылка / доктрина] кажется скудным. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в интернете — результаты будут помечены [web search — verify] и перед использованием требуют сверки с первоисточником, или (4) оставить пометку [SME VERIFY] и остановиться. Что выберете?» Юрист решает, принимать ли источники с меньшей надёжностью; скилл не решает за него.

Указание источника. Пометь каждую ссылку, попавшую в разбор, — включая нормы, на которые ссылается отправитель, обоснования наших вариантов ответа и любые материалы поиска для оценки обоснованности, — откуда она взята: [Westlaw], [CourtListener], [Trellis], [Descrybe] или имя инструмента MCP для ссылок, полученных из коннектора правового поиска; [web search — verify] для ссылок из веб-поиска; [model knowledge — verify] для ссылок, которые модель вспомнила из обучающих данных; [user provided] для ссылок, указанных в самой претензии. Ссылки с пометкой verify несут больший риск выдумки, и их нужно проверять в первую очередь. Никогда не удаляй и не объединяй пометки.

Шаг 6: Запиши разбор

Результат: ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md.

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

> **Наследование привилегии.** Этот разбор составлен по входящей претензии и журналу портфеля и фиксирует нашу первичную оценку обоснованности и позицию по ответу. Этот внутренний анализ охватывается адвокатской тайной (attorney-client privilege) и/или защитой рабочих материалов юриста (work product). Распространение разбора за пределы круга лиц, охваченных привилегией, — в том числе пересылка бизнес-руководителю без маркировки, передача контрагенту или прикрепление к передаче иска страховщику без очистки — может привести к утрате защиты и для самого документа, и для рассуждений в нём. Храните вместе с привилегированными материалами дела, маркируйте в соответствии с правилами о привилегии вашего стиля оформления и принимайте решения о распространении осознанно.

# Входящая претензия — разбор

> **ЭТО СОРТИРОВКА, А НЕ ЗАКЛЮЧЕНИЕ.** Этот документ — сканирование при приёме и анализ вариантов, а не юридическое заключение по существу. `Рейтинг разбора` ниже — структурированная оценка, помогающая юристу решить, как направить претензию. Это не рекомендация по существу и не замена анализа конкретного дела. Каждый указанный закон, правило или дело помечен для проверки специалистом; каждое суждение по существу принадлежит юристу, а не этому скиллу.

**Slug:** [slug]
**Получено:** [ГГГГ-ММ-ДД]
**Кто получил:** [юридическое лицо / человек]
**Входящий файл:** [путь]

---

## Претензия

**Отправитель:** [юридическое лицо, подписант, юрист]
**Тип претензии:** [тип]
**Конкретные требования:** [список]
**Их заявленный срок:** [дата]
**Подача как переписка в рамках урегулирования:** [помечена / по содержанию / ни то ни другое / неясно] — *защита зависит от поведения и контекста, а не от пометки; `[SME VERIFY]` по применимому правилу суда*

## Заявленные факты

[их версия, одним абзацем]

## Указанное правовое основание

[ссылки — каждая помечена в тексте `[SME VERIFY: applicability / currency / jurisdiction]` — не полагайся ни на одну ссылку здесь без независимой проверки]

## Угрозы / следующие шаги, которые они называют

[список]

---

## Сверка с портфелем

**Прямое совпадение:** [slug, если есть, или «нет»]
**Совпадение по типу / прецедент:** [список или «нет»]
**Пересечение по предмету:** [список или «нет»]
**Рекомендация:** [новое дело / добавить к существующему / связать через related_matters / отдельная входящая претензия]

---

## Оценка обоснованности

**Факты:** [соответствие нашей версии; расхождения]
**Правовое основание:** [применимость, с пометками]
**Их позиция, если дойдёт до суда:** [один абзац]
**Наши возражения:** [один абзац]
**Соразмерность убытков:** [оценка]
**Реальность угрозы:** [подадут ли в суд? возможности? постоянный истец?]

**Рейтинг разбора:** [существенные основания / спорно / слабо / необоснованно] — *структурированная оценка для маршрутизации, а не заключение по существу; `[SME VERIFY: counsel to confirm before relying on this]`*

---

## Варианты ответа

### A. Ответ по существу
[Обоснование, компромиссы, следующий шаг]

### B. Промежуточное письмо
[Обоснование, компромиссы, следующий шаг]

### C. Ответ в порядке урегулирования
[Обоснование, компромиссы, следующий шаг]

### D. Игнорировать + сохранить документы
[Обоснование, компромиссы, следующий шаг]

**Рекомендация:** [A/B/C/D] — [два предложения почему] — `[SME VERIFY: counsel to confirm before executing]`

---

## Сроки

- **Их заявленный срок:** [дата]
- **Наш внутренний срок принятия решения:** [дата]
- **Правовые сроки:** [срок исковой давности, сроки устранения, процессуальные — с датами]

---

## Немедленные действия

- [ ] Уведомление о сохранении документов выпущено — [да/нет] — если нет, запусти `/legal-hold [slug] --issue`
- [ ] Дело создано в журнале — [да/нет/определить]
- [ ] Юрист назначен — [кто]
- [ ] Иск передан страховщику — [да/нет/не применимо]
- [ ] Внутренняя эскалация (GC/финансовый директор/бизнес-руководитель) — [кто/когда]

Шаг 7: Передай дальше

По рекомендации и подтверждению пользователя:

  • Создание дела → передай в /matter-intake с: контрагент, тип, source: demand-letter (входящая), исходная теория в защитной формулировке, предзаполнено.
  • Ответ как исходящая претензия → передай в /demand-intake с: контрагент, контекст из разбора, желаемый результат как ответ.
  • Связать с существующим делом → обнови related_matters этого дела в _log.yaml; добавь событие в его history.md.
  • Отдельно → оставь в ~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/; портфель не меняется.

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

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

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

  • Не проверяет цитируемое право. Отмечает ссылки, чтобы пользователь прогнал их через ситатор (citator, проверка, что норма действует) или проверил с внешним юристом. Выдумывать юридический анализ по входящим претензиям — риск профессиональной ответственности.
  • Не отправляет ответ. Черновики составляются в demand-draft; этот скилл останавливается на решении по разбору.
  • Не выносит окончательное суждение по существу. Рейтинг — это оценка для сортировки; формальное заключение по существу даёт внешний юрист или более подробный анализ.
  • Не принимает решение о создании дела. Предлагает рекомендацию; решает пользователь.

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

Оригинал на английском
---
name: demand-received
description: Triage an inbound demand letter — extract fields, cross-check the portfolio, assess merit, present response options with a recommendation, and hand off to matter-intake or demand-intake if escalation is warranted. Use when the user says "we got a demand letter", "triage this demand", or shares an incoming demand to evaluate.
argument-hint: "[path-to-incoming] [--slug=custom-slug]"
---

# /demand-received

1. Read the incoming document from provided path.
2. Load `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml` for portfolio cross-check.
3. Load `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md` → risk calibration, landscape, demand-letter practice.
4. Follow the workflow and reference below.
5. Extract fields; cross-check portfolio; assess merit; present options with recommendation.
6. Write `~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md`. Copy or link incoming to `~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/incoming.[ext]`.
7. Hand off per user choice:
   - Create matter → `matter-intake` pre-populated
   - Respond with counter-demand → `demand-intake` pre-populated
   - Link to existing matter → update `related_matters` in log
   - Standalone → no further action

---

# Demand Received

## Purpose

Inbound demand letters are the bread and butter of an in-house litigation practice. A small fraction need escalation; most can be handled with a structured response or a holding letter. The failure mode is treating them all alike. This skill triages, cross-checks the portfolio, and produces options.

## Load context

- The incoming document (user provides path or drops it in-session)
- `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml` — scan for related matters (same counterparty, overlapping counterparties via entity relationships, or matter type + recent date)
- `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md` → risk calibration (for merit assessment), landscape (is the sender a frequent adversary?), demand-letter practice (house tone and response defaults)

## Workflow

### Step 1: Read the demand

Extract from the incoming:

- **Sender** — entity, signer, counsel (if signed by outside firm)
- **Recipient** — which entity/person at our company
- **Delivery** — certified, email, courier (matters for deadline calculation)
- **Date received** vs. **date signed**
- **Demand type** — payment, breach/cure, C&D, preservation, settlement, other
- **Specific asks** — what they want, by when
- **Facts alleged** — their version of what happened
- **Legal basis** — statutes, contract provisions, theories they cite
- **Threats** — what they say they'll do if we don't comply
- **Settlement-communication framing** — research the settlement-communication protections applicable in the forum (FRE 408 in federal, the state equivalent otherwise). Note whether the demand is marked as a settlement communication, but remember: protection attaches from conduct and context, not merely from labeling. Capture both the label (if any) and a first-pass read of whether the substance is in fact a compromise discussion.

### Step 2: Portfolio cross-check

Search `_log.yaml` for:

- **Direct match** — matter with same counterparty (their slug matches the sender)
- **Type match** — similar matter type with this counterparty in the past (closed matters count — they inform pattern)
- **Subject overlap** — matters where the subject might be the same dispute (e.g., same contract, same product, same project)

Present findings:

- If **direct match + active:** flag as almost certainly the same matter; recommend adding incoming to the existing matter, not opening a new one. Update `related_matters` if it's a tangent.
- If **direct match + closed:** flag — counterparty is back. May be a new dispute (open new matter) or a resurrected one (reopen or amend). User decides.
- If **type match:** note as precedent/context; probably distinct matter but inform the response strategy.
- If **no match:** novel. Treat as fresh.

### Step 3: Merit assessment

Not a legal opinion — a structured read:

- **Facts** — do the alleged facts align with what we know? Where's the disconnect?
- **Legal basis** — are the cited provisions/statutes actually applicable? (Flag cites for user verification — do not attempt to validate law autonomously.)
- **Strength on their side** — if they went to court tomorrow, what's their story?
- **Strength on our side** — what are our likely defenses?
- **Damages demanded vs. likely** — is the ask proportionate to what a court would award if they won?
- **Leverage and pressure** — are they credibly prepared to sue? Do they have capacity? Are they a repeat-litigant adversary per `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md`?

Output a triage rating: **substantial merit / debatable / weak / frivolous**. Be blunt. The user is triaging, not writing the brief.

### Step 4: Response options

Present 3-4 options with tradeoffs:

**Option A — substantive response**
- When: their demand has merit or is at least debatable; a reasoned reply protects the record
- Tradeoff: commits us to a position in writing
- Next step: `/demand-intake` with pre-populated fields for a counter-response letter

**Option B — holding letter**
- When: need time to investigate; don't want to concede anything or trigger their deadline math
- Tradeoff: doesn't resolve anything; buys 2-4 weeks
- Next step: short acknowledgment draft

**Option C — settlement response**
- When: early resolution is cheaper than litigation; willing to discuss without admitting
- Tradeoff: settlement-communication posture required — research the applicable rule (FRE 408 or state equivalent) and structure the response so the substance, not just the label, qualifies as a compromise discussion. Must be careful not to waive claims.
- Next step: `/demand-intake` with `type: settlement-response`

**Option D — ignore + preserve**
- When: demand is frivolous or the deadline doesn't create legal prejudice
- Tradeoff: silence can be used against us in some contexts (e.g., account stated); legal hold still required
- Next step: issue legal hold via `/legal-hold --issue` if not already; log the demand and move on

Recommend one. Be specific about why.

### Step 5: Deadline triage

- **Their stated deadline** — note it, but it doesn't bind us
- **Our internal deadline** — when we must decide (often: stated deadline minus 5 business days to draft + approve)
- **Legal deadlines** — statute of limitations, contractual cure periods, procedural requirements

Flag any legal deadlines that are tight. Calendar them.

**No silent supplement.** If the inbound demand cites rules, cases, or statutes that require verification, and a research query to the configured legal research tool (Westlaw, CourtListener, Trellis, Descrybe, or firm platform) returns few or no results for a given authority, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [cite / doctrine]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged `[web search — verify]` and should be checked against a primary source before relying, or (4) leave the `[SME VERIFY]` flag and stop here. Which would you like?" A lawyer decides whether to accept lower-confidence sources; the skill does not decide for them.

**Source attribution.** Tag every citation carried into the triage — including the sender's cited authorities, our response-option rationales, and any research pulled for merit assessment — with where it came from: `[Westlaw]`, `[CourtListener]`, `[Trellis]`, `[Descrybe]`, or the MCP tool name for citations retrieved from a legal research connector; `[web search — verify]` for web-search citations; `[model knowledge — verify]` for citations recalled from training data; `[user provided]` for citations supplied in the demand itself. Citations tagged `verify` carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

### Step 6: Write triage

Output: `~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/[slug]/triage.md`.

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

> **Privilege inheritance.** This triage is derived from the inbound demand and from the portfolio log, and it records our first-pass merit read and response posture. Those internal analyses are attorney-client and/or work-product material. Distributing this triage beyond the privilege circle — including forwarding it to the business lead without marking, sharing with the counterparty, or attaching to an insurance tender without scrubbing — can waive protection over both this document and the reasoning inside it. Store with privileged matter material, mark consistently with house privilege conventions, and make distribution decisions deliberately.

# Demand Received — Triage

> **READ FOR TRIAGE, NOT OPINION.** This document is an intake scan and an options analysis — not a legal merit opinion. The `Triage rating` below is a structured read to support the counsel's decision on how to route the demand. It is not a recommendation on the merits and does not substitute for case-specific legal analysis. Every cited statute, rule, or case is flagged for SME verification; every merit call is the counsel's, not this skill's.

**Slug:** [slug]
**Received:** [YYYY-MM-DD]
**Received by:** [entity / person]
**Incoming file:** [path]

---

## The demand

**Sender:** [entity, signer, counsel]
**Demand type:** [type]
**Specific asks:** [list]
**Their stated deadline:** [date]
**Settlement-communication framing:** [labeled / substantively / neither / ambiguous] — *protection turns on conduct and context, not the label; `[SME VERIFY]` against the forum's applicable rule*

## Facts alleged

[their version, in one paragraph]

## Legal basis cited

[citations — each inline-flagged with `[SME VERIFY: applicability / currency / jurisdiction]` — do not rely on any citation here without independent check]

## Threats / next steps they state

[list]

---

## Portfolio cross-check

**Direct match:** [slug if exists, or "none"]
**Type match / precedent:** [list or "none"]
**Subject overlap:** [list or "none"]
**Recommendation:** [new matter / add to existing / link via related_matters / standalone inbound]

---

## Merit assessment

**Facts:** [alignment with our version; disconnects]
**Legal basis:** [applicability, with flags]
**Their case if litigated:** [one paragraph]
**Our defenses:** [one paragraph]
**Damages proportionality:** [assessment]
**Credibility of threat:** [will they sue? capacity? repeat litigant?]

**Triage rating:** [substantial / debatable / weak / frivolous] — *structured read for routing, not a merit opinion; `[SME VERIFY: counsel to confirm before relying on this]`*

---

## Response options

### A. Substantive response
[Rationale, tradeoffs, next step]

### B. Holding letter
[Rationale, tradeoffs, next step]

### C. Settlement response
[Rationale, tradeoffs, next step]

### D. Ignore + preserve
[Rationale, tradeoffs, next step]

**Recommendation:** [A/B/C/D] — [two sentences why] — `[SME VERIFY: counsel to confirm before executing]`

---

## Deadlines

- **Their stated deadline:** [date]
- **Our internal decision deadline:** [date]
- **Legal deadlines:** [SoL, cure periods, procedural — with dates]

---

## Immediate actions

- [ ] Legal hold issued — [yes/no] — if no, run `/legal-hold [slug] --issue`
- [ ] Matter created in log — [yes/no/TBD]
- [ ] Counsel assigned — [who]
- [ ] Insurance tendered — [yes/no/N-A]
- [ ] Internal escalation (GC/CFO/business lead) — [who/when]
```

### Step 7: Hand off

Based on recommendation and user confirmation:

- Matter creation → hand off to `/matter-intake` with: counterparty, type, `source: demand-letter` (inbound), initial theory framed defensively, pre-populated.
- Counter-response as outbound demand → hand off to `/demand-intake` with: counterparty, context from triage, desired outcome as the response.
- Link to existing matter → update that matter's `related_matters` in `_log.yaml`; append event to its `history.md`.
- Standalone → leave in `~/.claude/plugins/config/claude-for-legal/litigation-legal/inbound/`; no portfolio change.

## Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

## What this skill does not do

- **Validate cited law.** Flags cites for the user to run through a citator (verify it is good law) or check with outside counsel. Inventing legal analysis on inbound demands is malpractice exposure.
- **Send a response.** Drafts are drafted in `demand-draft`; this skill stops at the triage decision.
- **Decide merit definitively.** The rating is a read for triage; a formal merit opinion lives with outside counsel or more thorough analysis.
- **Make the matter-creation call.** Surfaces the recommendation; user decides.

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