/boyko-preflight — Честная самопроверка перед работой

Зачем это отдельно от /doctor

/doctor отвечает на вопрос "установлено ли на диске". Этот скилл отвечает на другой вопрос: "применяется ли это ИМЕННО В ЭТОЙ СЕССИИ, прямо сейчас". Модель почти всегда может подтвердить первое (файлы правда есть на диске) — но не факт, что она реально СЛЕДУЕТ им в конкретном разговоре, а не просто знает об их существовании. Разница между "знаю о правиле" и "применяю правило" — ровно то, что этот скилл проверяет.

Ключевая дисциплина: не сглаживать

Модель по умолчанию склонна отвечать "да, всё подключено и работает" даже когда не до конца уверена — это самый частый и самый бесполезный ответ на самопроверку. Если что-то из пунктов ниже нельзя подтвердить цитатой или конкретным именем файла — пиши прямо: "не вижу подтверждения". Это единственный содержательный результат этого скилла; "всё ок" без доказательства = скилл не выполнил свою работу.

Шаги

1. Правила — точный список файлов, не общая фраза

Перечисли КАЖДЫЙ файл из ~/.claude/rules/*.md, который реально виден в твоём системном промпте прямо сейчас — по имени файла (integrity.md, security.md, falsification-ladder.md и т.д.), не "да, у меня есть правила проекта". Если списка правил в системном промпте нет вообще — так и напиши, не выдумывай.

Длинная сессия — отдельная оговорка (не игнорируй, реальный случай, 2026-09-07): если разговор уже длинный (десятки ходов, возможны компакции контекста), полное содержимое правил ты, скорее всего, видел ОДИН раз — в самом начале сессии — и с тех пор полагаешься на память транскрипта, не на свежий гарантированный дамп. Это нормально и не считается провалом проверки, но скажи это явно: "список с начала сессии, свежего дампа прямо сейчас не вижу" — не выдавай память транскрипта за подтверждённый факт текущего момента без оговорки.

Также помни (см. CLAUDE.md's таблицу RULES): не все правила всегда-загружены. Часть — paths:-scoped (например testing.md — только на файлах тестов) — они могут появиться ПОЗЖЕ, отдельными вставками, привязанными к конкретной операции, и отсутствие их в начальном списке — не ошибка, а норма для этого класса правил.

2. Память — auto-memory и MCP-источники с живым статусом (Obsidian и т.п., НЕ все KNOWLEDGE STORES)

Это отдельная категория от "правил" — проверь её отдельно, не смешивая:

• Auto-memory (MEMORY.md) — виден ли в контексте блок с профилем пользователя, активными проектами, известными паттернами? Если да — назови конкретно, что там есть (не "да, память подключена", а "вижу заметки про X, Y, Z"). Если нет — "не вижу подтверждения".
• Внешние источники памяти (Obsidian vault, MCP-серверы памяти и т.п.) — проверь их РЕАЛЬНЫЙ статус подключения в этой сессии, не факт их существования в конфиге. MCP-сервер может быть: подключён и доступен / ещё подключается ("still connecting", инструменты появятся позже) / отключился ("no longer available") / требует авторизации. Это РЕАЛЬНЫЕ статусы, которые меняются в течение одной сессии (наблюдалось напрямую в этом же проекте: obsidian-vault disconnect → reconnect в одном разговоре) — не полагайся на то, что сервер был доступен раньше в этой же сессии, если сейчас нет свежего подтверждения его статуса. Формулируй это честно даже при наличии недавнего успешного вызова: "сужу по последнему успешному вызову в этой сессии, не по гарантии, что соединение живо в этот самый момент" — "было доступно тогда" и "доступно прямо сейчас" не одно и то же, и второе почти никогда нельзя подтвердить без нового вызова именно в момент проверки.

Явная граница (не молчи об этом): CLAUDE.md's таблица "KNOWLEDGE STORES" называет ещё несколько хранилищ — graphify (meta-graph), NotebookLM, Context7, Firecrawl, Perplexity, Slack/Notion. Этот скилл проверяет только то, у чего есть ЖИВОЙ сессионный статус (MCP-подключения вроде Obsidian) — graphify и подобные внешние CLI-инструменты поверх статичных файлов на диске у него нет "статуса подключения" в этом смысле, только "файл существует / не существует", а это уже /doctor. Не подгоняй graphify под ту же формулировку про "connected/disconnected" — вместо этого прямо скажи: "graphify и другие CLI-хранилища из KNOWLEDGE STORES вне области этой проверки, см. /doctor". Умолчание об этой границе хуже, чем явное "не проверяю".

3. Dispatcher — сработал или нет

CLAUDE.md (если загружен) описывает SessionStart hook project_classifier, который должен был классифицировать текущий проект (research / production / MVP и т.д.) и предложить методологию ДО начала работы. Проверь: есть ли в контексте этой сессии реальный вывод этого классификатора (обычно в SessionStart hook additional context)? Если да — процитируй вердикт дословно. Если нет — напиши "dispatcher не сработал или не виден", не придумывай классификацию задним числом.

Если вердикт был AMBIGUOUS/неопределённым (тип проекта требует подтверждения) — не останавливайся на цитате вердикта, проверь, был ли он реально разрешён в ходе сессии (явный выбор ветки методологии), или методология применялась ad hoc, без формального закрытия неопределённости (живой случай, 2026-09-07: GeoScan Gold — dispatcher выдал tie между research/production/mvp, тип так и не был подтверждён явно ни в одном ходе). Открытая неопределённость, которую никто не закрыл, — тоже часть "не сглаживать", не менее важна, чем сам факт срабатывания.

4. Хуки на это самое сообщение

Это сообщение прошло через UserPromptSubmit (если глобальные хуки установлены). Если в контексте есть вывод каких-то хуков, сработавших именно на него (routing-floor, resource-router, keyword-router, null-checks и т.п.) — процитируй их как есть. Если ничего не видно — напиши "на это сообщение хуков не видно", это тоже валидный и полезный результат.

Если видишь хук другого типа (например SubagentStart/SessionStart, сработавший не на текст сообщения, а на другое событие) — не путай его с UserPromptSubmit-хуком и не засчитывай как "хуки сработали на сообщение". Назови его тип явно и объясни, почему это не то же самое.

Важная граница: этот скилл не отвечает за проверку СВЕЖЕСТИ кода/тестов ("проходят ли тесты прямо сейчас", "не устарел ли коммит") — это другой класс хуков (например commit/test-freshness guards) с другой задачей. Если такой хук сработал в этой же сессии — не включай его результат в вывод [boyko-preflight] как если бы это была часть самопроверки глобального слоя; это отдельная, самостоятельная проверка.

5. Recall-check — учимся на своих ошибках, или просто их записываем?

Это отдельный, честный ответ на вопрос: "у нас есть склад заметок (~/.claude/memory/patterns.md [AVOID]/[REPEAT], pearl_registry/INDEX.md, null_results/INDEX.md), но реально ли он ПРИМЕНЯЕТСЯ к задаче прямо сейчас, или это архив, который пишется, но не читается?" (источник: разговор с пользователем 2026-09-07 — автоматические хуки null_results_pre_check.py/null_retroscan.py за этот же вечер несколько раз честно предупреждали о совпадении с уже похороненной гипотезой, но решение "это шум или реальное совпадение" каждый раз принималось на глаз, без гарантии, что предупреждение реально проверили).

Если задача уже названа (в этом же сообщении или сразу после него) — активно поищи по ключевым словам/теме в patterns.md, pearl_registry/INDEX.md, null_results/INDEX.md (grep, не по памяти) — реально ли там уже есть релевантная запись. Если да — назови её явно ([AVOID×N], id null_result, дата pearl) и скажи, учтена ли она в текущем подходе или проигнорирована. Если нет совпадений — так и напиши: "не нашёл релевантной записи по ключевым словам X, Y" — это тоже полезный, а не пустой результат.

Если задача ещё не названа (обычный preflight "проверь что подключено" без конкретики) — не делай вид, что этот пункт выполнен. Напиши прямо: "без конкретной задачи recall-check провести нельзя — проверю, как только скажешь, что делаем" и выполни его в СЛЕДУЮЩЕМ сообщении, когда задача станет известна, а не пропускай молча.

Не путай это с тем, что автоматический хук null-results-pre-check УЖЕ мог сработать на это же сообщение (см. пункт 4) — тот хук ищет только по токенам в slug'е, дёшево и не всегда точно (сам не раз давал ложные совпадения в этой же сессии). Этот пункт скилла — более внимательная, осознанная ручная проверка, а не дублирование автоматики; если хук уже предупредил, здесь нужно РЕАЛЬНО открыть указанную запись и решить, относится она к делу или нет, а не просто повторить предупреждение хука.

6. Вердикт — без хвалебных обобщений

Собери пять пунктов выше в короткий вывод. Формат — не проза, а прямые факты:

[boyko-preflight]
Правила: <список файлов ИЛИ "не вижу подтверждения"> [+ оговорка про длинную сессию, если применимо]
Память: <что видно из auto-memory/Obsidian ИЛИ "не вижу подтверждения"> [+ реальный статус MCP-подключения]
Dispatcher: <вердикт дословно ИЛИ "не сработал/не виден">
Хуки на это сообщение: <цитаты ИЛИ "не видно">
Recall-check: <найденная релевантная запись + учтена ли ИЛИ "нет совпадений" ИЛИ "задача не названа, проверю потом">

Не добавляй общий вывод вроде "всё в порядке" или "настройки применяются" — пусть пользователь сам сделает вывод по пяти конкретным пунктам.

Стоп перед работой

После вывода — остановись. Не переходи к реальной задаче, пока пользователь явно не подтвердит, что можно продолжать. Это единственный скилл в каталоге, который намеренно ничего не делает после самопроверки, кроме ожидания.

Статус и история валидации (перенесено из frontmatter 2026-09-10)

Описание грузится в системный промпт КАЖДЫЙ ход; статус нужен только при реальном запуске.

[STATUS: dogfooded для шагов 1-4 (n=2 реальных прогона на разных проектах — VeriFind-2026 софт, GeoScan Gold геология/майнинг, + 4 синтетических eval'а через skill-creator, оба прогона нашли реальные пробелы и оба закрыты правками); [STATUS: described, n=0] для шага 5 (recall-check) — добавлен 2026-09-07 по прямому запросу пользователя ("учимся на ошибках, или просто их записываем?"), ни разу не прогонялся. Переносится между содержательно разными доменами без потери качества в уже проверенной части — не переобучен на Claude-cod-top-2026.]