Multi document brief

Анализ набора разнородных документов (pdf, docx, pptx, txt, xlsx, сканы, фото, картинки в любой комбинации) и выпуск аналитической записки .docx не длиннее 2 страниц с фиксированной структурой: общий вывод, затем по каждому топику сводка и логика решения. Используй, когда пользователь прикладывает несколько файлов и просит их проанализировать, свести, сделать выводы, записку, справку или саммари, в том числе с коротким фокусом (на чём сделать акцент). Также для запросов «сделай записку по этим материалам», «общий вывод и логика по документам», «brief from these files».

Аналитическая записка по набору документов

Результат всегда один и тот же по форме: Word-документ A4, ≤ 2 страниц:

text

АНАЛИТИЧЕСКАЯ ЗАПИСКА / заголовок / дата · источники · фокус
1. Общий вывод                      (выделенный блок + до 3 тезисов)
2. {Топик 1}   2.1. Сводка   2.2. Логика решения (таблица: факты → рассуждение → вывод → уверенность)
3. {Топик 2}   3.1. Сводка   3.2. Логика решения
4. {Топик 3}   4.1. Сводка   4.2. Логика решения
Источники: D1 — файл; D2 — …

Разделение ответственности — главный принцип скилла:

• Ты отвечаешь только за содержание — пишешь analysis.json по схеме ниже.
• Оформление делает скрипт build_docx.py: шрифты, нумерация, таблицы, колонтитулы, подбор плотности под 2 страницы. Один и тот же JSON → побайтно один и тот же .docx. Никогда не верстай docx вручную и не меняй оформление — иначе пропадает типизированность.

Обозначения в командах ниже:

• SKILL_DIR — папка, где лежит этот SKILL.md (в ней scripts/ и references/);
• WORK — рабочая папка во временной директории (scratchpad агента, иначе системная временная папка), никогда не рядом с файлами пользователя: там лежат корпус, изображения, JSON и PDF-превью;
• OUT — куда отдать результат: папка, которую назвал пользователь → папка результатов платформы (в claude.ai и Cowork — /mnt/user-data/outputs/) → текущая папка.
• Интерпретатор — python3; если его нет (Windows), то python.

Шаг 0. Входы

• Файлы: всё, что приложил пользователь (в claude.ai и Cowork — /mnt/user-data/uploads/; на других платформах — папка вложений текущего диалога), или пути и папки, которые он назвал. Можно передавать папку целиком.
• Фокус: короткая инструкция пользователя «на чём сделать фокус». Если её нет — фокус по умолчанию: «проанализировать информацию, сделать общий вывод, ключевые подвыводы и показать логику по каждому». Не задавай уточняющих вопросов о формате — он фиксирован.
• Число топиков: 3. Если пользователь явно просит 2 или 4 — допустимо (2–4).

Зависимости: только Pillow и openpyxl (для .xlsx). DOCX, PPTX и PDF читаются и DOCX пишется собственным кодом скрипта, без python-docx, python-pptx и PyMuPDF. Если в окружении есть PyMuPDF, pdftoppm или Ghostscript, страницы PDF со сканами и графиками рендерятся картинками; если нет, из PDF берутся встроенные картинки. LibreOffice нужен для точной проверки числа страниц, рендера слайдов целиком и форматов .doc/.ppt/.xls. Без него страницы считаются по метрикам шрифта, с запасом.

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

bash

python3 "$SKILL_DIR/scripts/extract.py" <файлы и/или папки> --out "$WORK"

Скрипт присваивает документам ID D1, D2, … и создаёт:

