| name | handoff |
| description | Лёгкий handoff текущей рабочей сессии для переезда в следующую: создаёт docs/plans/YYYY-MM-DD-session-handoff-<slug>-vN.md, обновляет project memory Claude Code, индексирует в MEMORY.md, при наличии новых правил создаёт feedback memory. Не делает атомов, не публикует во внешние системы, не делает git commit. Триггеры: "/handoff", "сделай handoff", "подготовь handoff", "переезд в следующую сессию", "сохрани контекст для следующей сессии", "handoff файл и memory". Аргумент: <project-slug> (опционально). Если не передан — определяет из контекста сессии.
|
handoff
Скилл для передачи контекста рабочей сессии в следующую сессию того же проекта Claude Code.
Опирается на штатную auto-memory систему Claude Code: handoff-файл фиксирует решения и состояние, а указатель на него попадает в MEMORY.md, который CC автоматически инжектит в системный промпт каждой новой сессии. Благодаря этому в новой сессии достаточно открыть тот же workspace — контекст подхватывается сам.
Не путать с companion-скиллом session-debrief (если он у тебя есть) — тот про окончательный финал этапа: атомы знаний, документация, git commit.
Requirements
- Claude Code с включённой auto-memory системой. У CC она штатная: путь к memory store —
~/.claude/projects/<encoded-workspace>/memory/, где <encoded-workspace> — это абсолютный путь твоей рабочей директории со слешами, заменёнными на дефисы, и ведущим дефисом. Пример: /Users/alice/code/myproject → ~/.claude/projects/-Users-alice-code-myproject/memory/.
- В рабочей директории должен существовать (или быть создаваемым) каталог
docs/plans/.
В тексте скилла ниже:
<workspace> — корень рабочей директории сессии (CWD Claude Code).<memory_store> — путь к memory store по формуле выше. Скилл вычисляет его сам из CWD.
Когда использовать
- Конец рабочей сессии по проекту, когда хочется продолжить позже без потери контекста.
- Большая сессия близка к context limit / компакции — нужно зафиксировать до продолжения.
- Передаёшь работу другому LLM / другой машине.
Когда НЕ использовать
- Завершение этапа целиком →
session-debrief (полный дебриф с атомами и commit), если такой companion-скилл есть.
- Просто закончить разговор без продолжения → ничего не нужно.
- Один-два шага в одном файле без архитектурных решений → пустой handoff бесполезен.
Граница с session-debrief
| Параметр | /handoff | /debrief |
|---|
Файл handoff в docs/plans/ | ✅ | ❌ |
| Project memory обновление | ✅ | ✅ |
| Атомы знаний (knowledge base) | ❌ | ✅ |
| Публикация во внешние системы (wiki, чаты) | ❌ | ❌ |
| Git commit | ❌ | ✅ |
| Когда применять | конец сессии, продолжим позже | конец большого этапа |
Шаг 0 — Определение проекта (slug)
Если передан аргумент
/handoff <project-slug> — взять как есть, валидируя через kebab-case (только [a-z0-9-]).
Если аргумента нет — детектить из контекста сессии
Проверять в порядке приоритета:
- Чтение/запись в одну папку проекта в этой сессии. Slug — по имени самой глубокой директории, в которой шла основная работа, нормализованной в kebab-case латиницей. Если в
<workspace> есть очевидная конвенция организации проектов (projects/<name>/, products/<name>/, clients/<name>/, lab/<name>/) — slug = <name>. Если работа шла прямо в подкаталоге без отдельной project-папки — slug = тематический ярлык по сути сессии (например auth-refactor, db-migration-v2).
- Активный handoff упоминается в memory или контексте → продолжить ту же серию (инкремент версии).
- Не удалось определить → спросить у пользователя одной строкой: «Какой slug проекта для handoff'а? (например
my-project)».
Slug должен быть kebab-case, латиница, без vN суффикса (версия добавляется отдельно). Если возникает амбигвити (несколько проектов в сессии) — спросить.
Шаг 1 — Определение версии
ls <workspace>/docs/plans/*-session-handoff-<slug>*.md 2>/dev/null
- Нет файлов →
v1.
- Есть файлы → найти максимальную
vN, инкремент: v(N+1).
- Файл без
vN (типа YYYY-MM-DD-session-handoff-<slug>.md) считать как v1 — следующий будет v2.
Дата файла = текущая дата сессии (today). Не реюзать дату из существующих файлов.
Шаг 2 — Анализ сессии
Сформировать (в голове, без вызова отдельных tools):
- TL;DR — 2-3 предложения для следующей сессии: где остановились, что критично знать.
- Что сделано — список созданных/обновлённых файлов + ключевых обсуждений.
- Архитектурные решения — конкретные «было → стало», по каждому 1-2 строки.
- Открытые вопросы — что ждёт ответа от пользователя или внешней стороны.
- Следующие шаги — 2-3 варианта для следующей сессии в порядке вероятной полезности.
- Правила и feedback — новые «не делать X», «всегда делать Y» из этой сессии.
- Memory pointers — какие файлы memory обновлены / созданы.
Если сессия слишком короткая или результатов нет — спросить пользователя «Уверен, что нужен handoff? Сессия не выглядит насыщенной». Не делать пустые handoff'ы.
Шаг 3 — Создание handoff-файла
Путь:
<workspace>/docs/plans/YYYY-MM-DD-session-handoff-<slug>-vN.md
Шаблон (фиксированный, заполнять разделы из шага 2):
# Session Handoff — <Project Display Name>
**Дата:** YYYY-MM-DD
**Версия:** vN
**Проект:** `<путь к рабочей папке>`
**Статус:** <одна фраза о текущем состоянии>
**Предыдущий handoff:** <ссылка на vN-1, если есть>
---
## TL;DR для следующей сессии
<2-3 предложения: где остановились, что критично знать первым>
---
## Что сделано в этой сессии
### Созданные / обновлённые файлы
| Файл | Что изменено |
|---|---|
| `path/to/file.md` | Создан/обновлён, что именно |
### Ключевые обсуждения
- <тема 1 — короткий итог>
- <тема 2 — короткий итог>
---
## Ключевые решения этой сессии
### 1. <Решение>
<1-2 строки контекста: было → стало → почему>
### 2. <Решение>
...
---
## Открытые вопросы
1. <вопрос — кто отвечает / какой ответ нужен>
2. ...
---
## Следующие шаги
### Вариант A (наиболее вероятный) — <название>
<краткое описание + что именно делать>
### Вариант B — <название>
...
### Вариант C — <название>
...
---
## Правила и feedback этой сессии
- <правило 1 с обоснованием>
- <правило 2>
---
## Критические файлы / ссылки
- <ключевые пути, URL, slug'и>
---
## Memory pointers
- `project_<slug>_active.md` — обновлена/создана YYYY-MM-DD
- `feedback_<slug>_<тема>.md` — если создан в этой сессии
---
## Контекст для следующей сессии в одну строку
> *<Однострочное резюме для подсказки в начале новой сессии.>*
Шаг 4 — Обновление project memory
Путь: <memory_store>/project_<slug>_active.md
Где <memory_store> — стандартный Claude Code memory store текущего workspace: ~/.claude/projects/<encoded-workspace>/memory/ (формула в Requirements). Если каталог не существует — создать (mkdir -p).
Если файл существует
Перечитать, переписать целиком актуальной версией. Сохранить:
- frontmatter (
name, description, type: project, originSessionId если был)
- 🔥 АКТИВНЫЙ маркер если уместен
- Why-блок (зачем проект существует)
- How to apply: актуальные архитектурные решения, активные документы, открытые вопросы, правила сессии
- Pointer на свежий handoff (обязательно:
Текущая активная сессия: YYYY-MM-DD, handoff = docs/plans/...).
Если файла нет
Создать с frontmatter:
---
name: <Project Display Name>
description: <одна строка для индекса MEMORY.md>
type: project
---
Тело — Why + How to apply + ссылка на handoff.
Шаг 5 — Обновление MEMORY.md
Путь: <memory_store>/MEMORY.md
Это индекс всей persistent memory, который Claude Code автоматически инжектит в каждую новую сессию. Именно через эту строку следующая сессия увидит свежий handoff и подхватит контекст.
Если строка проекта уже есть
Найти и обновить одну строку:
- [project_<slug>_active.md](project_<slug>_active.md) — 🔥 АКТИВНЫЙ: <короткая суть>. Handoff vN: docs/plans/YYYY-MM-DD-session-handoff-<slug>-vN.md
Длина строки ≤ 200 символов. Описание — самое важное в проекте сейчас, не история.
Если строки нет
Добавить в подходящую секцию по семантике slug (например ## Project Context, ## Active Projects, ## Clients — какая уже есть в твоём MEMORY.md). Если ни одна не подходит — добавить в общую секцию активных проектов; если такой нет — создать ## Project Context в конце файла.
Шаг 6 — Опциональный feedback memory
Если в сессии появилось новое явное правило от пользователя («не делай X», «всегда делай Y», «отдельная ветка»), создать:
Путь: <memory_store>/feedback_<slug>_<тема>.md
Имя файла: feedback_<slug>_<короткая_тема>.md (snake_case, латиница).
Содержимое:
---
name: <Заголовок правила>
description: <Одна строка для индекса>
type: feedback
---
<Краткое описание правила>
**Why:** <что произошло, почему правило появилось>
**How to apply:**
- <конкретные ситуации применения>
- <чего не делать>
Затем добавить строку в MEMORY.md секцию ## Feedback:
- [feedback_<slug>_<тема>.md](feedback_<slug>_<тема>.md) — <одна строка с сутью>
Правила определения «достаточно ли важно сохранить как feedback»:
- Прямая фраза «не делай X» / «всегда делай Y» — да.
- Корректное архитектурное решение, подтверждённое пользователем — да.
- Один разовый выбор без обоснования — нет.
- Если сомневаешься — спроси: «Зафиксировать как правило в memory: «<кратко>»? (y/n)».
Шаг 7 — Финальный отчёт пользователю
После всех правок отчитаться кратко:
Готово.
📄 Handoff: docs/plans/2026-MM-DD-session-handoff-<slug>-vN.md
🧠 Memory: project_<slug>_active.md (обновлено / создано)
📑 Index: MEMORY.md (строка обновлена)
[если был] 📌 Feedback: feedback_<slug>_<тема>.md
В следующей сессии достаточно открыть handoff-файл — контекст подхватится.
Не пересказывать содержимое handoff'а (он уже в файле). Указать только пути.
Чек-лист исполнения
Граничные случаи
- Несколько проектов в одной сессии → спросить slug; разрешено сделать несколько handoff'ов подряд.
- Сессия только обсуждение, без файлов → можно делать handoff, если есть архитектурные решения. Если нет — предупредить и переспросить.
- Файл с тем же путём уже существует (что почти невозможно при правильной нумерации) → инкрементировать ещё раз и дать знать пользователю.
- Slug содержит недопустимые символы → нормализовать в kebab-case латиницей или спросить.
- Папка
docs/plans/ не существует → создать (mkdir -p).
- Папка проекта в
.gitignore → не предлагать git commit, упомянуть в отчёте «коммит не нужен, папка в .gitignore».
