New dialog handoff
Skill dzhokhov/markdown-agent-vault-ru/skills/new-dialog-handoff
Open-source starter kit for an agent-ready Markdown vault with AGENTS.md, templates, skills, logs, and file-safe AI workflows.
npx -y skills add dzhokhov/markdown-agent-vault-ru --skill new-dialog-handoffAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Безопасный переход в новый диалог, когда чат стал длинным или агент прогнозирует скорое исчерпание контекстного окна. Скилл переиспользует `parking` и `resume`, фиксирует durable source of truth и готовит короткий restart-packet для свежего чата. ОБЯЗАТЕЛЬНО используй, когда пользователь говорит: «новый диалог», «перенеси в новый чат», «сделай handoff», «продолжим в новом чате», а также когда агент сам выводит критический хвост вида `CTX~N% -> new-dialog-handoff`.
SKILL.md
6.9 KB, as published. Nobody here has run it
Переход в новый диалог
Ты выполняешь протокол безопасного 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):
- существующий проектный контур —
README.md→plan.md→context.md→tasks.md→log.md; 01_now/ops/<contour>/delegations/<person-slug>.md— если state — это открытое делегирование;01_now/personal/tasks.md— если state — личное обязательство владельца;- уже созданный standalone note в
03_knowledge/; 00_inbox/— если это curiosity без проекта;- новый 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); - не изобретай параллельную систему фиксации;
- в следующем чате рекомендуй вход через
resume— он сам перечитает README → plan → context → tasks → log и сделает passive recall по delegations.
Если задача вне проекта, но в текущем цикле уже создан durable artifact:
- используй его как source of truth;
- отдельную handoff-память не создавай.
Если durable artifact ещё нет, а потеря контекста реальна:
- сначала создай минимальный checkpoint в правильном месте;
- только потом предлагай новый чат.
Шаг 3. Сожми handoff до restart-packet
Верни пользователю короткий пакет, максимум 5 пунктов:
Новый диалог:
- Что продолжаем: <1 строка>
- Source of truth: <1-3 файла — в порядке plan → context → tasks → log>
- Открытые делегирования: <если есть, путь к delegations/*.md>
- Следующий шаг: <1 конкретное действие>
- Старт в новом чате: <короткая команда или prompt>
Не пересказывай всю сессию. Не копируй длинный анализ. Не дублируй содержимое файлов в чат.
Шаг 4. Правило запуска нового чата
Если проектный handoff:
- рекомендованный старт:
resume <проект или задача>
Если это standalone работа:
- дай paste-ready prompt:
Продолжаем <задача>. Source of truth: <пути к файлам>. Не пересказывай заново, продолжай с шага: <следующий шаг>.
Шаг 5. При критическом остатке не пытайся «дожать»
Если хвост уже критический:
- не начинай новый длинный анализ;
- не уходи в дополнительные поиски;
- сначала checkpoint/handoff;
- затем новый чат.
Ограничения
- Не держи важный state только в истории разговора.
- Не создавай новый handoff-артефакт, если достаточно
parking+ существующих файлов. - Не подменяй
resume; новый чат должен либо входить черезresume, либо опираться на явно названные source-of-truth файлы. - Не растягивай restart-packet: он должен быть короче обычного recap.