Передача контекста между сессиями агента
Навык передачи контекста помогает сохранить важные данные между сессиями, улучшая качество работы агента. Он позволяет избежать потерь информации и повторных ошибок при переходе к новой сессии.
Экосистема: Универсальный
Инструкция
--- name: session-handoff description: "Use when context approaches capacity, before /clear or /compact, when switching tasks, or when ending a coding session: produces a structured handoff artifact for the next session." category: productivity risk: safe source: community source_repo: alapha888/session-handoff-kit source_type: community date_added: "2026-10-05" author: alapha888 tags: [context-management, session-handoff, coding-agents, workflow] tools: [claude, cursor, codex] license: "MIT" license_source: "https://github.com/alapha888/session-handoff-kit/blob/main/LICENSE" --- # Навык передачи контекста между сессиями ## Цель Большие контекстные окна ухудшают соблюдение инструкций, точность рассуждений и точность инструментов по мере накопления токенов. Долгие сессии заполняются устаревшими планами, прерванными черновиками и повторяющимися следами ошибок. Сброс до новой сессии восстанавливает производительность, но слепое отбрасывание контекста приводит к потере состояния, галлюцинированному прогрессу и повторяющимся ошибкам. Навык `session-handoff` стандартизирует, как агент фиксирует активное состояние. Он переводит эфемерную рабочую память в действительный, проверяемый документ-переход для следующей сессии. ## Когда использовать этот навык - Использование контекста приближается к пределу (примерно >60%), и сброс неизбежен. - Перед выполнением команд `/clear` или `/compact` в Claude Code, Cursor или Codex. - При смене задач в середине сессии или завершении кодирования, которое будет продолжено другой сессией (или агентом). --- ## Рабочий процесс: Завершение сессии (6 шагов) Запустите эту последовательность, когда сессия агента достигает операционных пределов или когда работа приостанавливается: 1. **Аудит состояния Git и рабочего пространства** Выполните `git status -s` и `git diff --stat`, чтобы установить реальное состояние. Никогда не полагайтесь на память чата о том, что было изменено. Определите измененные, неотслеживаемые и подготовленные файлы. 2. **Зафиксируйте целевое состояние против реализованной реальности** Определите исходную цель в одном предложении. Документируйте точно то, что было проверено как работающее (с проходящими тестовыми командами или проверками времени выполнения) по сравнению с тем, что остается частичным или непроверенным. 3. **Запишите принятые решения и отвергнутые пути** Перечислите архитектурные и дизайнерские решения, принятые в ходе сессии, вместе с конкретной аргументацией. Явно запишите отрицательные решения (подходы, которые были опробованы и отвергнуты), чтобы предотвратить повторные попытки неудачных решений следующими агентами. 4. **Каталогизируйте затронутые файлы и соответствующие символы** Перечислите ключевые пути к файлам, функции, классы и определения схем, которые были изменены или упомянуты. Включите ссылки на строки, где это уместно. 5. **Изолируйте открытые циклы с владельцами и проверками** Перечислите все неразрешенные крайние случаи, неудачные тесты, отложенные задачи и ограничения среды. Каждый открытый цикл должен указывать, кто его решает (Человек или Агент) и как будет проверено завершение. 6. **Укажите немедленное следующее действие** Составьте одну, атомарную, недвусмысленную инструкцию для следующего агента, чтобы выполнить ее в первый ход. Не предоставляйте широкий список; укажите точную команду для выполнения или файл для редактирования в первую очередь. --- ## Правила работы - **Отделяйте факты от предположений**: Тест, который прошел, — это факт; предположение, что код работает, потому что он скомпилирован, — это спекуляция. Явно помечайте непроверенные предположения как `[UNVERIFIED]`. - **Обязывайте владельцев и проверки для открытых циклов**: Каждый открытый цикл должен указывать владельца (`Human` или `Agent`) и детерминированные критерии проверки (например, `pytest tests/auth/test_token.py:test_refresh_rotation passes`). - **Запрещайте неопределенные продолжения**: Никогда не пишите "продолжить работу над аутентификацией" или "завершить компоненты фронтенда". Укажите точный символ, файл и режим ошибки. - **Ссылайтесь на реальные идентификаторы рабочего пространства**: Все ссылки на код должны использовать точные пути к файлам и имена символов. Не используйте обобщенные описания псевдокода. --- ## Пример: Запись передачи сессии ```markdown # Session Handoff: JWT Rotation Implementation ### Goal & Current State - **Target Goal**: Implement refresh token rotation and revocation in the FastAPI auth service. - **Current State**: Refresh token database migration applied and rotation endpoint created. Token generation and database persistence work. Revocation blacklist cache is not yet wired into the dependency validator. - **Verification**: `pytest tests/test_auth_tokens.py` passes (4/4 tests). ### Decisions Made (With Reasons) - **Used Redis for Token Revocation List**: Selected Redis over Postgres lookups for revoked JTI tokens to keep latency under 5ms on protected routes. - **Rejected Stateless Refresh Tokens**: We initially evaluated sliding expiration in JWT claims without persistence, but discarded it because compromised tokens could not be revoked before natural expiry. - **Token Format**: Chose UUIDv4 for `jti` claim to maintain compatibility with existing session storage schemas. ### Files Changed - `src/services/auth.py`: Added `rotate_refresh_token(old_token: str)` function and Redis invalidation call. - `src/models/tokens.py`: Added `RefreshTokenRecord` SQLModel table for tracking token families. - `alembic/versions/20261005_add_token_families.py`: Migration creating `token_records` table. - `tests/test_auth_tokens.py`: Added unit tests for token family generation and rotation. ### Open Loops - [Agent] Wire `verify_token_not_revoked` into `src/api/deps.py` -> Verify by checking `tests/test_auth_deps.py` fails on blacklisted token. - [Agent] Handle database rollback if Redis is unreachable during rotation -> Verify by mocking Redis connection failure in unit test. - [Human] Set `REDIS_AUTH_URL` secret in `.env.test` for CI execution. ### Next Action Open `src/api/deps.py` and import `is_token_blacklisted` from `src.services.auth`. Insert the check into `get_current_user` directly after JWT decode verification. ### Watch-outs - Do not modify the existing `access_token` expiration time (currently 15 minutes) in `src/core/config.py`. - Alembic migration `20261005_add_token_families.py` must run before starting the API server locally (`alembic upgrade head`). ``` --- ## Антипаттерны - **Сброс транскрипта чата**: Вставка сырых логов разговоров в заметку передачи. Контекстное окно следующей сессии немедленно загрязняется тем самым разговорным шумом, от которого вы хотели избавиться. - **Призрак завершения**: Обозначение модуля как "завершенного", когда он только написан, но не выполнен или не протестирован. - **Пропущенный тупик**: Пропуск решений, которые не сработали. Следующий агент прочитает кодовую базу, увидит тот же очевидный путь и повторно реализует неудачный подход. - **Абстрактный следующий шаг**: Завершение с "Следующее: реализовать оставшиеся тесты." Новый агент тратит 3-5 ненужных ходов, чтобы выяснить, что нужно протестировать. ## Ограничения - Этот навык производит письменную передачу только; он не может сохранить живое состояние, такое как выполняющиеся процессы, незафиксированный вывод терминала или контекст отладки в памяти — запишите все, что имеет значение, явно в заметке. - Качество передачи ограничено тем, что записывает исходящая сессия: решения, тупики или изменения файлов, которые не записаны, не могут быть восстановлены следующей сессией. - Он не заменяет систему контроля версий или отслеживание задач; сначала зафиксируйте работу и ссылайтесь на коммиты или тикеты в заметке, вместо того чтобы дублировать их.Источник на GitHub