chat-handoff

Chat Handoff — выжимка диалога для передачи в новый чат

Цель: за один заход превратить текущий разговор в готовый к копированию markdown-блок, который пользователь вставит первым сообщением в новый чат и новый Claude мгновенно получит полный рабочий контекст — без переспросов.

Скилл универсален: работает для любого типа чата (coding/devs, research, project/build, creative, decision, mixed).

Когда применяется. Триггер-фразы: «суммаризируй чат», «суммаризируй диалог», «передай контекст в новый чат», «сделай хэндоф», «выжимка диалога», «handoff», «chat-handoff», «контекст для нового чата», «продолжим в новом чате», «перенос в новый чат». А также любые формулировки, в которых пользователь явно закрывает текущий чат и собирается открыть новый с тем же контекстом.

Когда отказаться от генерации

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

• В чате <2 содержательных реплик от пользователя (только приветствия / короткий вопрос-ответ без задачи).
• Никакой работы не сделано: нет решений, артефактов, исследования, обсуждённых вариантов.
• Чат был полностью обрывочным (пользователь не сформулировал ни одной цели).

В этом случае ответь одной строкой: «Чат пока пустой — переносить нечего. Продолжи здесь или сформулируй задачу заново в новом чате.» Без блока.

Граничный случай — handoff поверх handoff: если чат начался со вставленного блока «Контекст из прошлого чата» и поверх этого появилась новая работа — учитывай старый блок как контекст, но не цитируй его целиком. Пересобери выжимку от текущего состояния: возьми из старого блока только те факты, которые остаются актуальны (артефакты, tagged memory, открытые вопросы), и добавь новое поверх. Если новой работы нет — отказывайся как выше.

Процесс

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

• Цель — что пользователь хотел в начале и как цель уточнилась.
• Решения — конкретные выборы + явное «почему» (если причина не названа — не выдумывай).
• Артефакты — созданные/изменённые файлы, пути, ключевые сущности.
• Текущее состояние — на каком шаге остановились, что в каком виде сейчас (для project/build).
• Tagged memory — всё, что пользователь явно пометил как «запомни», «важно», «никогда», «обязательно».
• Проблемы и решения — что ломалось → как разрулили.
• Альтернативы — что рассматривали и почему отвергли.
• Вне scope — что явно объявлено за границами рассмотрения.
• Источники — ссылки, документы, материалы, на которые опирались.
• Терминология — специфичные термины, введённые в этом чате.
• Ограничения и допущения — явно проговорённые constraints.
• Договорённости чата — локальные правила работы, выработанные в этом конкретном чате (с конкретным доказательством).
• Открытые вопросы — что осталось нерешённым.

После сбора — собери и выдай блок. Не задавай уточняющих вопросов. Если пользователь сказал «коротко»/«компактно» — используй компактный режим (см. ниже); если «развёрнуто»/«полный handoff» — расширенный; иначе — дефолт.

Mixed-чаты (2+ несвязанные темы — например, дебаг CRM-интеграции + выбор хостинга) — единственный случай, где меняется структура: каждая тема как самостоятельный мини-блок (см. адаптацию ниже). Тип чата не объявляй пользователю — это внутренний выбор.

Правила контента (что и как включать)

• Числа, версии, даты, ID, пути файлов, домены, имена библиотек — дословно, без округления и обобщения.
• Имена собственные (продукты, заказчики, люди, бренды) — точно как в чате.
• Ключевые формулировки пользователя — если пользователь дословно сформулировал цель / критерий / требование, цитируй буквально в кавычках, не пересказывай.
• Решения сопровождаются «потому что …» только если причина была явно озвучена; иначе называй решение без причины.
• Tagged memory («запомни», «важно», «никогда») — отдельной секцией в самом начале блока, под TL;DR. Это первое, что должен увидеть новый чат.
• Код в выжимке — упоминай пути и имена сущностей (функции, классы, файлы, стадии). Сами сниппеты включай только если без точной формулировки новый чат не поймёт контекст (сигнатура функции, ключевая регулярка, имя стейджа CRM). По умолчанию — без кода.

