# New Dialog Handoff

> Безопасный переход в новый диалог, когда чат стал длинным или агент прогнозирует скорое исчерпание контекстного окна. Скилл переиспользует `parking` и `resume`, фиксирует durable source of truth и готовит короткий restart-packet для свежего чата. ОБЯЗАТЕЛЬНО используй, когда пользователь говорит: «новый диалог», «перенеси в новый чат», «сделай handoff», «продолжим в новом чате», а также когда агент сам выводит критический хвост вида `CTX~N% -> new-dialog-handoff`.

- Skill: `dzhokhov/new-dialog-handoff` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add dzhokhov/new-dialog-handoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dzhokhov/new-dialog-handoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dzhokhov (https://skillmd.com/u/dzhokhov)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dzhokhov/new-dialog-handoff

---


# Переход в новый диалог

Ты выполняешь протокол безопасного handoff в свежий чат. Цель: не потерять рабочее состояние, не дублировать память и не тащить критичный контекст только в историю разговора.

## Принцип

Сначала сохрани состояние в durable source of truth, потом переводи работу в новый чат. Не делай длинный пересказ беседы, если уже есть `log.md`, `tasks.md`, `context.md`, research-note, spec или другой канонический артефакт.

## Когда применять

- Чат стал длинным и качество следующих ответов может просесть.
- Агент показывает критический хвост `CTX`.
- Пользователь явно просит продолжить в новом чате.
- Предстоит длинный следующий шаг: review, большой diff, большой ресёрч, многофайловая правка, длинное объяснение.

## Протокол

### Шаг 1. Определи, где должен жить state

Спроси себя:
- это проектная работа;
- это standalone research/knowledge;
- или уже есть готовый канонический артефакт, на который можно опереться.

Приоритет источника правды (в порядке **медленные слои → быстрые**, как в [write-protocol.md §5](../../meta/rules/write-protocol.md)):
1. существующий проектный контур — `README.md` → `plan.md` → `context.md` → `tasks.md` → `log.md`;
2. `01_now/ops/<contour>/delegations/<person-slug>.md` — если state — это открытое делегирование;
3. `01_now/personal/tasks.md` — если state — личное обязательство владельца;
4. уже созданный standalone note в `03_knowledge/`;
5. `00_inbox/` — если это curiosity без проекта;
6. новый checkpoint только если без него состояние реально потеряется.

Если handoff касается активного проекта, а `plan.md` ещё не существует (legacy) — сначала создай `plan.md` из шаблона, затем фиксируй состояние уже в новом slow-layer контракте. Handoff не должен опираться только на `log.md`, если проект уже активный.

### Шаг 2. Переиспользуй `parking`, а не заменяй его

Если работа относится к проекту:
- сначала выполни протокол из `skills/parking/SKILL.md` — он сам разведёт state по правильным файлам (plan / log / tasks / delegations / personal) согласно task-routing decision tree (см. [task-routing-methodology-2026-04.md §4](../../03_knowledge/task-routing-methodology-2026-04.md));
- не изобретай параллельную систему фиксации;
- в следующем чате рекомендуй вход через `resume` — он сам перечитает README → plan → context → tasks → log и сделает passive recall по delegations.

Если задача вне проекта, но в текущем цикле уже создан durable artifact:
- используй его как source of truth;
- отдельную handoff-память не создавай.

Если durable artifact ещё нет, а потеря контекста реальна:
- сначала создай минимальный checkpoint в правильном месте;
- только потом предлагай новый чат.

### Шаг 3. Сожми handoff до restart-packet

Верни пользователю короткий пакет, максимум 5 пунктов:

```text
Новый диалог:
- Что продолжаем: <1 строка>
- Source of truth: <1-3 файла — в порядке plan → context → tasks → log>
- Открытые делегирования: <если есть, путь к delegations/*.md>
- Следующий шаг: <1 конкретное действие>
- Старт в новом чате: <короткая команда или prompt>
```

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

### Шаг 4. Правило запуска нового чата

Если проектный handoff:
- рекомендованный старт: `resume <проект или задача>`

Если это standalone работа:
- дай paste-ready prompt:

```text
Продолжаем <задача>. Source of truth: <пути к файлам>. Не пересказывай заново, продолжай с шага: <следующий шаг>.
```

### Шаг 5. При критическом остатке не пытайся «дожать»

Если хвост уже критический:
- не начинай новый длинный анализ;
- не уходи в дополнительные поиски;
- сначала checkpoint/handoff;
- затем новый чат.

## Ограничения

- Не держи важный state только в истории разговора.
- Не создавай новый handoff-артефакт, если достаточно `parking` + существующих файлов.
- Не подменяй `resume`; новый чат должен либо входить через `resume`, либо опираться на явно названные source-of-truth файлы.
- Не растягивай restart-packet: он должен быть короче обычного recap.