# Parking > Парковка текущего контекста работы для безопасного переключения на другую задачу. Агент анализирует ход беседы, определяет проект и задачу, классифицирует тип прерывания, записывает стоп-кадр в log.md проекта, обновляет plan.md (если появляется blocker или меняется вектор), а затем фиксирует состояние в правильном слое: plan.md §Blockers, tasks.md или delegations/ в зависимости от типа паузы. После этого можно безопасно переключаться или закрывать чат — точка возврата сохранена. ОБЯЗАТЕЛЬНО используй этот скилл, когда пользователь говорит: «паркуйся», «park», «припаркуйся», «стоп-кадр», «запаркуй», «parking», «сохрани точку возврата», «зафиксируй где мы». Также используй проактивно, если видишь, что пользователь переключается на другую тему без явной парковки — предложи: «Сделать стоп-кадр перед переключением?» - Skill: `dzhokhov/parking` (Agent Skill) - Install (CLI): `npx skillmds@latest add dzhokhov/parking` - Raw SKILL.md: https://api.skillmd.com/api/skills/dzhokhov/parking/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/parking --- # Парковка контекста Ты выполняешь протокол парковки — фиксируешь текущее состояние работы, чтобы любая будущая сессия (или возврат в этом же чате) могла восстановить контекст с точки остановки. ## Зачем это нужно Переключение контекста стоит ~23 минуты на восстановление фокуса (исследование Ophir & Nass). Без явной точки возврата исходная задача теряется — особенно когда контекстное окно забивается новым материалом. Парковка решает эту проблему: она создаёт формализованную «хлебную крошку», которая переживает и этот чат, и следующий. ## Модель роутинга задач Парковка работает в рамках task-routing-модели (см. [task-routing-methodology-2026-04.md](../../03_knowledge/task-routing-methodology-2026-04.md) и [Правила 10–14 AGENTS.md](../../AGENTS.md)). Ключевые инварианты: - `plan.md` — **медленный контракт** проекта (Goal, Milestones, **Blockers**, Drift Guard, Contingency). Парковка **обязательно** меняет `plan.md §Blockers`, если тип прерывания — BLOCKED или DELEGATED с milestone-impact. Блокеры — first-class сущность плана, не секция `tasks.md`. См. [§5.4 методологии](../../03_knowledge/task-routing-methodology-2026-04.md). - `tasks.md` — **execution queue**. Маркер `PAUSED` идёт сюда только если это NEED_INFO шаг текущего milestone (тактический сбор информации). Размышление («надо разобраться с X») идёт в `plan.md` как open question под milestone, не в `tasks.md`. Секции `Blocked` в `tasks.md` **нет** — она переехала в `plan.md §Blockers`. - `01_now/ops//delegations/.md` — если парковка произошла потому, что задача делегирована сотруднику, маркер идёт сюда. Если блокирует milestone — **параллельно** запись в `plan.md §Blockers` с `Тип: delegated-work`. - `01_now/personal/tasks.md` — личное внешнее обязательство владельца. Парковка **не порождает** личных строк — это событие маршрутизации, а не тип прерывания. - `00_inbox/` — только для «случайной идеи», у которой нет ни проекта, ни домашнего контура. Опять же — не парковка, а routing. **💡 SPAWNED — категориальная ошибка.** Появление новой идеи в ходе работы над основной задачей — не тип прерывания, а **событие маршрутизации**: идея уходит в свой целевой файл (`plan.md` другого проекта, `personal/tasks.md`, `00_inbox/`, `delegations/`), и работа продолжается без парковки. В типах PAUSED этого маркера больше нет. ## Протокол (выполняй строго по шагам) ### Шаг 1. Определи проект и задачу из контекста беседы Проанализируй текущий чат и определи: - **Проект**: к какому проекту из `01_now/projects/` относится работа. Если не относится ни к одному — укажи «вне проекта» и выбери destination по типу (см. Шаг 4): личное → `01_now/personal/tasks.md`, curiosity → `00_inbox/`. - **Задача**: что конкретно делали (не «работали над проектом», а «дописали 3 из 5 пунктов анализа unit-экономики»). - **Точка остановки**: на чём именно прервались — максимально конкретно. - **Влияет ли прерывание на вектор проекта?** Если да — на Шаге 3 обновляется `plan.md`, не только `log.md`. ### Шаг 2. Классифицируй тип прерывания Определи тип автоматически из контекста разговора. Не спрашивай пользователя, если тип очевиден. | Маркер | Тип | Когда использовать | Триггер возврата | |--------|-----|-------------------|------------------| | `⏸️ BLOCKED` | Жду внешнего события / результата из другого проекта / ответа клиента / дедлайна | Мяч не у пользователя, и **никакого действия, приближающего результат, у него нет**. Включает cross-project dependency и external-event. | Получен ответ / прошёл дедлайн / сработал fallback | | `🔀 DELEGATED` | Отдал в проработку сотруднику | Задача в работе у делегата, SoT — трекер или `delegations/.md` | Результат готов, нужно проверить | | `🔍 NEED_INFO` | Нужно найти/изучить | **У владельца есть action**, который приблизит результат (читать, спрашивать, пробовать) — это тактический execution-шаг, не блокер | Информация найдена и структурирована | | `⏹️ STOPPED` | Просто остановился | Конец сессии, нет конкретного блокера | Следующая сессия по этому проекту | **Правило дизамбигуации BLOCKED vs NEED_INFO:** если тип неочевиден — спроси одним коротким вопросом: «У тебя есть действие, которое приблизит результат, или ты просто ждёшь?». Есть действие → NEED_INFO. Нет действия → BLOCKED. **Маркера 💡 SPAWNED больше нет** — новая идея/задача не паркуется, а маршрутизируется в свой целевой файл без прерывания основной работы (см. §«Модель роутинга задач» выше). ### Шаг 3. Обнови `plan.md` — first-class слой Это **первый слой** записи. Порядок «медленные слои опережают быстрые» ([write-protocol.md §5](../../meta/rules/write-protocol.md)) означает, что `plan.md` всегда обновляется раньше `log.md`, `tasks.md`, `delegations/`. По типу прерывания: | Тип | Что пишется в `plan.md` | |---|---| | ⏸️ BLOCKED | **Новая карточка в `## Blockers`** (`Bx`, с полями: Открыт, Тип, Ждём, Блокирует, Моё действие, Условие возврата, Fallback, Stale check) + статус каждого затронутого milestone меняется на `blocked on Bx` | | 🔀 DELEGATED без milestone-impact | `plan.md` не меняется — запись идёт только в `delegations/.md` | | 🔀 DELEGATED с milestone-impact (блокирует milestone) | **Новая карточка в `## Blockers`** с `Тип: delegated-work`, параллельно записи в `delegations/.md` | | 🔍 NEED_INFO тактический | `plan.md` не меняется — строка идёт в `tasks.md §Next` | | 🔍 NEED_INFO стратегический (меняет вектор) | Правка в `§Milestones` или `§Drift Guard` — это не блокер, а изменение плана | | ⏹️ STOPPED | `plan.md` не меняется — запись только в `log.md` | Если первоначальный подход оказался тупиком, scope поменялся, milestone потерял смысл — это всегда правка `plan.md` в `§Milestones` / `§Drift Guard` / `§Contingency`, а не блокер. ### Шаг 4. Запиши стоп-кадр в `log.md` проекта Открой `01_now/projects//log.md` и добавь запись в формате: ``` - YYYY-MM-DD: <МАРКЕР> PAUSED | Задача: <что делали>. Остановился на: <конкретная точка>. Причина: <почему переключаемся>. Действие: <что сделано для разблокировки — кому написал, что делегировал, куда записал идею>. Вернуться когда: <триггер возврата>. ``` Нейтральный пример: ``` - 2026-03-07: BLOCKED PAUSED | Задача: пересчитать модель запуска. Остановился на: собрал все метрики кроме одного входного показателя. Причина: нет подтверждённых данных от ответственного. Действие: записал делегирование в файл ответственного. Вернуться когда: получу данные или через 3 дня. ``` Для типа `⏹️ STOPPED` формат короче: ``` - 2026-03-07: ⏹️ STOPPED PAUSED | Задача: <что делали>. Остановился на: <конкретная точка>. Следующий шаг: <что делать при возврате>. ``` ### Шаг 5. Создай/обнови маркер-задачу в целевом файле Выбор файла жёстко зависит от типа прерывания: | Тип | Куда идёт маркер | Формат | |-----|------------------|--------| | `⏸️ BLOCKED` | **`/plan.md §Blockers`** — новая карточка Bx + `blocked on Bx` на затронутых milestone'ах | карточка блокера со всеми полями (см. Шаг 3) | | `🔀 DELEGATED` без milestone-impact | **Только** `01_now/ops//delegations/.md` Active | `- [ ] YYYY-MM-DD → <суть> [tracker-link] • due: <дата> • [контекст](chat-or-log-ref)` | | `🔀 DELEGATED` с milestone-impact | `delegations/.md` Active **+** `plan.md §Blockers` Bx (`Тип: delegated-work`) со ссылкой на строку в delegations | карточка блокера + lean-index строка, двусторонне связанные | | `🔀 DELEGATED` без трекера | `delegations/.md` с пометкой `tracker_sot: none` + `plan.md §Blockers` если блокирует milestone | карточка блокера + lean-index без tracker-link | | `🔍 NEED_INFO` тактический | `/tasks.md §Next` | `- [ ] 🔍 <собрать X> → <что после> (YYYY-MM-DD)` | | `🔍 NEED_INFO` стратегический | `/plan.md §Milestones` или `§Drift Guard` | правка плана, не строка-маркер | | `⏹️ STOPPED` | Только запись в `/log.md` (см. Шаг 4). `tasks.md §Active` остаётся как есть | — | **Convergence rule для delegated-work blockers:** если сотрудник перестаёт блокировать milestone (делегирование выполнено или больше не критично), блокер закрывается по ritual §5.4.2 методологии — карточка переезжает в `## Blockers — Resolved`, статус milestone снимается, строка в `delegations/.md` переходит в `Done (7d)`. Нейтральный пример карточки блокера в `plan.md`: ```markdown ### B1 — Недостающий показатель от ответственного - Открыт: 2026-03-07 - Тип: delegated-work - Ждём: подтверждённый показатель, чтобы пересчитать модель - Блокирует: M3 - Моё действие: напомнить ответственному через 3 дня - Условие возврата: получены подтверждённые данные - Fallback: взять оценку из последнего отчёта и пометить как приближение - Stale check: 7 дней ``` Нейтральный пример параллельной строки в `delegations/responsible.md`: ```markdown - [ ] 2026-03-07 → собрать недостающий показатель [TRACKER-123](url) • due: 2026-03-10 • ссылка на `plan.md#b1` ``` ### Шаг 6. Подтверди парковку Ответь пользователю одним коротким сообщением в формате: > Припарковался. [Проект X] — записал стоп-кадр в log.md, маркер в [целевой файл]. > (если применимо) plan.md обновлён: [что изменилось]. > Точка остановки: [краткое описание]. > Триггер возврата: [условие]. > Можем переключаться. Пример с делегированием: > Припарковался. 2026-example — log.md, делегирование в ops/2026-example/delegations/responsible.md. > Точка остановки: собрал все метрики кроме одного показателя. > Триггер возврата: ответственный присылает данные или 2026-03-10. > Можем переключаться. ## Ограничение глубины переключений Если пользователь уже находится на первом уровне переключения (ушёл от основной задачи A к сервисной B) и хочет нырнуть ещё глубже (задача C) — заблокируй: > «Это второй уровень переключения. Записываю задачу [C] в tasks.md/inbox — вернёмся к ней отдельно. Сейчас заканчиваем [B] или паркуемся и возвращаемся к [A].» Максимальная допустимая глубина: 1 уровень. ## Протокол «длинный чат» Если в текущем чате уже было 2+ парковки или диалог явно длинный и многотемный — предупреди: > «Чат стал длинным. Рекомендую продолжить в новой сессии — я подхвачу контекст из log.md при вызове /resume.» ## Проактивная парковка Если пользователь начинает говорить о другом проекте/задаче без явной команды парковки, и при этом в текущем чате шла содержательная работа — предложи: > «Вижу, что переключаемся. Сделать стоп-кадр по [текущая задача], чтобы не потерять точку возврата?» Не навязывай — если пользователь говорит «не надо» или переключение тривиальное (короткий вопрос, не требующий глубокого погружения) — пропусти.