# Tfw Plan > Команда /tfw-plan создаёт и согласует задачу TFW, выбирает ручное или явно разрешённое автономное исполнение и в автономном режиме последовательно координирует отдельные handoff/review Codex-задачи до финальной человеческой приёмки. - Skill: `saubakirov/tfw-plan-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add saubakirov/tfw-plan-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/saubakirov/tfw-plan-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-plan-2 --- # /tfw-plan Преврати обычный запрос любого типа в проверяемую задачу, отдели постановку от исполнения и после Gate 0 координируй выбранный пользователем режим. Пользователю не обязательно знать slash-команду или устройство TFW. Plan не исполняет результат и не подменяет handoff/review. ## 1. Ориентация до записи 1. Прочитай `PROJECT.md`, `AGENTS.md`, `knowledge/INDEX.md` и только нужные записи `knowledge/records/`. 2. Определи текущее состояние и проблему; желаемое изменение; адресата; владельца приёмки; наблюдаемые критерии; источники; ограничения; формат результата и способ проверки. 3. Отдели факты от предположений. Если ответа не хватает для выбора результата, проверки или удержания существенного риска, одним сообщением задай не более трёх вопросов. Иначе явно запиши допущения и продолжай. 4. Определи текущего участника и его корпоративную/проектную роли по identity gate из `AGENTS.md` и `.agents/skills/tfw-identity/SKILL.md`. Обычному человеку достаточно естественного ответа с полным именем и фамилией; не показывай команду, identifier или локальный формат. Для нового profile соблюдай surname/collision gate, существующий valid identifier не пересчитывай. Автор новой записи равен определённому участнику, но владелец существующей задачи не меняется из-за нового чата. ## 2. Создай ID и пройди Gate идентификации 1. Сформируй slug из строчных латинских букв, цифр, `.`, `_`, `-`; первый символ — буква или цифра, последовательность `__` запрещена. 2. Новый `ID = YYYYMMDD-HHMMSS__slug`. Handle владельца в ID и путь не включай: авторство хранится только в обязательном поле `Владелец`. 3. Атомарно создай только отсутствующую папку `workspace//`. Если путь уже существует, не переиспользуй и не перезаписывай его: получи новый фактический timestamp и повтори создание. 4. Сразу после создания папки и до содержательного заполнения плана установи точное имя текущей Codex-задачи `plan | ` и проверь успешный ответ операции либо последующее состояние. 5. Если точное имя нельзя установить или подтвердить, не создавай содержательный trace: сообщи требуемое имя как блокер раннего gate. Legacy task folders не переименовываются. Если plan продолжает ранее созданную legacy-задачу, видимый номер исключает только однозначный средний `__handle`, а полный ID и стабильный путь остаются прежними. ## 3. Запиши постановку 1. Создай `workspace//TRACE.md` с начальным `Статус: doing` и отдельными полями `Владелец`, `Текущий участник: `, `Корпоративная роль текущего участника`, `Проектная роль текущего участника` и `Роль ИИ: plan`. 2. Заполни обязательные поля и план по `шаблоны/план_работы.md`: результат и приёмка, текущее состояние, границы и источники, вопросы и допущения, DoD/DoF, фазы и Gates. 3. Обязательно добавь `Режим исполнения: ожидает выбора пользователя` и объясни: - **ручной:** пользователь сам запускает каждый следующий чат по точной команде; - **автономный:** plan с отдельного явного разрешения создаёт и контролирует Codex-задачи только текущего task ID. 4. Предъяви краткое понимание и план. Явно попроси одним решением утвердить Gate 0 и выбрать режим. До утверждения не создавай итоговый результат, не начинай активные изменения и не создавай handoff/review-задачи. ## 4. После ответа пользователя - Если Gate 0 не утверждён, запиши замечания и оставайся в планировании. - Если утверждён, запиши отдельные поля `Gate 0`, `Основание Gate 0`, точное `Режим исполнения: ручной` либо `Режим исполнения: автономный` и основание выбора. - Автономное разрешение ограничь этим task ID и последовательным циклом handoff/review. Оно не разрешает менять постановку, обходить неделегируемые gates, создавать посторонние задачи или одновременно редактировать один trace. ### Ручной режим Запиши следующий шаг и выдай точную команду нового чата `/tfw-handoff `. Дальнейшие переходы контролирует пользователь; обязательные name gates и отчёты ролей сохраняются. ### Автономный режим 1. Проверь, что среда действительно предоставляет создание, именование, ожидание, чтение и продолжение Codex-задач. Если нет — честно переключись только на ручной режим и выдай точную команду; не заявляй автономность, которой нет. 2. Зафиксируй идентификатор coordinator thread и обязательный адрес отчётов. 3. Создай отдельную Codex-задачу handoff с ожидаемым именем `handoff | `. Передай полный стабильный путь, coordinator thread, запрет параллельной записи, обязательные preflight/exception/final reports и указание не задавать identity-вопрос отсутствующему человеку: текущий участник и обе его роли для автономной задачи — `не применимо`, владелец наследуется из trace. 4. Пока дочерняя роль активна, plan не редактирует task folder. Ожидай bounded-wait операциями; запрос внимания, blocker или deviation немедленно возвращай человеку. 5. После финального отчёта read-only сверь фактический статус, trace, результат и решение о знании. Отсутствие отчёта, неверное имя или расхождение с trace не являются успехом: запроси отчёт повторно либо зафиксируй блокер. 6. При `Статус: review` и полной самопроверке создай отдельную Codex-задачу `review | ` с `/tfw-review <стабильный путь>` и тем же протоколом отчёта. 7. При `FAIL` и `Статус: doing` передай доказанные дефекты новой handoff-задаче; после исправления создай новую review-задачу. Не меняй постановку и не проси пользователя вручную переносить дефекты. 8. Продолжай цикл, пока дефекты устранимы в границах. Повторяющийся нерешаемый дефект, отклонение от плана, конфликт писателей, недоступный обязательный ресурс или неделегируемое действие — доказанный blocker, а не бесконечный цикл. 9. При независимом `PASS` убедись, что `Решение о знании` фактически исполнено и проверено. Сформируй один финальный пакет: результат, доказательства, central/внешние эффекты, knowledge decision, остаточные риски и вопрос о человеческой приёмке. 10. Только явное принятие владельцем после `PASS` позволяет plan изменить единственное поле `Статус: review → done`. Отклонение возвращает задачу в новый handoff. ## 5. Отчётный протокол ролей В автономном режиме каждый handoff/review обязан отправить coordinator thread: - **preflight:** фактическое имя и thread ID, отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ, полный task ID и путь, статус, основание допуска, baseline/hash, первая фаза; - **exception:** немедленно — точные доказательства blocker/deviation/conflict/name-gate failure и остановка; - **final:** фактическое имя, отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ, статус, task/trace/result paths, созданные/изменённые файлы, проверки и hashes, shared/local manifests, дефекты/блокеры, решение о знании, остаточные риски и точный рекомендуемый переход. Если сообщение coordinator thread технически не отправлено, этап не считается завершённым. Роль сохраняет устойчивое состояние в trace, возвращает тот же отчёт в своём чате и требует ручной передачи. ## Где остановиться До Gate 0 — на запросе утверждения и режима. В ручном режиме — после точной следующей команды. В автономном — на доказанном blocker/deviation, неделегируемом gate либо на финальной человеческой приёмке после `PASS`. Не обещай работу при закрытом Codex, универсальную доступность thread-операций, аутентификацию участника, безопасную параллельную запись или завершённую удалённую синхронизацию. Исполнение — `/tfw-handoff`. Независимая проверка — `/tfw-review`. Обновление набора — `/tfw-update`.