handoff

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-]).

Если аргумента нет — детектить из контекста сессии

Проверять в порядке приоритета:

1. Чтение/запись в одну папку проекта в этой сессии. Slug — по имени самой глубокой директории, в которой шла основная работа, нормализованной в kebab-case латиницей. Если в <workspace> есть очевидная конвенция организации проектов (projects/<name>/, products/<name>/, clients/<name>/, lab/<name>/) — slug = <name>. Если работа шла прямо в подкаталоге без отдельной project-папки — slug = тематический ярлык по сути сессии (например auth-refactor, db-migration-v2).
2. Активный handoff упоминается в memory или контексте → продолжить ту же серию (инкремент версии).
3. Не удалось определить → спросить у пользователя одной строкой: «Какой 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'ам этого slug).
• Файл handoff создан в docs/plans/ с правильным шаблоном.
• Project memory обновлено или создано, содержит pointer на handoff.
• MEMORY.md строка обновлена / добавлена.
• Feedback memory создан (если применимо).
• Отчёт пользователю короткий, только пути.

Граничные случаи

• Несколько проектов в одной сессии → спросить slug; разрешено сделать несколько handoff'ов подряд.
• Сессия только обсуждение, без файлов → можно делать handoff, если есть архитектурные решения. Если нет — предупредить и переспросить.
• Файл с тем же путём уже существует (что почти невозможно при правильной нумерации) → инкрементировать ещё раз и дать знать пользователю.
• Slug содержит недопустимые символы → нормализовать в kebab-case латиницей или спросить.
• Папка docs/plans/ не существует → создать (mkdir -p).
• Папка проекта в .gitignore → не предлагать git commit, упомянуть в отчёте «коммит не нужен, папка в .gitignore».