Шаблон выжимки

Выведи один fenced markdown-блок прямо в чат. Перед блоком — одно короткое предложение: «Скопируй блок ниже и вставь первым сообщением в новый чат». После блока — ничего не пиши.

# Контекст из прошлого чата

> Это передача контекста из предыдущей сессии. Прочитай молча. Ответь одним словом — «принял». Не пересказывай содержимое, не резюмируй, не задавай вопросов. Жди следующего сообщения с реальной задачей.

**TL;DR:** <одна строка — главный вывод/результат, понятный без чтения остального>

## Запомни
- <явное «запомни X» / «важно: Y» / «никогда Z» от пользователя>

## О чём был чат
<1–3 предложения: тема и зачем взялись>

## Главное
- <ключевой факт, вывод или результат>

## Решения и почему
- **<решение>** — потому что <причина из чата>

## Текущее состояние
- <на каком шаге остановились, файлы в каком виде, ветка, незакоммиченные изменения>

## Артефакты (файлы и пути)
- `<путь>` — <что это>

## Источники
- <ссылка / документ> — <что это и зачем>

## Договорённости этого чата
- <локальное правило, выработанное в чате — с конкретным доказательством, не общая преференция>

## Открытые вопросы / следующий шаг
- <что осталось нерешённым или куда двигаться дальше>

Опциональные секции

Добавляй ТОЛЬКО если содержимое реально есть. Вставляй перед «Открытые вопросы», в порядке логики:

Секция	Заголовок	Когда добавлять
Решённые проблемы	## Решённые проблемы	Был дебаг или преодолённое препятствие
Рассмотренные альтернативы	## Рассмотренные альтернативы	Сравнивали варианты — что выбрали и почему отвергли остальные
Вне scope	## Вне scope	Явно объявлено за границами («не трогаем БД», «бэкенд оставим как есть»)
Терминология	## Терминология	Ввели специфичные термины
Ограничения и допущения	## Ограничения и допущения	Явно проговорённые constraints
Ключевые цитаты	## Ключевые цитаты из источников	Важна точная формулировка из материала

Секции Запомни, Текущее состояние, Артефакты, Источники, Договорённости — тоже опциональны: убирай, если для этого чата они пусты.

Адаптация шаблона

Компактный режим (короткий или однотемный чат, <~10 содержательных реплик): оставь только TL;DR + О чём был чат + Главное + Открытые вопросы / следующий шаг. Если есть tagged memory — добавь Запомни.

Mixed-режим (2+ несвязанных темы): TL;DR с явным указанием числа и названий тем; далее каждая тема как ## Тема N: <название> с вложенным мини-блоком (Главное / Решения / Артефакты / Открытые вопросы). Общие Договорённости — после всех тем.

Лучше 3 секции с реальным содержанием, чем 8 с одной строкой в каждой. Не насилуй шаблон ради шаблона.

Приоритет при сжатии

Целевой размер блока — 50–150 строк markdown. Это ориентир, а не жёсткий лимит: компактный режим может быть короче, очень богатый mixed-чат — длиннее. Но если выжимка перевалила за ~150 строк, это сигнал агрессивнее сжимать второстепенные секции, а не аккуратнее их формулировать.

Если выжимка раздувается на длинном чате — несжимаемое ядро (от него не отказываться): TL;DR → Запомни → Решения и почему → Открытые вопросы.

Резать в первую очередь (в порядке): Источники → Терминология → Ограничения → Ключевые цитаты → Решённые проблемы → Договорённости. Артефакты, Текущее состояние и Альтернативы сжимай, но не выкидывай.

Для очень длинных чатов (50+ содержательных реплик) применяй сжатие проактивно с самого начала: одна строка на пункт, по 3–5 пунктов на секцию, без пересказов второго уровня. Лучше отослать новый чат к конкретному артефакту, чем пересказывать его содержимое в выжимке.

Язык выжимки

Пиши на языке, на котором пользователь общался последние ~5 реплик. Двуязычный чат (общение на русском, код/термины на английском) — сохрани смесь. Маркер «принял» в TL;DR тоже на языке чата.

