Хронология по документам дела

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

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

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

Что делает: Собирает хронологию событий из документов дела, убирает дубли, помечает значимость по версии дела и отмечает пробелы и привилегированные материалы.
Когда брать: Когда нужно составить рабочую хронологию или временную шкалу по файлу дела или переданным документам, в том числе для изложения обстоятельств или подготовки свидетеля.
Когда не брать: Если дело не прошло приём (проверку конфликта интересов) или документы получены в порядке раскрытия и их использование для другой цели не подтверждено.
Пример запроса: Построй хронологию по файлу дела «Ромашка против Лютик» и отметь ключевые события.
Нужно подключить: документы дела или переданные материалы, профиль практики с версией дела
Работает лучше с: Gmail или Outlook, Google Drive, SharePoint, iManage, платформа eDiscovery (Everlaw, Relativity, DISCO, Aurora)

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

Как включить

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

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

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

Текст

---
name: chronology
description: Составь или обнови хронологию по заявленным источникам документов и загруженным файлам: датированные события извлекаются, очищаются от дублей и помечаются по значимости согласно версии дела. Используй, когда пользователь просит составить хронологию или временную шкалу по переданным документам или файлу дела, говорит «хронология по переданным документам» или «что когда произошло», либо ему нужна рабочая хронология, хронология для изложения обстоятельств или хронология по конкретному свидетелю.
argument-hint: "[slug] [--format=working|sof|witness-[name]]"
---

/chronology

Загрузи ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md → версия дела, ключевой факт (pivot fact), основные факты.
Загрузи ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md → источники хранения документов, шаблон папки дела по умолчанию.
Следуй рабочему процессу и справке ниже.
Определи источники по порядку: пути, указанные пользователем в этой сессии, папка дела по умолчанию, источники, заявленные в ~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md.
Из читаемых источников: извлеки датированные события. О недоступных источниках: запиши в «Пробелах».
Убери дубли, объедини источники по каждому событию.
Пометь значимость (🔴/🟡/⚪) по версии дела.
Запиши ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md (или вариант формата по флагу).
Если есть прежняя версия: номер версии увеличивается, пользователю показывается краткое описание отличий.
Подтверди перед завершением: «Вот что я собрал. Просмотрите записи 🔴: не ошибся ли я где-нибудь?»

Хронология

Ограничения на использование раскрытых документов

Прежде чем работать с набором судебных документов, спроси: «Были ли какие-либо из этих документов получены в порядке раскрытия или обмена доказательствами (disclosure / discovery) в судебном производстве?» Если да:

Англия и Уэльс (CPR 31.22): на документы, полученные при раскрытии, распространяется подразумеваемое обязательство: их можно использовать только для целей того производства, в котором они раскрыты, если только суд не даст разрешение, раскрывающая сторона не согласится или документ не был зачитан в открытом заседании. Использование их по другому делу, другому требованию или в коммерческих целях без разрешения — неуважение к суду (contempt).
США: защитные определения (protective orders) и Rule 26(c) могут вводить похожие ограничения. Проверь определение.
Другие юрисдикции: обычно действуют похожие ограничения. Проверь местное правило.

Подтверди: «Это использование укладывается в производство, в котором документы были раскрыты, либо у меня есть разрешение / согласие, либо документы теперь публичны». Если не подтверждено, пометь: «⚠️ На раскрытые документы могут действовать ограничения использования. Убедитесь, что такое использование разрешено, прежде чем продолжать».

Назначение

Факты происходят по порядку. Хронология — это позвоночник, на который нанизывается любой рассказ: изложение обстоятельств в документе, записки о резервах, записки об урегулировании, подготовка к депозициям и к допросу свидетелей. Собирать хронологию вручную медленно; ИИ хорошо справляется со структурным извлечением. Но есть оговорка: мусор на входе — мусор на выходе. Этот скилл берёт данные из источников, заявленных в конфигурации, и из всего, что загрузит пользователь.

Режимы

Этот скилл обслуживает две практические среды. Выбери режим по умолчанию по полю ## Role пользователя в CLAUDE.md конфигурации плагина; пользователь может переопределить его флагом при каждом запуске.