• $WORK/corpus.md — весь текст с якорями <<D2 · стр. 3>>, <<D1 · слайд 4>> — это и есть формат ссылок;
• $WORK/texts/Dn.md — текст каждого документа отдельно;
• $WORK/images/*.jpg — всё, что нужно посмотреть глазами: картинки-входы, сканы и «графические» страницы PDF, слайды с диаграммами/изображениями, рисунки внутри docx (уже уменьшены, ≤1568 px);
• $WORK/manifest.json — реестр, оценка токенов и reading_strategy.

Данные диаграмм pptx/docx (категории и значения) извлекаются в текст как [Диаграмма] … — это точнее, чем считывать столбики с картинки. Прочитай таблицу, которую печатает скрипт: предупреждения [!] (нет текстового слоя, лимит рендера, legacy-формат) учитывай при выводах.

Шаг 2. Чтение — ничего не пропустить

1. Текст. Если reading_strategy = single_pass — прочитай $WORK/corpus.md целиком. Если per_document_notes (корпус большой) — читай $WORK/texts/Dn.md по одному и после каждого дописывай выписки в $WORK/notes.md, чтобы не держать весь корпус в контексте.
2. Изображения. Открой инструментом просмотра файлов каждый файл из images в манифесте. Сканы — это единственный источник их текста; графики — источник трендов. Цифры с графика записывай, только если они явно подписаны; иначе — «по графику ≈», и не используй как точный факт.
3. Выписки (в уме или в $WORK/notes.md) — по одной строке: [D2 · стр. 3] факт/цифра/решение/риск. Цифры — дословно, с единицами и периодом. Помечай, что является мнением или прогнозом.

Шаг 3. Синтез — методика

Топики. Выбери ровно 3 (или сколько попросили) самостоятельные темы, которые важнее всего для фокуса: не пересекаются, вместе покрывают главное, по каждой можно сделать вывод. Предпочитай темы, подтверждённые 2+ источниками. Порядок — по значимости. Плохой топик — пересказ одного файла («Презентация D1»); хороший — вопрос, на который отвечают несколько файлов («Экономика проекта»).

Общий вывод — ответ на вопрос анализа, а не оглавление: главный вывод → ключевое условие/риск → что из этого следует. Лучшие выводы связывают топики между собой (два риска с общей причиной, противоречие между планом и фактами).

Логика решения — объяснение, почему ИИ пришёл к выводу. Читатель должен суметь проверить её:

• evidence — 2–4 исходных факта со ссылками; только то, что есть в материалах;
• reasoning — 2–4 шага от фактов к выводу: сопоставление источников, причинно-следственная связь, найденное противоречие, недостающие данные. Не повторяй факты — покажи ход мысли;
• conclusion — одно предложение;
• confidence: высокая — несколько согласующихся источников, прямые данные; средняя — один источник или косвенные данные; низкая — гипотеза, противоречия, мало данных;
• caveats (необязательно) — что может изменить вывод, чего не хватает.

Собственные расчёты (сумма, разница, окупаемость, пересчёт на базу) допустимы и часто ценнее всего, но помечай их «расчёт:» и показывай входные данные: «расчёт: 162 FTE × 1,1 млн = 178 млн руб./год». Если расчёт расходится с цифрой в документе — это находка, укажи обе. Вывод, держащийся на твоём расчёте поверх прямых данных, — не выше «средней» уверенности, если расчёт не тривиален.

Вопрос «да/нет» («стоит ли…», «реалистично ли…»): overall.text начинается с прямого ответа, условия и рекомендации — в key_points и в conclusion топиков. Структуру не меняй.

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

Шаг 4. analysis.json

Пример: references/example_analysis.json. Лимиты — жёсткие, их проверяет скрипт.

json

{
  "meta": {"title": "суть записки, ≤110", "focus": "фокус анализа, ≤220 (необяз.)",
           "date": "YYYY-MM-DD (необяз., по умолчанию сегодня)"},
  "overall": {"text": "≤800", "key_points": ["0–3 шт., каждый ≤170"]},
  "topics": [
    {"title": "≤90",
     "summary": "3–5 предложений с цифрами, ≤600",
     "logic": {
       "evidence": [{"text": "≤200", "refs": ["D2 · стр. 3", "D4"]}],
       "reasoning": ["≤200", "..."],
       "conclusion": "≤240",
       "confidence": "высокая | средняя | низкая",
       "confidence_reason": "≤150",
       "caveats": "≤170, необяз."}}
  ]
}

evidence: 2–4 пункта, суммарно ≤560; reasoning: 2–4 шага, суммарно ≤520. Пиши строго по схеме; если формат всё же немного отступит (факт строкой со ссылкой в скобках, «Высокая (…)»), скрипт переупакует его сам и ошибкой это не считается. refs начинаются с ID документа (D3, D1 · слайд 2, D4 · рис. 1). Проверяется: существование ID, номер страницы/слайда (не больше, чем в документе) и упоминания D… в любом тексте. В документе ссылка печатается как [D1, слайд 2]. sources не пиши — их подставит --manifest.

Перед рендером можно проверить JSON и заполненность лимитов: python3 "$SKILL_DIR/scripts/build_docx.py" "$WORK/analysis.json" --manifest "$WORK/manifest.json" --check. Ориентир — 60–85% по полям: тогда записка выходит в основном, просторном профиле.

Шаг 5. Рендер

bash

python3 "$SKILL_DIR/scripts/build_docx.py" "$WORK/analysis.json" --manifest "$WORK/manifest.json" \
        --out "$WORK/<Название>.docx" --pdf
cp "$WORK/<Название>.docx" "$OUT/"        # PDF-превью остаётся в WORK

• exit 2 — ошибки схемы: исправь перечисленные поля и запусти снова.
• exit 3 — не влезает в 2 страницы даже в плотном профиле: сократи поля, названные в сообщении.
• Скрипт сам перебирает профили standard → compact → dense и берёт первый, что влезает.
• --manifest передавай всегда: без него ссылки не проверяются и нет блока «Источники».

Имя файла — по сути записки, через подчёркивания (например, Записка_локализация_EV.docx).

Шаг 6. Проверка и выдача

1. Если создан PDF-превью и есть pdftoppm, посмотри страницы (pdftoppm -r 80 -png "$WORK/<Название>.pdf" "$WORK/page"): ≤ 2 страницы, ничего не обрезано. Без превью ориентируйся на сообщение скрипта: в нём число страниц и способ проверки.
2. Сверь каждую цифру в записке с corpus.md/изображениями, а каждую ссылку — с нужным документом.
3. Проверь согласованность: общий вывод не противоречит выводам топиков (сроки, суммы, оценки совпадают везде), уверенность соответствует шкале.
4. Ответ пользователю — на его языке, 2–3 предложения: что за записка, главный вывод одной фразой, ограничения (например, нечитаемый скан). PDF-превью — служебный, не прикладывай без просьбы.

Автономный режим на локальной LLM

Для работы без облачной модели, на локальной LLM с ограниченным контекстом, есть отдельный пакет docbrief (Python-модули и Jupyter-ноутбук). Он использует те же extract.py и build_docx.py, поэтому структура и вёрстка записки те же, и добавляет бюджет токенов на каждый запрос, map → сжатие → синтез и проверку чисел по источникам. Упоминай его, только если пользователь спрашивает про локальную модель или пакетный запуск без участия агента.