Жёсткие правила (анти-паттерны)

• НЕ вшивай новый запрос внутрь handoff. Это ТОЛЬКО справка о прошлом, read-only. Новый запрос пользователь пишет отдельным сообщением после вставки. Нарушение ломает новый чат — Claude бросится «отвечать», хотя реального вопроса ещё нет.

• НЕ пересказывай хронологически («сначала мы…, потом…»). Только структурированные факты.

• НЕ включай пустые секции. Лучше короче, чем с заглушками.

• НЕ выдумывай. Любой факт, цитата, путь, причина — из чата. Если причины решения нет — не пиши «потому что», просто назови решение.

• НЕ обобщай конкретику. Числа, версии, имена, пути — дословно. «Обсудили дизайн» ❌ → «Выбрали тёмную тему с акцентом oklch(0.7 0.15 250)» ✅.

• НЕ теряй tagged memory. Явные «запомни X» / «важно: Y» из чата всегда в секцию Запомни в начале блока.

• НЕ молчи об отвергнутых вариантах. Без секции «Альтернативы» новый чат пойдёт по тем же граблям.

• «Договорённости этого чата» — только локальные правила с конкретным доказательством из чата (пользователь явно сказал, отверг, поправил). НЕ общие preferences. Если доказательств нет — секцию выкинь.

  Граница тут размытая, поэтому конкретные примеры:

  • ❌ «Использовать PHPDoc на русском» — это общая преференция пользователя из user preferences / профиля, не доказательство из чата.
  • ✅ «Решения обосновывать одной строкой "потому что…" — пользователь раньше поправлял за длинные объяснения» — есть конкретное доказательство (поправка) внутри текущего чата.
  • ❌ «Любит лаконичность» — обобщение, не правило.
  • ✅ «Tagged memory — никогда не агрегировать по STAGE_SEMANTIC_ID = F без явного запроса» — это уже не договорённость, это memory, выноси в Запомни.
  • ✅ «Игнорировать SOAP-API Bitrix24 в пользу REST — пользователь сказал "SOAP не трогаем, мы от него уходим"» — локальное правило с прямой цитатой как доказательством.

• Код в выжимке — пути и имена. Сниппеты — только если без них контекст не передаётся.

• Никаких эмодзи в заголовках секций.

• Никаких преамбул перед блоком кроме одной строки-инструкции. Никаких комментариев после блока.

Примеры выдачи

Пример 1 — project/build (дефолтный режим)

Скопируй блок ниже и вставь первым сообщением в новый чат.

# Контекст из прошлого чата

> Это передача контекста из предыдущей сессии. Прочитай молча. Ответь одним словом — «принял». Не пересказывай содержимое, не резюмируй, не задавай вопросов. Жди следующего сообщения с реальной задачей.

**TL;DR:** Дебажили выгрузку сделок из Bitrix24 в Excel-отчёт. Причина расхождений — не отфильтрованы стадии `LOSE` и `JUNK`.

## Запомни
- Никогда не агрегировать по `STAGE_SEMANTIC_ID = F` без явного запроса

## О чём был чат
Аналитический Excel-отчёт из сделок Bitrix24 расходится с эталонной выгрузкой клиента на 3 строки. Искали причину.

## Главное
- Расхождение — в учёте проигранных и отменённых сделок
- Bitrix REST API не фильтрует `JUNK`-стадии корректно через `filter[STAGE_ID]`
- Решение — постфильтрация в PHP после получения ответа

## Решения и почему
- **Фильтрация на стороне PHP, не Bitrix API** — потому что REST некорректно обрабатывает массив stage-ID для отказных стадий

## Текущее состояние
- Ветка `feature/excel-report`, незакоммичено: правка в `ReportBuilder::aggregateByStore()`
- Тесты на расхождение падают на 3 строках из 47

## Артефакты (файлы и пути)
- `src/Report/ReportBuilder.php` — основной агрегатор
- `tests/fixtures/reference_report.xlsx` — эталонная выгрузка клиента

