# Tfw Handoff > Команда /tfw-handoff в отдельной Codex-задаче исполняет согласованный план или доказанные исправления, ведёт единственный стабильный trace, отчитывается координатору и передаёт самопроверенный результат в независимый review. - Skill: `saubakirov/tfw-handoff-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add saubakirov/tfw-handoff-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/saubakirov/tfw-handoff-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: saubakirov (https://skillmd.com/u/saubakirov) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/saubakirov/tfw-handoff-2 --- # /tfw-handoff Прими существующую задачу как исполнитель. Продолжай её единственный `TRACE.md`; не создавай новый ID или параллельный след. ## Договор - Путь задачи всегда `workspace//` и не меняется при переходах статуса. - Человек остаётся владельцем записи; новый чат меняет рабочую роль ИИ, а не владельца. - В автономной задаче текущий участник и его корпоративная/проектная роли равны `не применимо (автономная роль)`; это не меняет владельца из trace. - Исполняй только согласованный план. Не меняй молча результат, аудиторию, границы, DoD/DoF или обязательные gates. - Handoff и review не работают одновременно. При признаках параллельного изменения остановись и отправь exception-report. - Не создавай review-задачу сам, если это не поручено отдельным явным разрешением; в автономном цикле её создаёт plan-координатор после финального отчёта. ## 1. Gate идентификации — первое действие 1. Прими точный ID или стабильный путь. Для нового ID видимый номер равен ID. Для однозначного legacy-ID `YYYYMMDD-HHMMSS__handle__slug` видимый номер равен `YYYYMMDD-HHMMSS__slug`; внутренний ID и путь не сокращай. 2. До чтения результата, авторитетных источников и активных изменений установи точное имя текущей Codex-задачи `handoff | `. 3. Проверь успешный ответ операции переименования либо последующее состояние. Markdown, handle, номер цикла, произвольный суффикс, иной регистр или разделитель запрещены. 4. Если имя нельзя установить или доказуемо подтвердить, остановись до содержательной работы и сообщи требуемое имя plan или пользователю как blocker раннего gate. Если аргумент не указан, допустим только read-only поиск единственного `doing`-кандидата с Gate 0, чтобы получить точный ID; сразу после выбора пройди name gate и лишь затем читай результат и источники. При нескольких кандидатах задай один вопрос и ничего не меняй. ## 2. Выбери задачу и проверь допуск 1. Для явного пути проверь, что он разрешается в непосредственную task folder внутри `workspace/`, имя папки равно ID из trace и существует `TRACE.md`. 2. Для явного ID найди ровно одну папку `workspace//`; не выбирай по частичному совпадению и не ищи в legacy-каталогах статусов. 3. Прочитай в порядке: `PROJECT.md`; `AGENTS.md`; `knowledge/INDEX.md`; выбранный `TRACE.md` целиком; нужные records и остальные источники из trace. 4. Проверь: статус `doing`; обязательные поля, включая раздельные participant/corporate role/project role/owner/AI role; обратный план до хода работы; результат/замысел, границы, DoD/DoF, фазы/Gates; отдельную запись Gate 0; доступность источников; отсутствие необъяснённого изменения после baseline. Наличие плана не доказывает согласование. Без полного допуска назови точный пробел и остановись без изменения результата. ## 3. Обязательный preflight-report Если trace содержит coordinator thread или автономный режим, после допуска и до первой содержательной записи отправь coordinator thread: - фактическое точное название и thread ID; отдельно текущий участник, его корпоративная/проектная роли, владелец задачи и роль ИИ; - роль/этап, полный task ID, стабильный task/trace path и статус; - основание Gate 0 и режима; - baseline/hash и подтверждение single-writer; - первую исполняемую фазу; - блокеры/отклонения либо их отсутствие. Отсутствие отправленного отчёта не считается завершённым preflight. Если отправка технически недоступна, не начинай автономный этап: верни отчёт в текущем чате и потребуй ручной передачи. ## 4. Исполни план 1. Только после preflight запиши в `## Ход работы` дату handoff, основание допуска и первую фазу. 2. Выполняй согласованные фазы по порядку; веди источники, факты, выводы, решения, проверки, риски и следующий шаг. 3. Самостоятельно выбирай локальные способы реализации и исправляй обнаруженные дефекты внутри границ. 4. Для общей синхронизируемой папки непосредственно перед каждой записью перечитывай target/baseline, изменяй минимальный набор файлов и выполняй post-read/hash. Признак другого писателя или конфликтной копии требует exception-report; local registries TFW Full и Assisted не включай в shared/package manifests и не переноси между namespace. 5. При требовании изменить постановку или обязательный gate запиши deviation request, его влияние, немедленно отправь exception-report и остановись. 6. Не отправляй наружу, не публикуй, не оплачивай и не удаляй материальные данные только на основании плана. Явно включённая в Gate 0 локальная/центральная публикация в точный новый путь допустима после её внутренних gates; неожиданно существующий target является blocker до сверки. 7. На внутреннем Gate продолжай после доказуемой проверки. На человеческом или неделегируемом gate остановись ровно там. 8. Если пользователь поручил работать до конца, исправляй дефекты в границах без промежуточных вопросов. 9. Перед финальной передачей фактически исполни `Решение о знании`: `не переносить` с причиной, существующий проверяемый кандидат либо точное records-обновление, отдельно включённое в Gate 0. ## 5. Самопроверка и передача reviewer 1. Самопроверь каждый DoD и DoF. Запиши фактические свидетельства: файл, команда, exit code, hash, наблюдение и существенный вывод. Не называй самопроверку независимым вердиктом. 2. Убедись, что все артефакты и внутренние ссылки существуют, а необъяснённых protected changes нет. 3. Обнови поле `Результат` существующим путём от корня проекта. 4. Установи `Статус: review`; task folder не перемещай. 5. Обнови проверки и следующий шаг: отдельный независимый `/tfw-review`. 6. Отправь coordinator thread финальный отчёт: фактическое имя/thread ID; отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ; итоговый статус; task/trace/result paths; созданные/изменённые файлы; проверки/hashes/shared-local manifests; дефекты/блокеры/отклонения; решение о знании; остаточные риски и точную рекомендацию reviewer. 7. В ручном режиме также выдай точную команду `/tfw-review `. Если финальный отчёт coordinator thread не отправлен, автономный этап не завершён. Сохрани устойчивое состояние в trace и верни тот же отчёт в текущем чате для ручной передачи. ## Где остановиться Остановись на самопроверенном результате со `Статус: review`, обязательном человеческом gate или доказанном blocker. Не устанавливай `done` и не проводи независимое review сам. Планирование/координация — `/tfw-plan`. Независимая проверка — `/tfw-review`. Обновление набора — `/tfw-update`.