**Режим --matter (по умолчанию для корпоративного юриста по спорам).** Ориентирован на историю дела. Читает версию дела и основные факты из matter.md, берёт данные из заявленных источников хранения документов (Google Drive, SharePoint, Gmail, iManage, CLM — всё, что объявлено в разделе ## Landscape файла CLAUDE.md) и считает history.md текущим внутренним журналом (решения, режимы сохранения документов, записки о резервах — намеренно не входят в хронологию). Результат ориентирован на дело: что происходило по всему спору, с пометками для использования в аргументации.
**Режим --documents (по умолчанию для ассоциата / помощника юриста фирмы).** Ориентирован на переданные документы. Читает версию дела из конфигурации, затем извлекает данные из экспорта eDiscovery, набора файлов хранителей (custodians) или пронумерованной по Бейтсу передачи документов (production). Результат ориентирован на передачу документов: что показывают документы, со ссылками на номера Бейтса, с пометками по версии дела.

Оба режима сходятся в одной структуре результата (хронология, пометки значимости 🔴/🟡/⚪, пробелы, вариант для изложения обстоятельств). Различие — в профиле источников и в рамке значимости.

Если ## Role — solo или other, по умолчанию выбери --matter, но при первом запуске назови оба режима и дай пользователю выбрать.

Рамка стороны (пометки значимости)

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

Истец (наступательная рамка) — 🔴 отмечает события, которые *устанавливают* элементы требования (ответственность, причинную связь, ущерб, уведомление), *закрывают* пробелы, которые попытается открыть защита, или *запускают* течение срока исковой давности в пользу истца. 🟡 отмечает события, которые поддерживают требование, но уязвимы для оспаривания. ⚪ — фоновый контекст.
Защита (оборонительная рамка) — 🔴 отмечает события, которые *ломают* элементы требования (отсутствие причинной связи, уведомления, доверия), *открывают* защиту по сроку исковой давности или юрисдикции либо *поддерживают* возражения по существу (освобождение, отказ от права, принятие риска, сопутствующая вина). 🟡 отмечает события, которые подрывают рассказ истца. ⚪ — фон.
Обе / по-разному — спроси пользователя для каждой хронологии, чью рамку применять к пометкам значимости. Сама хронология нейтральна к стороне; меняется только чтение значимости.

Укажи применённую рамку в начале результата: Significance tags applied from [plaintiff / defense] perspective. При подготовке варианта для изложения обстоятельств используй сторону по умолчанию, если пользователь не укажет иное.

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

Общее:

CLAUDE.md конфигурации плагина → контекст версии дела (корпоративный юрист: ## Landscape для источников документов; ассоциат фирмы: ## Case theory и ## Document review для платформы и хранителей), ## Outputs для заголовка рабочего материала, ## Decision posture для правила пометки привилегированных материалов.
Прежний chronology.md по этому делу, если он есть.
Любые файлы, которые пользователь загружает, или пути, которые он даёт в сессии.

Режим --matter дополнительно читает:

~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md → версия дела, основные факты, ключевой факт (для пометок значимости), ключевые даты.
Шаблон папки дела по умолчанию из CLAUDE.md → где лежат документы для этой метки.

Режим --documents дополнительно читает:

метаданные платформы eDiscovery, если доступен коннектор (Everlaw, Relativity, DISCO, Aurora) — по хранителю и диапазону дат.
Манифест диапазонов Бейтса или указатель передачи документов, если пользователь на него указывает.

**Барьер конфликта интересов — обойти нельзя (режим --matter).** Перед построением хронологии проверь ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml на метку дела. Если дела нет в _log.yaml, откажись и перенаправь:

«Я не вижу [метка дела] в журнале дел. Сначала запустите /litigation-legal:matter-intake, чтобы выполнилась проверка конфликта интересов и было настроено рабочее пространство дела. Я не буду строить хронологию по делу, которое не прошло приём: проверка конфликта интересов — это барьер».

Не продолжай по делу, которое не прошло приём. Приём запускает проверку конфликта интересов и записывает строку в _log.yaml, которую читает этот скилл. Режим --documents (работа с произвольным набором документов без метки дела) от барьера освобождён, но его результаты следует считать исследованием до оформления дела и не подшивать как рабочий материал по делу.

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

Шаг 0. Барьер привилегии (запускается первым, каждый раз)

Работа над хронологией берёт данные из документов. Документы часто привилегированы (адвокатская тайна, рабочий материал адвоката, общий интерес, совместная защита): файлы дел внутри компании часто такие по умолчанию; передачи документов eDiscovery, особенно поэтапные или в рамках общего интереса, часто содержат привилегированные или непроверенные материалы. Перенос содержимого привилегированного документа в хронологию, которой потом поделятся, может *создать риск* утраты привилегии, в зависимости от того, кто её получит и по какой доктрине (могут применяться защиты общего интереса, совместной защиты, Kovel и рабочего материала). Анализ утраты привилегии зависит от фактов: получи одобрение юриста, прежде чем распространять.

Скилл не будет извлекать данные, пока пользователь не выберет режим привилегии:

Прежде чем извлекать: как источники проверены на привилегию? - A. Все источники проверены — вы уже их проверили. Я извлекаю без пометок привилегии. Результат готов к раскрытию, но всё равно помечается как рабочий материал. - B. Смешанные или ещё не проверены — я извлекаю и помечаю каждую запись флагом priv: ok (источник заведомо не привилегирован), flag (источник потенциально привилегирован — адвокатская тайна, рабочий материал, общий интерес) или review (источник неясен). Помеченные записи выделяются в результате, а вариант для изложения обстоятельств по умолчанию их отфильтровывает. - C. Прервать — сначала проверьте — приостановить скилл. Проверьте источники. Вернитесь и запустите заново.

Запиши выбор в заголовок хронологии как privilege_posture: A-cleared | B-mixed | C-aborted. При B или C коротко запиши обоснование.

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

Шаг 1. Определи источники документов

**Режим --matter:**

Пути, указанные пользователем — всё, что брошено в этой сессии (пути к файлам, ссылки на диск, экспорты почты).
Папка дела по умолчанию — из шаблона хранения документов в CLAUDE.md, раскрытого для этой метки (например, G:/Legal/Matters/acme-v-us-2026).
Заявленные источники — таблица Document storage в CLAUDE.md, отфильтрованная до тех, которых может касаться дело (например, архив Gmail для переписки отправителя, юридическая папка SharePoint).
Спроси — если источников кажется мало, уточни: «Я могу собрать хронологию по тому, что есть, но она будет неполной. Есть ли что-то ещё, на что мне указать? Ключевые письма, договоры, внутренние записки, сопроводительные письма к передаче документов?»

**Режим --documents:**

Экспорт передачи документов / набор Бейтса — пользователь указывает папку передачи или манифест; скилл читает по диапазону Бейтса и дате.
Коннектор eDiscovery — если доступен коннектор MCP (Everlaw, Relativity, DISCO, Aurora), загрузи по хранителю и диапазону дат.
Файлы хранителей — если пользователь даёт сырые почтовые ящики хранителей или экспорты дисков, читай и их.
Спроси — если охват кажется скудным для ключевого хранителя или диапазона дат, уточни.

Шаг 2. Загрузи и прочитай

Для каждого источника с читаемыми файлами:

PDF, письма (.eml), .docx, .txt — читай напрямую.
Архивы почты (Gmail, Outlook) — если коннектор MCP авторизован, запрашивай по диапазону дат + контрагент / ключевые слова; иначе пользователь экспортирует нужные цепочки писем в папку.
Платформы eDiscovery (Everlaw, Relativity, DISCO, Aurora) — если коннектор доступен, загружай по хранителю и диапазону дат; иначе пользователь даёт экспорт.

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

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

Указание источника. Помечай каждую запись хронологии тем, откуда событие взято: путь к файлу, номер Бейтса, коннектор MCP или заявленный источник хранения документов для событий, извлечённых из полученных документов (это уже отражено в столбце «Источники»). Для любого события или даты, которые нельзя связать с полученным документом (например, факт, вспомненный из обучающих данных модели, или событие из публичного реестра, найденное веб-поиском), пометь прямо в тексте: [web search — verify], [model knowledge — verify] или [user provided], если пользователь назвал факт в сессии. Записи с пометкой verify несут больший риск выдумки, чем записи из документов, и проверять их надо в первую очередь. Никогда не стирай и не сворачивай эти пометки: это самый быстрый для юриста сигнал, какие записи проверять, прежде чем переносить их в документ или изложение обстоятельств.

Пометки касаются каждого раздела, где сформулирован юридический вывод, срок или вычисленная дата, а не только записей хронологии. Хронология получена из документов. Раздел «Пробелы», раздел «Ключевые события», строки о связи с версией дела и любое утверждение об исковой давности, приостановке срока, сроке подачи, окончании раскрытия или определении привилегии — это юридический анализ, который скилл пишет из знаний модели, если источник не указан. Каждое такое утверждение несёт отметку происхождения: [computed from: <правило со своей пометкой>], [model knowledge — verify], [user provided] или пометку коннектора исследования, если получено в этой сессии. Срок исковой давности без пометки по умолчанию считается [model knowledge — verify]. Строка в «Ключевых событиях», характеризующая юридическое значение факта, — это анализ, и ей нужна пометка. Правило простое: если это утверждение о праве, а не о том, что говорит документ, оно должно нести ту же отметку происхождения, что и записи хронологии. Когда коннектор исследования недоступен, а скилл вычисляет сроки или цитирует нормы, запиши это в строку Sources: заметки для проверяющего (см. ## Outputs в CLAUDE.md плагина), не выводя отдельного баннера.

Шаг 3. Извлеки события

Для каждого документа определи датированные события:

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

Обычно одно событие на документ. Иногда ноль (без даты или событие не установлено). Иногда несколько (протокол встречи с несколькими решениями).

Флаг привилегии на каждую запись (только если privilege_posture == B-mixed). Правило трёх состояний: никогда не решай молча, что субъективный тест привилегии не выполнен:

priv: ok — источник заведомо не привилегирован (поданные документы, переписка с регуляторами, публичные документы, переписка с контрагентом без участия нашего юриста). Используется, только если нет правдоподобной теории привилегии.
priv: flag — источник заведомо или вероятно привилегирован (переписка с юристом, записки как рабочий материал, привилегированные черновики, материалы совместной защиты). Значение по умолчанию для всего неопределённого: если вывод о преобладающей цели спорный, предвидение судебного спора пограничное или содержание смешанное, это сюда, а не в ok.
priv: review — источник неясен на вид, и скилл вообще не смог принять решение (нет метаданных отправителя/получателя, нечитаем и т. д.).

При priv: flag или priv: review добавь прямо в текст [SME VERIFY: privilege status], чтобы юрист увидел это при проверке. Недостаточная пометка ведёт к утрате привилегии (односторонняя дверь); избыточную пометку юрист исправляет при проверке (двусторонняя дверь). Предпочитай поправимую ошибку.

Шаг 4. Убери дубли

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

Шаг 5. Пометь значимость — по версии дела

Прочитай ключевой факт и основные факты из matter.md (режим --matter) или из раздела ## Case theory конфигурации (режим --documents). Пометь каждое событие:

🔴 Ключевое — событие входит в ключевой факт или является основным фактом за нас или против нас
🟡 Значимое — контекст, свидетельство закономерности, поддерживает второстепенный довод
⚪ Фон — полезно для полноты, в документ не пойдёт

Дисциплина: хронология из 300 записей с 300 пометками 🔴 не имеет пометок. Оставляй 🔴 для событий, которые действительно сдвинули бы позицию суда, оценивающего факты. В сомнении ставь 🟡.

Пограничные пометки: когда запись находится между 🔴 и 🟡 (или между 🟡 и ⚪), ставь меньшую значимость и добавляй прямо в текст [SME VERIFY — borderline significance call]. Суждение юриста перекроет оценку скилла. Хронология, уверенно завышающая значимость, менее полезна, чем та, что показывает свою неуверенность.

Шаг 6. Запиши

Результат по умолчанию — рабочая хронология. Варианты — по запросу.

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

Рабочая хронология (по умолчанию)

Расположение: ~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md. Полная, с пометками, с примечаниями. Справочный документ, с которым работает юрист.

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

> **Наследование привилегии.** Эта хронология составлена из документов дела, которые могут быть защищены адвокатской тайной, рабочим материалом адвоката, быть материалами общего интереса / совместной защиты или смесью этого. Она наследует статус защиты источников. Распространение за пределы круга привилегии — бизнес-заинтересованным лицам вне поручения, юристам противоположной стороны, регулятору — может привести к утрате защиты как хронологии, так и исходных источников. Храни вместе с привилегированными материалами дела, помечай согласно принятым в фирме правилам привилегии и принимай решения о распространении осознанно. Выбранный ниже режим привилегии — это отметка происхождения для любого решения о последующем распространении.

# Хронология — [название дела]

> Пометки значимости (🔴/🟡/⚪) и флаги привилегии (🔒) — первичная оценка, требующая `[SME VERIFY]` перед использованием в любом внешнем рабочем материале (документах, изложении обстоятельств, записке совету директоров, материале для внешнего юриста).

**Дело:** [slug]
**Режим:** matter | documents
**Составлена:** [ГГГГ-ММ-ДД]
**Источники:** [N] документов из [типы источников]
**Записей:** [N] ([N] 🔴 / [N] 🟡 / [N] ⚪)
**Ключевой факт:** [одно предложение]
**Режим привилегии:** A-cleared | B-mixed | C-aborted
**Помеченных записей:** [N] 🔒 *(присутствует только при режиме B-mixed)*

---

## Хронология

| Дата | Событие | Пометка | 🔒 | Источники |
|---|---|---|---|---|
| [ГГГГ-ММ-ДД] | [что произошло, одно предложение] | 🔴/🟡/⚪ | [пусто / 🔒-flag / 🔒-review] | [пути к файлам или номера Бейтса] |

---

## Ключевые события (только 🔴)

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

### [дата] — [название события]
- Что: [одна строка]
- Связь с версией: [почему это важно]
- Источники: [список]

---

## Пробелы

**Диапазоны дат без событий:**
[диапазоны — где документы за этот период?]

**Ожидалось, но отсутствует:**
[события, которые мы ожидали бы увидеть задокументированными, но их нет — например, «изменения к договору между 2024-06 и 2025-03 — не переданы»]

**Нечитаемые источники:**
[источники, заявленные в CLAUDE.md, но недоступные при этом запуске — например, «передача документов Everlaw — нет коннектора MCP; нужен экспорт»]

---

## Дисциплина пометок

- `[VERIFY: фактическое утверждение — дата, участники, содержание]` — ещё не подтверждено по исходному документу
- `[UNCERTAIN: правовая квалификация — например, создаёт ли событие регуляторный триггер]`
- `[CITE NEEDED: номер Бейтса / приложение / страница:строка депозиции]`
- `[SME VERIFY: privilege status | borderline significance call]` — нужно суждение юриста

---

## Версия
- v[N] составлена [дата] из [краткое описание источников]
- v[N-1] составлена [дата] (предыдущая, заменена)

Хронология для изложения обстоятельств (по запросу)

Отфильтруй до 🔴 и значимых 🟡. Подай прозой в хронологическом порядке повествования — это каркас фактического раздела документа. Каждый абзац — одно событие или тесно связанная группа, со ссылками на материалы дела.

Фильтр привилегии по умолчанию: при privilege_posture == B-mixed записи с флагами 🔒 и 🔒-review по умолчанию исключаются. Вариант для изложения обстоятельств предназначен для последующего внешнего использования (документы, раскрытие, переговоры с контрагентом) — записям 🔒 там не место, пока юрист не подтвердит статус привилегии. Если пользователь всё же хочет включить записи 🔒, требуй явного подтверждения флагом --include-flagged; зафиксируй это подтверждение в заголовке результата как постоянную запись.

Хронология по конкретному свидетелю (по запросу)

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

Постепенное наращивание

Если chronology.md уже существует:

Прочитай прежнюю версию
Построй новую хронологию по текущим источникам
Сравни: новые события (с прошлой сборки), изменённые записи (к существующим событиям добавлены источники), удалённые записи (редко; отметь, почему)
Сохрани номер прежней версии; запиши новую версию как v[N+1]
Выведи краткое описание того, что изменилось

Связь с matter.md / history.md

Намеренно разделены (режим --matter для корпоративного юриста). history.md — текущий журнал юриста: решения, обновления, процессуальные вехи, внутренние стратегические заметки. chronology.md — хронология фактов для аргументации. Они пересекаются, но не сливаются:

Введён режим сохранения документов → записывается в history.md (внутреннее действие). В хронологию обычно не попадает (это не факт спора).
Контрагент направил уведомление о нарушении 14 марта → записывается в chronology.md (🟡: устанавливает его осведомлённость). Также в history.md, если приём ссылался на это.
Составлена наша записка с рекомендацией по резерву → только history.md.

Когда юрист хочет видеть события из history в хронологии, он может их вставить. По умолчанию они остаются раздельными.

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

Не разрешает противоречия. Когда два документа говорят разное о том, когда произошло событие, в хронологию идут обе записи с флагом. Разрешение — на усмотрение юриста; может потребоваться беседа со свидетелем или дальнейшее раскрытие.
Не придумывает события, которых нет в источниках. Если события нет в документах (и нет в matter.md или в конфигурации как зафиксированного факта), его нет в хронологии, но «Пробелы» могут указать на то, что его не хватает.
Не гарантирует полноту. Хронология хороша ровно настолько, насколько хороши источники. Если передача документов eDiscovery продолжается и пришло всего 20%, хронология это отражает. Назови это ограничение.
Не решает за пользователя вопрос о привилегии. Барьер шага 0 заставляет выбрать режим; флаг priv у каждой записи фиксирует первичную классификацию. Окончательные определения привилегии — на усмотрение юриста по флагам [SME VERIFY].

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

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

---
name: chronology
description: Build or update a chronology from declared document sources and uploads — dated events extracted, de-duped, and tagged by significance per the matter theory. Use when the user asks to build a chronology or timeline from a production or matter file, says "chron from the production" or "what happened when", or needs a working, statement-of-facts, or witness-specific timeline.
argument-hint: "[slug] [--format=working|sof|witness-[name]]"
---

# /chronology

1. Load `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md` → theory, pivot fact, key facts.
2. Load `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md` → Document storage sources, default matter folder pattern.
3. Follow the workflow and reference below.
4. Identify sources in order: user-provided paths this session, default matter folder, declared sources from `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md`.
5. For readable sources: extract dated events. For unreachable sources: note in Gaps.
6. De-dupe, merge with sources list per event.
7. Tag significance (🔴/🟡/⚪) per matter theory.
8. Write `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md` (or format variant per flag).
9. If prior version exists: version number increments, diff summary presented to user.
10. Confirm before finalizing: "Here's what I built. Scan the 🔴 entries — anything I miscalled?"

---

# Chronology

## Disclosed-document use restrictions

Before working with a set of litigation documents, ask: "Were any of these documents obtained through disclosure or discovery in legal proceedings?" If yes:

- **England & Wales (CPR 31.22):** Documents obtained through disclosure are subject to the implied undertaking — you may only use them for the purpose of the proceedings in which they were disclosed, unless the court grants permission, the disclosing party consents, or the document has been read in open court. Using them for a different matter, a different claim, or a commercial purpose without permission is a contempt.
- **US:** Protective orders and Rule 26(c) may impose similar restrictions. Check the order.
- **Other jurisdictions:** Similar restrictions commonly apply. Check the local rule.

Confirm: "This use is within the proceedings in which the documents were disclosed, or I have permission / consent, or the documents are now public." If not confirmed, flag it: "⚠️ Disclosed documents may have use restrictions. Confirm this use is permitted before proceeding."

## Purpose

Facts happen in order. The chronology is the spine every narrative hangs on — the statement of facts in a brief, reserve memos, settlement memos, depo prep, witness prep. Building a chron by hand is slow; AI is good at structured extraction. The catch: garbage-in, garbage-out. This skill pulls from the sources the configuration declares and from whatever the user uploads.

## Modes

This skill serves two practice settings. Pick a default from the user's `## Role` in the plugin's configuration CLAUDE.md; the user can override per-run with a flag.

- **`--matter` mode (default for in-house litigation counsel).** Matter-history-focused. Reads the matter's case theory and key facts from `matter.md`, pulls from declared document-storage sources (Google Drive, SharePoint, Gmail, iManage, CLM — whatever the `## Landscape` section of CLAUDE.md declares), and treats `history.md` as the running internal log (decisions, holds, reserve memos — intentionally not in the chronology). Output is matter-centric: what happened across the dispute, tagged for advocacy use.
- **`--documents` mode (default for firm associate / paralegal).** Production-document-focused. Reads the case theory from the configuration, then extracts from an eDiscovery export, a custodial file set, or a Bates-numbered production. Output is production-centric: what the documents show, with Bates citations, tagged per the case theory.

Both modes converge on the same output structure (timeline, 🔴/🟡/⚪ significance tags, gaps, SoF variant). The difference is the source profile and the significance frame.

If `## Role` is `solo` or `other`, default to `--matter` but mention both modes on the first run and let the user pick.

## Side framing (significance tags)

The same event is significant in different ways depending on whether the practitioner is proving a claim or disproving it. Read `## Side` in the practice profile (and the per-matter posture if the matter overrides the default):

- **Plaintiff (offensive framing)** — 🔴 marks events that *establish* elements of the claim (liability, causation, damages, notice), *close* gaps the defense will try to open, or *start* statute-of-limitations clocks in the plaintiff's favor. 🟡 marks events that support the claim but are subject to impeachment. ⚪ is background context.
- **Defense (defensive framing)** — 🔴 marks events that *break* elements of the claim (failure of causation, notice, reliance), *open* statute-of-limitations or jurisdictional defenses, or *support* affirmative defenses (release, waiver, assumption of risk, comparative fault). 🟡 marks events that undermine the plaintiff's narrative. ⚪ is background.
- **Both / varies** — ask the user per-chronology which side's framing to apply for significance tags. The underlying timeline is side-neutral; only the significance read changes.

Note the applied framing at the top of the output: `Significance tags applied from [plaintiff / defense] perspective.` When producing a Statement of Facts variant, use the side default unless the user specifies otherwise.

## Load context

Common:
- Plugin configuration CLAUDE.md → case theory context (in-house: `## Landscape` for document sources; firm associate: `## Case theory` and `## Document review` for platform + custodians), `## Outputs` for the work-product header, `## Decision posture` for the privilege-flagging rule.
- Prior `chronology.md` for this matter, if it exists.
- Any files the user uploads or paths they provide in-session.

`--matter` mode also reads:
- `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md` → case theory, key facts, pivot fact (for significance tagging), key dates.
- Default matter folder pattern from CLAUDE.md → where docs for this slug live.

`--documents` mode also reads:
- eDiscovery platform metadata if a connector is available (Everlaw, Relativity, DISCO, Aurora) — by custodian + date range.
- Bates-range manifest or production index if the user points at one.

**Conflicts gate — unbypassable (`--matter` mode).** Before building the chronology, check `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml` for the matter slug. If the matter is not in `_log.yaml`, refuse and route:

> "I don't see [matter slug] in the matter log. Run `/litigation-legal:matter-intake` first so the conflicts check runs and the matter workspace is set up. I won't build a chronology on a matter that hasn't been intaken — the conflicts check is the gate."

Do not proceed on an unintaken matter. Intake is what runs conflicts and writes the `_log.yaml` row this skill reads from. `--documents` mode (running against an ad-hoc document set without a matter slug) is exempt from the gate, but its outputs should be treated as pre-matter research and not filed as if matter work product.

## Workflow

### Step 0: Privilege gate (runs first, every time)

Chronology work pulls from documents. Documents are often privileged (attorney-client, work product, common interest, joint defense) — in-house matter files often are by default; eDiscovery productions, especially rolling productions or common-interest productions, often contain privileged or unreviewed material. Extracting content from a privileged document into a chronology that later gets shared can *risk* waiver, depending on who receives it and under what doctrine (common-interest, joint-defense, Kovel, and work-product protections may apply). Waiver analysis is fact-specific — get counsel sign-off before distributing.

The skill will not extract until the user picks a privilege posture:

> Before I extract: how have the sources been privilege-screened?
>
> - **A. All sources cleared** — you've already screened these. I extract without privilege flags. Output is discovery-ready posture; still marked work product.
>
> - **B. Mixed or not yet screened** — I extract and tag every entry with a `priv` flag: `ok` (sourced from clearly non-privileged material), `flag` (sourced from potentially privileged material — A/C, WP, common interest), or `review` (source unclear). Flagged entries are visually marked in the output, and the Statement-of-Facts variant filters them out by default.
>
> - **C. Abort — screen first** — pause the skill. Screen the sources. Return and re-run.

Record the choice in the chronology header as `privilege_posture: A-cleared | B-mixed | C-aborted`. If B or C, record the rationale briefly.

**Why a gate and not just a warning:** a warning gets read once and forgotten. A gate forces the posture decision into the record, which means every chronology file carries its own provenance — anyone reading it later knows whether entries were derived from privilege-screened material.

### Step 1: Identify document sources

**`--matter` mode:**

1. **User-provided paths** — anything dropped in this session (file paths, drive links, email exports).
2. **Default matter folder** — from CLAUDE.md's document-storage pattern, expanded for this slug (e.g., `G:/Legal/Matters/acme-v-us-2026`).
3. **Declared sources** — the `Document storage` table in CLAUDE.md, filtered to ones this matter might touch (e.g., Gmail archive for sender-side communications, SharePoint legal folder).
4. **Ask** — if sources look thin, prompt: "I can build from what I have, but the chronology will be incomplete. Anything else to point me at? Key emails, contracts, internal memos, production letters?"

**`--documents` mode:**

1. **Production export / Bates set** — the user points at the production directory or a manifest; the skill reads by Bates range + date.
2. **eDiscovery connector** — if an MCP connector is available (Everlaw, Relativity, DISCO, Aurora), pull by custodian + date range.
3. **Custodial files** — if the user provides raw custodial mailboxes or drive exports, read those too.
4. **Ask** — if coverage looks thin for a key custodian or date range, prompt.

### Step 2: Pull + read

For each source with readable files:

- **PDFs, emails (.eml), .docx, .txt** — read directly.
- **Email archives (Gmail, Outlook)** — if an MCP connector is authenticated, query by date range + counterparty / key terms; otherwise the user exports relevant threads to a folder.
- **eDiscovery platforms (Everlaw, Relativity, DISCO, Aurora)** — if connector is available, pull by custodian + date range; otherwise the user provides an export.

If the skill can't access a declared source, name it explicitly in the output's Gaps section rather than silently proceeding.

**No silent supplement.** If source coverage for an era of the matter is thin — fewer documents than expected for a claimed time window, a custodian whose mailbox isn't accessible, a production that hasn't landed — report what was found and stop. Do NOT fill gaps from web search, public record search, or model knowledge about the matter without asking. Say: "Sources returned [N] events for [period / custodian]. Coverage appears thin. Options: (1) point me at additional sources (Bates, folder, mailbox), (2) try a different MCP connector if configured, (3) search the web for public-record events in this window — results will be tagged `[web search — verify]` and should be checked against a primary source before relying, or (4) stop here and note the gap. Which would you like?" A lawyer decides whether to accept lower-confidence sources; the skill does not decide for them.

**Source attribution.** Tag every chronology entry with where the event came from: the file path, Bates number, MCP connector, or declared document-storage source for events extracted from retrieved documents (already captured in the Sources column). For any event or date that cannot be traced to a retrieved document — e.g., a fact recalled from model training data, a public-record event found via web search — tag it inline: `[web search — verify]`, `[model knowledge — verify]`, or `[user provided]` where the user stated the fact in-session. Entries tagged `verify` carry higher fabrication risk than document-sourced entries and should be checked first. Never strip or collapse the tags — they are counsel's fastest signal about which entries to verify before pulling them into a brief or SoF.

**Tagging reaches every section that states a legal conclusion, deadline, or computed date — not just timeline entries.** The timeline is sourced from documents. The Gaps section, the Key events section, the Theory tie lines, and any statement of limitations, tolling event, filing deadline, discovery cutoff, or privilege determination are legal analysis the skill writes from model knowledge unless sourced. Every such statement carries a provenance tag: `[computed from: <rule cited with tag>]`, `[model knowledge — verify]`, `[user provided]`, or a research-connector tag if retrieved in this session. A statute-of-limitations window with no tag defaults to `[model knowledge — verify]`. A "key event" line that characterizes a fact's legal significance is analysis and needs the tag. The rule is simple: if it's an assertion about the law, not an assertion about what a document says, it must carry the same provenance tag the timeline entries do. When no research connector is reachable and the skill is computing deadlines or citing rules, record it in the **Sources:** line of the reviewer note (see plugin CLAUDE.md `## Outputs`) — do not emit a standalone banner.

### Step 3: Extract events

For each document, identify dated events:

- **Email:** `[date] [sender] told [recipient] [subject/content]`
- **Meeting:** `[date] [attendees] met about [topic]` (per calendar entry or notes)
- **Decision:** `[date] [decision-maker] decided [what]` (per memorializing doc)
- **Filing / pleading:** `[date] [party] filed [motion/complaint/response]`
- **External event:** `[date] [thing happened]` (contract signed, product launched, regulator acted, event crossed a threshold)

One event per document usually. Occasionally zero (undated or no event established). Sometimes multiple (meeting summary covering several decisions).

**Privilege flag per entry (only when privilege_posture == B-mixed). Three-state rule — never silently decide a subjective privilege test isn't met:**

- `priv: ok` — source is **confidently** non-privileged (filings, regulatory correspondence, public docs, counterparty communications without our counsel). Used only when there's no plausible privilege theory.
- `priv: flag` — source is confidently or likely privileged (communications with counsel, work-product memos, privileged drafts, joint-defense material). **Default for anything uncertain** — if the dominant-purpose call is close, or litigation contemplation is borderline, or the content is mixed, it goes here, not in `ok`.
- `priv: review` — source unclear on its face, but the skill could not make the call at all (no sender/recipient metadata, unreadable, etc.).

When `priv: flag` or `priv: review`, add `[SME VERIFY: privilege status]` inline so the counsel sees it during review. Under-flagging waives privilege (one-way door); over-flagging is corrected by counsel in review (two-way door). Prefer the recoverable error.

### Step 4: De-dupe

The same event surfaces in multiple documents: a meeting is on three calendars and produces a summary email — that's **one event with four sources**, not four events. Merge. The merged entry cites all sources.

### Step 5: Tag significance — per case theory

Read the pivot fact and key facts from `matter.md` (`--matter` mode) or from the configuration's `## Case theory` section (`--documents` mode). Tag each event:

- 🔴 **Key** — event is part of the pivot fact or a key fact for/against us
- 🟡 **Relevant** — context, pattern evidence, supports a secondary argument
- ⚪ **Background** — useful for completeness, not going in the brief

**Discipline:** a chronology of 300 entries with 300 🔴 tags has no tags. Reserve 🔴 for events that would genuinely move a factfinder. If in doubt, 🟡.

**Borderline tagging:** when an entry sits between 🔴 and 🟡 (or 🟡 and ⚪), tag at the lower significance and add `[SME VERIFY — borderline significance call]` inline. Counsel's judgment will override the skill's call. A chronology that confidently over-tags is less useful than one that surfaces its uncertainty.

### Step 6: Write

Default output is the working chronology. Variants on request.

## Output formats

### Working chronology (default)

Location: `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md`. Complete, tagged, annotated. The reference doc counsel works from.

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

> **Privilege inheritance.** This chronology is derived from matter documents that may be attorney-client-privileged, work-product-protected, common-interest / joint-defense material, or a mix. It inherits the sources' protection status. Distributing it beyond the privilege circle — to business stakeholders outside the engagement, to opposing counsel, to a regulator — can waive protection over both the chronology and the underlying sources. Store with privileged matter material, mark consistently with house privilege conventions, and make distribution decisions deliberately. The privilege-posture choice captured below is the provenance stamp for any later distribution call.

# Chronology — [Matter Name]

> Significance tags (🔴/🟡/⚪) and privilege flags (🔒) are first-pass reads requiring `[SME VERIFY]` before use in any external work product (briefs, SoF, board memo, outside counsel deliverable).

**Matter:** [slug]
**Mode:** matter | documents
**Built:** [YYYY-MM-DD]
**Sources:** [N] documents across [source types]
**Entries:** [N] ([N] 🔴 / [N] 🟡 / [N] ⚪)
**Pivot fact:** [one sentence]
**Privilege posture:** A-cleared | B-mixed | C-aborted
**Flagged entries:** [N] 🔒 *(only present when posture == B-mixed)*

---

## Timeline

| Date | Event | Tag | 🔒 | Sources |
|---|---|---|---|---|
| [YYYY-MM-DD] | [what happened, one sentence] | 🔴/🟡/⚪ | [blank / 🔒-flag / 🔒-review] | [file paths or Bates] |

---

## Key events (🔴 only)

[Pulled out, each with a line on why it matters to the theory.]

### [date] — [event title]
- What: [one line]
- Theory tie: [why this matters]
- Sources: [list]

---

## Gaps

**Date ranges with no events:**
[ranges — where are documents for this period?]

**Expected but missing:**
[events we'd expect to see documented but don't — e.g., "contract amendments between 2024-06 and 2025-03 — not produced"]

**Unreadable sources:**
[sources declared in CLAUDE.md but not accessible this run — e.g., "Everlaw production — no MCP connector; export needed"]

---

## Marker discipline

- `[VERIFY: factual assertion — date, attendees, content]` — not yet confirmed against the underlying doc
- `[UNCERTAIN: legal characterization — e.g., whether an event establishes a regulatory trigger]`
- `[CITE NEEDED: Bates / exhibit / depo page:line]`
- `[SME VERIFY: privilege status | borderline significance call]` — counsel judgment needed

---

## Version
- v[N] built on [date] from [source summary]
- v[N-1] built on [date] (prior, superseded)
```

### Statement-of-facts chronology (on request)

Filter to 🔴 and relevant 🟡 only. Present as prose in chronological narrative order — the skeleton for a brief's fact section. Each paragraph is one event or tightly linked cluster, with record citations.

**Privilege filter default:** when `privilege_posture == B-mixed`, 🔒-flagged and 🔒-review entries are **excluded** by default. The SoF variant is intended for eventual external use (briefs, disclosures, negotiating counterparty) — 🔒 entries don't belong there until counsel confirms privilege status. If the user wants 🔒 entries included anyway, require explicit `--include-flagged` acknowledgment; capture the acknowledgment in the output header as permanent record.

### Witness-specific chronology (on request)

Filter to events where a named witness is sender, recipient, attendee, or subject. Feeds witness prep and helps reconstruct what a witness knew when.

## Incremental builds

If `chronology.md` exists:

- Read prior version
- Build new chronology from current sources
- Diff: new events (since last build), modified entries (new sources added to existing events), removed entries (rare; note why)
- Preserve the prior version number; write new version with `v[N+1]`
- Output summary of what changed

## Integration with matter.md / history.md

**Intentionally separate** (in-house `--matter` mode). `history.md` is counsel's running log — decisions, updates, procedural milestones, internal strategy notes. `chronology.md` is the advocacy-facing timeline of facts. They overlap but don't merge:

- A hold was issued → goes in history.md (internal action). Usually not in chronology (not a fact of the dispute).
- The counterparty sent a breach notice on March 14 → goes in chronology.md (🟡 — establishes their knowledge). Also in history.md if the intake referenced it.
- Our reserve recommendation memo was drafted → history.md only.

When counsel wants history events in the chronology, they can paste them. The default is they stay separate.

## What this skill does not do

- **Resolve contradictions.** When two documents say different things about when an event happened, both entries go in with a flag. Resolution is counsel's call; may require witness interview or further discovery.
- **Invent events not in the sources.** If it's not in the documents (and not in matter.md or the configuration as a captured fact), it's not in the chronology — but "Gaps" might call it out as missing.
- **Guarantee completeness.** A chronology is only as good as the sources. If the eDiscovery production is ongoing and only 20% has landed, the chronology reflects that. Name the limitation.
- **Decide privilege status for the user.** The Step 0 gate forces the posture choice; the per-entry `priv` flag captures first-pass classification. Actual privilege determinations are counsel's call per `[SME VERIFY]` flags.

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

---
name: chronology
description: Составь или обнови хронологию по заявленным источникам документов и загруженным файлам: датированные события извлекаются, очищаются от дублей и помечаются по значимости согласно версии дела. Используй, когда пользователь просит составить хронологию или временную шкалу по переданным документам или файлу дела, говорит «хронология по переданным документам» или «что когда произошло», либо ему нужна рабочая хронология, хронология для изложения обстоятельств или хронология по конкретному свидетелю.
argument-hint: "[slug] [--format=working|sof|witness-[name]]"
---

# /chronology

1. Загрузи `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md` → версия дела, ключевой факт (pivot fact), основные факты.
2. Загрузи `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md` → источники хранения документов, шаблон папки дела по умолчанию.
3. Следуй рабочему процессу и справке ниже.
4. Определи источники по порядку: пути, указанные пользователем в этой сессии, папка дела по умолчанию, источники, заявленные в `~/.claude/plugins/config/claude-for-legal/litigation-legal/CLAUDE.md`.
5. Из читаемых источников: извлеки датированные события. О недоступных источниках: запиши в «Пробелах».
6. Убери дубли, объедини источники по каждому событию.
7. Пометь значимость (🔴/🟡/⚪) по версии дела.
8. Запиши `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md` (или вариант формата по флагу).
9. Если есть прежняя версия: номер версии увеличивается, пользователю показывается краткое описание отличий.
10. Подтверди перед завершением: «Вот что я собрал. Просмотрите записи 🔴: не ошибся ли я где-нибудь?»

---

# Хронология

## Ограничения на использование раскрытых документов

Прежде чем работать с набором судебных документов, спроси: «Были ли какие-либо из этих документов получены в порядке раскрытия или обмена доказательствами (disclosure / discovery) в судебном производстве?» Если да:

- **Англия и Уэльс (CPR 31.22):** на документы, полученные при раскрытии, распространяется подразумеваемое обязательство: их можно использовать только для целей того производства, в котором они раскрыты, если только суд не даст разрешение, раскрывающая сторона не согласится или документ не был зачитан в открытом заседании. Использование их по другому делу, другому требованию или в коммерческих целях без разрешения — неуважение к суду (contempt).
- **США:** защитные определения (protective orders) и Rule 26(c) могут вводить похожие ограничения. Проверь определение.
- **Другие юрисдикции:** обычно действуют похожие ограничения. Проверь местное правило.

Подтверди: «Это использование укладывается в производство, в котором документы были раскрыты, либо у меня есть разрешение / согласие, либо документы теперь публичны». Если не подтверждено, пометь: «⚠️ На раскрытые документы могут действовать ограничения использования. Убедитесь, что такое использование разрешено, прежде чем продолжать».

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

Факты происходят по порядку. Хронология — это позвоночник, на который нанизывается любой рассказ: изложение обстоятельств в документе, записки о резервах, записки об урегулировании, подготовка к депозициям и к допросу свидетелей. Собирать хронологию вручную медленно; ИИ хорошо справляется со структурным извлечением. Но есть оговорка: мусор на входе — мусор на выходе. Этот скилл берёт данные из источников, заявленных в конфигурации, и из всего, что загрузит пользователь.

## Режимы

Этот скилл обслуживает две практические среды. Выбери режим по умолчанию по полю `## Role` пользователя в `CLAUDE.md` конфигурации плагина; пользователь может переопределить его флагом при каждом запуске.

- **Режим `--matter` (по умолчанию для корпоративного юриста по спорам).** Ориентирован на историю дела. Читает версию дела и основные факты из `matter.md`, берёт данные из заявленных источников хранения документов (Google Drive, SharePoint, Gmail, iManage, CLM — всё, что объявлено в разделе `## Landscape` файла CLAUDE.md) и считает `history.md` текущим внутренним журналом (решения, режимы сохранения документов, записки о резервах — намеренно не входят в хронологию). Результат ориентирован на дело: что происходило по всему спору, с пометками для использования в аргументации.
- **Режим `--documents` (по умолчанию для ассоциата / помощника юриста фирмы).** Ориентирован на переданные документы. Читает версию дела из конфигурации, затем извлекает данные из экспорта eDiscovery, набора файлов хранителей (custodians) или пронумерованной по Бейтсу передачи документов (production). Результат ориентирован на передачу документов: что показывают документы, со ссылками на номера Бейтса, с пометками по версии дела.

Оба режима сходятся в одной структуре результата (хронология, пометки значимости 🔴/🟡/⚪, пробелы, вариант для изложения обстоятельств). Различие — в профиле источников и в рамке значимости.

Если `## Role` — `solo` или `other`, по умолчанию выбери `--matter`, но при первом запуске назови оба режима и дай пользователю выбрать.

## Рамка стороны (пометки значимости)

Одно и то же событие значимо по-разному в зависимости от того, доказывает ли практик требование или опровергает его. Прочитай `## Side` в профиле практики (и позицию по конкретному делу, если дело переопределяет значение по умолчанию):

- **Истец (наступательная рамка)** — 🔴 отмечает события, которые *устанавливают* элементы требования (ответственность, причинную связь, ущерб, уведомление), *закрывают* пробелы, которые попытается открыть защита, или *запускают* течение срока исковой давности в пользу истца. 🟡 отмечает события, которые поддерживают требование, но уязвимы для оспаривания. ⚪ — фоновый контекст.
- **Защита (оборонительная рамка)** — 🔴 отмечает события, которые *ломают* элементы требования (отсутствие причинной связи, уведомления, доверия), *открывают* защиту по сроку исковой давности или юрисдикции либо *поддерживают* возражения по существу (освобождение, отказ от права, принятие риска, сопутствующая вина). 🟡 отмечает события, которые подрывают рассказ истца. ⚪ — фон.
- **Обе / по-разному** — спроси пользователя для каждой хронологии, чью рамку применять к пометкам значимости. Сама хронология нейтральна к стороне; меняется только чтение значимости.

Укажи применённую рамку в начале результата: `Significance tags applied from [plaintiff / defense] perspective.` При подготовке варианта для изложения обстоятельств используй сторону по умолчанию, если пользователь не укажет иное.

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

Общее:
- `CLAUDE.md` конфигурации плагина → контекст версии дела (корпоративный юрист: `## Landscape` для источников документов; ассоциат фирмы: `## Case theory` и `## Document review` для платформы и хранителей), `## Outputs` для заголовка рабочего материала, `## Decision posture` для правила пометки привилегированных материалов.
- Прежний `chronology.md` по этому делу, если он есть.
- Любые файлы, которые пользователь загружает, или пути, которые он даёт в сессии.

Режим `--matter` дополнительно читает:
- `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/matter.md` → версия дела, основные факты, ключевой факт (для пометок значимости), ключевые даты.
- Шаблон папки дела по умолчанию из CLAUDE.md → где лежат документы для этой метки.

Режим `--documents` дополнительно читает:
- метаданные платформы eDiscovery, если доступен коннектор (Everlaw, Relativity, DISCO, Aurora) — по хранителю и диапазону дат.
- Манифест диапазонов Бейтса или указатель передачи документов, если пользователь на него указывает.

**Барьер конфликта интересов — обойти нельзя (режим `--matter`).** Перед построением хронологии проверь `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/_log.yaml` на метку дела. Если дела нет в `_log.yaml`, откажись и перенаправь:

> «Я не вижу [метка дела] в журнале дел. Сначала запустите `/litigation-legal:matter-intake`, чтобы выполнилась проверка конфликта интересов и было настроено рабочее пространство дела. Я не буду строить хронологию по делу, которое не прошло приём: проверка конфликта интересов — это барьер».

Не продолжай по делу, которое не прошло приём. Приём запускает проверку конфликта интересов и записывает строку в `_log.yaml`, которую читает этот скилл. Режим `--documents` (работа с произвольным набором документов без метки дела) от барьера освобождён, но его результаты следует считать исследованием до оформления дела и не подшивать как рабочий материал по делу.

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

### Шаг 0. Барьер привилегии (запускается первым, каждый раз)

Работа над хронологией берёт данные из документов. Документы часто привилегированы (адвокатская тайна, рабочий материал адвоката, общий интерес, совместная защита): файлы дел внутри компании часто такие по умолчанию; передачи документов eDiscovery, особенно поэтапные или в рамках общего интереса, часто содержат привилегированные или непроверенные материалы. Перенос содержимого привилегированного документа в хронологию, которой потом поделятся, может *создать риск* утраты привилегии, в зависимости от того, кто её получит и по какой доктрине (могут применяться защиты общего интереса, совместной защиты, Kovel и рабочего материала). Анализ утраты привилегии зависит от фактов: получи одобрение юриста, прежде чем распространять.

Скилл не будет извлекать данные, пока пользователь не выберет режим привилегии:

> Прежде чем извлекать: как источники проверены на привилегию?
>
> - **A. Все источники проверены** — вы уже их проверили. Я извлекаю без пометок привилегии. Результат готов к раскрытию, но всё равно помечается как рабочий материал.
>
> - **B. Смешанные или ещё не проверены** — я извлекаю и помечаю каждую запись флагом `priv`: `ok` (источник заведомо не привилегирован), `flag` (источник потенциально привилегирован — адвокатская тайна, рабочий материал, общий интерес) или `review` (источник неясен). Помеченные записи выделяются в результате, а вариант для изложения обстоятельств по умолчанию их отфильтровывает.
>
> - **C. Прервать — сначала проверьте** — приостановить скилл. Проверьте источники. Вернитесь и запустите заново.

Запиши выбор в заголовок хронологии как `privilege_posture: A-cleared | B-mixed | C-aborted`. При B или C коротко запиши обоснование.

**Почему барьер, а не просто предупреждение:** предупреждение читают один раз и забывают. Барьер заставляет внести решение о режиме привилегии в записи, а значит, каждый файл хронологии несёт собственное происхождение: любой, кто читает его позже, знает, получены ли записи из проверенных на привилегию материалов.

### Шаг 1. Определи источники документов

**Режим `--matter`:**

1. **Пути, указанные пользователем** — всё, что брошено в этой сессии (пути к файлам, ссылки на диск, экспорты почты).
2. **Папка дела по умолчанию** — из шаблона хранения документов в CLAUDE.md, раскрытого для этой метки (например, `G:/Legal/Matters/acme-v-us-2026`).
3. **Заявленные источники** — таблица `Document storage` в CLAUDE.md, отфильтрованная до тех, которых может касаться дело (например, архив Gmail для переписки отправителя, юридическая папка SharePoint).
4. **Спроси** — если источников кажется мало, уточни: «Я могу собрать хронологию по тому, что есть, но она будет неполной. Есть ли что-то ещё, на что мне указать? Ключевые письма, договоры, внутренние записки, сопроводительные письма к передаче документов?»

**Режим `--documents`:**

1. **Экспорт передачи документов / набор Бейтса** — пользователь указывает папку передачи или манифест; скилл читает по диапазону Бейтса и дате.
2. **Коннектор eDiscovery** — если доступен коннектор MCP (Everlaw, Relativity, DISCO, Aurora), загрузи по хранителю и диапазону дат.
3. **Файлы хранителей** — если пользователь даёт сырые почтовые ящики хранителей или экспорты дисков, читай и их.
4. **Спроси** — если охват кажется скудным для ключевого хранителя или диапазона дат, уточни.

### Шаг 2. Загрузи и прочитай

Для каждого источника с читаемыми файлами:

- **PDF, письма (.eml), .docx, .txt** — читай напрямую.
- **Архивы почты (Gmail, Outlook)** — если коннектор MCP авторизован, запрашивай по диапазону дат + контрагент / ключевые слова; иначе пользователь экспортирует нужные цепочки писем в папку.
- **Платформы eDiscovery (Everlaw, Relativity, DISCO, Aurora)** — если коннектор доступен, загружай по хранителю и диапазону дат; иначе пользователь даёт экспорт.

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

**Никаких тихих добавок.** Если охват источников по какому-то периоду дела скуден — документов меньше, чем ожидалось для заявленного периода, у хранителя недоступен почтовый ящик, передача документов ещё не поступила, — сообщи, что найдено, и остановись. НЕ заполняй пробелы веб-поиском, поиском по публичным реестрам или знаниями модели об этом деле, не спросив. Скажи: «Источники дали [N] событий за [период / хранитель]. Охват, похоже, слабый. Варианты: (1) укажите дополнительные источники (Бейтс, папку, почтовый ящик), (2) попробуйте другой коннектор MCP, если настроен, (3) поищите в вебе события из публичных реестров за этот период — результаты будут помечены `[web search — verify]` и перед использованием их нужно сверить с первоисточником, или (4) остановиться здесь и отметить пробел. Что выберете?» Решает, принимать ли источники с меньшей надёжностью, юрист; скилл за него не решает.

**Указание источника.** Помечай каждую запись хронологии тем, откуда событие взято: путь к файлу, номер Бейтса, коннектор MCP или заявленный источник хранения документов для событий, извлечённых из полученных документов (это уже отражено в столбце «Источники»). Для любого события или даты, которые нельзя связать с полученным документом (например, факт, вспомненный из обучающих данных модели, или событие из публичного реестра, найденное веб-поиском), пометь прямо в тексте: `[web search — verify]`, `[model knowledge — verify]` или `[user provided]`, если пользователь назвал факт в сессии. Записи с пометкой `verify` несут больший риск выдумки, чем записи из документов, и проверять их надо в первую очередь. Никогда не стирай и не сворачивай эти пометки: это самый быстрый для юриста сигнал, какие записи проверять, прежде чем переносить их в документ или изложение обстоятельств.

**Пометки касаются каждого раздела, где сформулирован юридический вывод, срок или вычисленная дата, а не только записей хронологии.** Хронология получена из документов. Раздел «Пробелы», раздел «Ключевые события», строки о связи с версией дела и любое утверждение об исковой давности, приостановке срока, сроке подачи, окончании раскрытия или определении привилегии — это юридический анализ, который скилл пишет из знаний модели, если источник не указан. Каждое такое утверждение несёт отметку происхождения: `[computed from: <правило со своей пометкой>]`, `[model knowledge — verify]`, `[user provided]` или пометку коннектора исследования, если получено в этой сессии. Срок исковой давности без пометки по умолчанию считается `[model knowledge — verify]`. Строка в «Ключевых событиях», характеризующая юридическое значение факта, — это анализ, и ей нужна пометка. Правило простое: если это утверждение о праве, а не о том, что говорит документ, оно должно нести ту же отметку происхождения, что и записи хронологии. Когда коннектор исследования недоступен, а скилл вычисляет сроки или цитирует нормы, запиши это в строку **Sources:** заметки для проверяющего (см. `## Outputs` в CLAUDE.md плагина), не выводя отдельного баннера.

### Шаг 3. Извлеки события

Для каждого документа определи датированные события:

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

Обычно одно событие на документ. Иногда ноль (без даты или событие не установлено). Иногда несколько (протокол встречи с несколькими решениями).

**Флаг привилегии на каждую запись (только если privilege_posture == B-mixed). Правило трёх состояний: никогда не решай молча, что субъективный тест привилегии не выполнен:**

- `priv: ok` — источник **заведомо** не привилегирован (поданные документы, переписка с регуляторами, публичные документы, переписка с контрагентом без участия нашего юриста). Используется, только если нет правдоподобной теории привилегии.
- `priv: flag` — источник заведомо или вероятно привилегирован (переписка с юристом, записки как рабочий материал, привилегированные черновики, материалы совместной защиты). **Значение по умолчанию для всего неопределённого**: если вывод о преобладающей цели спорный, предвидение судебного спора пограничное или содержание смешанное, это сюда, а не в `ok`.
- `priv: review` — источник неясен на вид, и скилл вообще не смог принять решение (нет метаданных отправителя/получателя, нечитаем и т. д.).

При `priv: flag` или `priv: review` добавь прямо в текст `[SME VERIFY: privilege status]`, чтобы юрист увидел это при проверке. Недостаточная пометка ведёт к утрате привилегии (односторонняя дверь); избыточную пометку юрист исправляет при проверке (двусторонняя дверь). Предпочитай поправимую ошибку.

### Шаг 4. Убери дубли

Одно и то же событие всплывает в нескольких документах: встреча стоит в трёх календарях и порождает итоговое письмо — это **одно событие с четырьмя источниками**, а не четыре события. Объедини. Объединённая запись ссылается на все источники.

### Шаг 5. Пометь значимость — по версии дела

Прочитай ключевой факт и основные факты из `matter.md` (режим `--matter`) или из раздела `## Case theory` конфигурации (режим `--documents`). Пометь каждое событие:

- 🔴 **Ключевое** — событие входит в ключевой факт или является основным фактом за нас или против нас
- 🟡 **Значимое** — контекст, свидетельство закономерности, поддерживает второстепенный довод
- ⚪ **Фон** — полезно для полноты, в документ не пойдёт

**Дисциплина:** хронология из 300 записей с 300 пометками 🔴 не имеет пометок. Оставляй 🔴 для событий, которые действительно сдвинули бы позицию суда, оценивающего факты. В сомнении ставь 🟡.

**Пограничные пометки:** когда запись находится между 🔴 и 🟡 (или между 🟡 и ⚪), ставь меньшую значимость и добавляй прямо в текст `[SME VERIFY — borderline significance call]`. Суждение юриста перекроет оценку скилла. Хронология, уверенно завышающая значимость, менее полезна, чем та, что показывает свою неуверенность.

### Шаг 6. Запиши

Результат по умолчанию — рабочая хронология. Варианты — по запросу.

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

### Рабочая хронология (по умолчанию)

Расположение: `~/.claude/plugins/config/claude-for-legal/litigation-legal/matters/[slug]/chronology.md`. Полная, с пометками, с примечаниями. Справочный документ, с которым работает юрист.

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

> **Наследование привилегии.** Эта хронология составлена из документов дела, которые могут быть защищены адвокатской тайной, рабочим материалом адвоката, быть материалами общего интереса / совместной защиты или смесью этого. Она наследует статус защиты источников. Распространение за пределы круга привилегии — бизнес-заинтересованным лицам вне поручения, юристам противоположной стороны, регулятору — может привести к утрате защиты как хронологии, так и исходных источников. Храни вместе с привилегированными материалами дела, помечай согласно принятым в фирме правилам привилегии и принимай решения о распространении осознанно. Выбранный ниже режим привилегии — это отметка происхождения для любого решения о последующем распространении.

# Хронология — [название дела]

> Пометки значимости (🔴/🟡/⚪) и флаги привилегии (🔒) — первичная оценка, требующая `[SME VERIFY]` перед использованием в любом внешнем рабочем материале (документах, изложении обстоятельств, записке совету директоров, материале для внешнего юриста).

**Дело:** [slug]
**Режим:** matter | documents
**Составлена:** [ГГГГ-ММ-ДД]
**Источники:** [N] документов из [типы источников]
**Записей:** [N] ([N] 🔴 / [N] 🟡 / [N] ⚪)
**Ключевой факт:** [одно предложение]
**Режим привилегии:** A-cleared | B-mixed | C-aborted
**Помеченных записей:** [N] 🔒 *(присутствует только при режиме B-mixed)*

---

## Хронология

| Дата | Событие | Пометка | 🔒 | Источники |
|---|---|---|---|---|
| [ГГГГ-ММ-ДД] | [что произошло, одно предложение] | 🔴/🟡/⚪ | [пусто / 🔒-flag / 🔒-review] | [пути к файлам или номера Бейтса] |

---

## Ключевые события (только 🔴)

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

### [дата] — [название события]
- Что: [одна строка]
- Связь с версией: [почему это важно]
- Источники: [список]

---

## Пробелы

**Диапазоны дат без событий:**
[диапазоны — где документы за этот период?]

**Ожидалось, но отсутствует:**
[события, которые мы ожидали бы увидеть задокументированными, но их нет — например, «изменения к договору между 2024-06 и 2025-03 — не переданы»]

**Нечитаемые источники:**
[источники, заявленные в CLAUDE.md, но недоступные при этом запуске — например, «передача документов Everlaw — нет коннектора MCP; нужен экспорт»]

---

## Дисциплина пометок

- `[VERIFY: фактическое утверждение — дата, участники, содержание]` — ещё не подтверждено по исходному документу
- `[UNCERTAIN: правовая квалификация — например, создаёт ли событие регуляторный триггер]`
- `[CITE NEEDED: номер Бейтса / приложение / страница:строка депозиции]`
- `[SME VERIFY: privilege status | borderline significance call]` — нужно суждение юриста

---

## Версия
- v[N] составлена [дата] из [краткое описание источников]
- v[N-1] составлена [дата] (предыдущая, заменена)
```

### Хронология для изложения обстоятельств (по запросу)

Отфильтруй до 🔴 и значимых 🟡. Подай прозой в хронологическом порядке повествования — это каркас фактического раздела документа. Каждый абзац — одно событие или тесно связанная группа, со ссылками на материалы дела.

**Фильтр привилегии по умолчанию:** при `privilege_posture == B-mixed` записи с флагами 🔒 и 🔒-review по умолчанию **исключаются**. Вариант для изложения обстоятельств предназначен для последующего внешнего использования (документы, раскрытие, переговоры с контрагентом) — записям 🔒 там не место, пока юрист не подтвердит статус привилегии. Если пользователь всё же хочет включить записи 🔒, требуй явного подтверждения флагом `--include-flagged`; зафиксируй это подтверждение в заголовке результата как постоянную запись.

### Хронология по конкретному свидетелю (по запросу)

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

## Постепенное наращивание

Если `chronology.md` уже существует:

- Прочитай прежнюю версию
- Построй новую хронологию по текущим источникам
- Сравни: новые события (с прошлой сборки), изменённые записи (к существующим событиям добавлены источники), удалённые записи (редко; отметь, почему)
- Сохрани номер прежней версии; запиши новую версию как `v[N+1]`
- Выведи краткое описание того, что изменилось

## Связь с matter.md / history.md

**Намеренно разделены** (режим `--matter` для корпоративного юриста). `history.md` — текущий журнал юриста: решения, обновления, процессуальные вехи, внутренние стратегические заметки. `chronology.md` — хронология фактов для аргументации. Они пересекаются, но не сливаются:

- Введён режим сохранения документов → записывается в history.md (внутреннее действие). В хронологию обычно не попадает (это не факт спора).
- Контрагент направил уведомление о нарушении 14 марта → записывается в chronology.md (🟡: устанавливает его осведомлённость). Также в history.md, если приём ссылался на это.
- Составлена наша записка с рекомендацией по резерву → только history.md.

Когда юрист хочет видеть события из history в хронологии, он может их вставить. По умолчанию они остаются раздельными.

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

- **Не разрешает противоречия.** Когда два документа говорят разное о том, когда произошло событие, в хронологию идут обе записи с флагом. Разрешение — на усмотрение юриста; может потребоваться беседа со свидетелем или дальнейшее раскрытие.
- **Не придумывает события, которых нет в источниках.** Если события нет в документах (и нет в matter.md или в конфигурации как зафиксированного факта), его нет в хронологии, но «Пробелы» могут указать на то, что его не хватает.
- **Не гарантирует полноту.** Хронология хороша ровно настолько, насколько хороши источники. Если передача документов eDiscovery продолжается и пришло всего 20%, хронология это отражает. Назови это ограничение.
- **Не решает за пользователя вопрос о привилегии.** Барьер шага 0 заставляет выбрать режим; флаг `priv` у каждой записи фиксирует первичную классификацию. Окончательные определения привилегии — на усмотрение юриста по флагам `[SME VERIFY]`.

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