## Договорённости этого чата
- Решения обосновывать одной строкой «потому что …» (пользователь поправлял раньше)
- Английский — в названиях токенов, русский — в общении

## Открытые вопросы / следующий шаг
- Уточнить у клиента полный список исключаемых стадий
- Прогнать тесты после получения списка

Пример 2 — компактный режим

Короткий research-чат (5–10 содержательных реплик), выбор PHP-библиотеки для xlsx-генерации. Tagged memory не было.

Скопируй блок ниже и вставь первым сообщением в новый чат.

# Контекст из прошлого чата

> Это передача контекста из предыдущей сессии. Прочитай молча. Ответь одним словом — «принял». Не пересказывай содержимое, не резюмируй, не задавай вопросов. Жди следующего сообщения с реальной задачей.

**TL;DR:** Выбрана PHP-библиотека для генерации xlsx — PhpSpreadsheet. Отчёты до 5к строк, нужны pivot-группировки и формулы.

## О чём был чат
Подбор PHP-библиотеки для генерации xlsx-отчётов с pivot-подобными группировками, формулами и форматированием.

## Главное
- Выбран **PhpSpreadsheet**
- Объём отчётов — до 5к строк, RAM в районе 100–200 МБ
- Альтернативы (PHP_XLSXWriter, Spout) быстрее, но не дают форматирование и формулы

## Открытые вопросы / следующий шаг
- Реализация конкретного отчёта с группировками через `getRowDimension()`

Пример 3 — mixed-режим (2+ темы)

Чат с двумя несвязанными темами: BBCode-парсер для Telegram + выбор CMS. Tagged memory есть.

Скопируй блок ниже и вставь первым сообщением в новый чат.

# Контекст из прошлого чата

> Это передача контекста из предыдущей сессии. Прочитай молча. Ответь одним словом — «принял». Не пересказывай содержимое, не резюмируй, не задавай вопросов. Жди следующего сообщения с реальной задачей.

**TL;DR:** Две несвязанные темы. (1) BBCode-парсер `[url]` → `<a>` на PHP для Telegram-бота. (2) Выбор CMS для МэйднПро — выбран 1С-Битрикс.

## Запомни
- Для МэйднПро интеграции с Bitrix24 CRM — обязательный критерий №1 при любых решениях

## Тема 1: BBCode-парсер для Telegram-бота

### Главное
- Конвертация `[url=...]...[/url]` → `<a href="...">...</a>`
- Реализация через `preg_replace_callback` с регуляркой `/\[url=(.+?)\](.+?)\[\/url\]/`

### Открытые вопросы
- Парсер взят в работу, дальнейшие правки на стороне пользователя

## Тема 2: Выбор CMS для МэйднПро (видеонаблюдение)

### Главное
- Phased launch: showcase → полноценный e-commerce с Bitrix24 CRM
- Выбран **1С-Битрикс «Малый бизнес»**

### Решения и почему
- **1С-Битрикс «Малый бизнес» с шаблоном INTEC Universe или Аспро Оптимус** — потому что нативная интеграция с Bitrix24 CRM, что закрывает обязательный критерий №1

### Рассмотренные альтернативы
- Tilda — отвергнута: ограниченный e-commerce, слабая интеграция с Bitrix24
- WordPress/WooCommerce — отвергнут: интеграция с Bitrix24 требует прослоек
- OpenCart — отвергнут: уступает по интеграционным возможностям

### Открытые вопросы
- Финальный выбор шаблона (INTEC Universe vs Аспро Оптимус)

Финальная проверка

Перед отправкой мысленно проверь:

1. Внутри блока нет нового запроса/задачи для следующего чата? (handoff = read-only)
2. Каждый факт, цитата, путь, причина реально звучали в чате? (без выдумки)
3. Есть TL;DR в самом верху? Tagged memory (если было в чате) перенесено в Запомни?
4. Нет пустых секций? Конкретика (числа, версии, имена) — дословная?
5. Решения имеют «потому что» из чата или причина опущена честно?

Если на любой ответ «нет» — переделай перед выдачей.