# Tfw Review > Команда /tfw-review в отдельной Codex-задаче независимо аудирует результат по исходным DoD/DoF, не исправляет его, сообщает PASS/FAIL координатору и сохраняет человеческий gate перед done. - Skill: `saubakirov/tfw-review-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add saubakirov/tfw-review-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/saubakirov/tfw-review-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-review-2 --- # /tfw-review Независимо проверь результат после `/tfw-handoff`. Работай с существующей задачей и единственным `TRACE.md`; не создавай новый ID, параллельный trace или новый результат. ## Договор - Путь задачи всегда `workspace//` и не меняется при `PASS`, `FAIL` или человеческой приёмке. - Человек остаётся владельцем записи. Новый чат меняет роль ИИ, но не владельца. - В автономной задаче текущий участник и его корпоративная/проектная роли равны `не применимо (автономная роль)`; это не имитирует человека у компьютера. - Не редактируй результат, не исправляй дефекты и не дописывай отсутствующую самопроверку. - Не меняй постановку, план, границы, DoD/DoF или gates; не смягчай критерии ради `PASS`. - Не считай вывод handoff доказательством: перечитай результат и источники, повтори доступные проверки. - Не устанавливай `done`. При признаках параллельной записи остановись и отправь exception-report. ## 1. Gate идентификации — первое действие 1. Прими точный ID или стабильный путь. Новый ID используется дословно. Для однозначного legacy-ID `YYYYMMDD-HHMMSS__handle__slug` видимый номер равен `YYYYMMDD-HHMMSS__slug`; внутренний ID и стабильный путь не сокращай. 2. До чтения результата, авторитетных источников и начала аудита установи точное имя текущей Codex-задачи `review | `. 3. Проверь успешный ответ операции либо последующее состояние. Markdown, handle, номер цикла, произвольный суффикс, иной регистр или разделитель запрещены. 4. Если имя нельзя установить или подтвердить, остановись до содержательной работы и сообщи требуемое имя plan или пользователю как blocker. Если аргумент не указан, допустим только read-only поиск единственного `review`-кандидата с Gate 0, существующим результатом и самопроверкой, чтобы получить ID; сразу после выбора пройди name gate. При нескольких кандидатах задай один вопрос и ничего не меняй. ## 2. Выбери задачу и проверь допуск 1. Для пути проверь, что он разрешается в непосредственную task folder внутри `workspace/`, содержит `TRACE.md`, имя папки равно ID и `Статус: review`. 2. Для ID найди ровно одну `workspace//`; не выбирай частичное совпадение и не ищи в статусных каталогах. 3. Прочитай в порядке: `PROJECT.md`; `AGENTS.md`; `knowledge/INDEX.md`; весь выбранный trace; все источники/входы; все ожидаемые артефакты и результат. 4. Проверь обязательные поля, включая раздельные participant/corporate role/project role/owner/AI role; обратный план; отдельный Gate 0; существующие result paths; фактическую самопроверку каждого DoD/DoF и исполненное `Решение о знании`. 5. Сними baseline/hash результата и trace; проверь отсутствие необъяснённого изменения после handoff. Без полного допуска назови конкретный пробел и остановись, не исправляя его и не меняя статус. ## 3. Обязательный preflight-report Если trace содержит coordinator thread или автономный режим, после допуска и до первой содержательной записи отправь coordinator thread: - фактическое имя и thread ID; отдельно текущий участник, его корпоративная/проектная роли, владелец задачи и роль ИИ; - роль/этап, полный task ID, task/trace/result paths и статус; - основание допуска, baseline hashes и подтверждение single-writer; - перечень проверочной базы и первую фазу аудита; - блокеры/отклонения либо их отсутствие. Не начинай автономный этап без отправленного preflight. При технически недоступной отправке верни отчёт в текущем чате и потребуй ручной передачи. ## 4. Проведи независимый аудит 1. После preflight запиши в ход работы дату review, основание допуска и прочитанные источники/артефакты. 2. Восстанови базу только из согласованного плана: желаемый результат, критерии, границы, DoD, DoF и gates. 3. Для каждого DoD запиши фактическое свидетельство и `выполнен`/`не выполнен`. 4. Для каждого DoF запиши фактическое свидетельство и `не обнаружен`/`обнаружен`. 5. Повтори структурные, содержательные и исполняемые проверки; фиксируй команды, exit codes, hashes и существенные результаты. 6. Отдельно проверь фактическое решение о знании, запрет преждевременного `done`, shared-write baselines/post-hashes и отсутствие local bindings TFW Full/Assisted в shared/package manifests и migration inputs. 7. Отдели блокирующие дефекты от рекомендаций вне согласованных критериев. ## 5. Вердикт и обязательный финальный отчёт ### PASS Только если каждый DoD доказан, ни один DoF не обнаружен, обязательные проверки прошли и блокирующего риска нет: - запиши `Вердикт независимого review: PASS`, дату, матрицу и остаточные неблокирующие риски; - оставь `Статус: review`; result и task folder не меняй; - укажи следующий шаг: финальный пакет plan и явная человеческая приёмка/отклонение. ### FAIL Если хотя бы один DoD не доказан, обнаружен DoF, обязательная проверка упала или существенный риск не снят: - запиши `Вердикт независимого review: FAIL` и приоритизированные дефекты: ожидаемое/фактическое, доказательство и условие перепроверки; - до и после записи вердикта зафиксируй SHA-256 результата и докажи, что артефакт не изменён; - измени только `Статус: review → doing`; task folder и поле `Результат` сохрани; - в ручном режиме выдай `/tfw-handoff `; в автономном рекомендуй plan создать новую handoff-задачу с доказанными дефектами. ### Final report После записи PASS/FAIL отправь coordinator thread: фактическое имя/thread ID; отдельно текущий участник, его корпоративная/проектная роли, владелец и роль ИИ; вердикт и статус; task/trace/result paths; повторённые проверки/hashes/shared-local manifests; дефекты/блокеры/отклонения; решение о знании; остаточные риски и точный следующий переход. Если финальный отчёт не отправлен, автономный этап не завершён. Сохрани устойчивое состояние в trace и верни отчёт в текущем чате для ручной передачи. Недоступный обязательный источник или технически невозможный аудит не превращай в выдуманный PASS/FAIL: запиши пробел, немедленно отправь exception-report и остановись без изменения результата. ## Где остановиться Остановись после `PASS` в `review`, после `FAIL` в `doing`, на обязательном человеческом gate или доказанном blocker. Reviewer не создаёт результат, не исправляет его и не подменяет человеческую приёмку. Планирование/координация — `/tfw-plan`. Исполнение/исправление — `/tfw-handoff`.