Boyko Preflight

---
name: boyko-preflight
description: >
  Честная самопроверка в начале сессии в ЛЮБОМ проекте (не только
  Claude-cod-top-2026) — отвечает не на вопрос "установлен ли глобальный
  слой" (для этого /doctor), а на вопрос "применяется ли он ИМЕННО СЕЙЧАС,
  в этой конкретной сессии". Перечисляет реально загруженные файлы из
  ~/.claude/rules/*.md по именам, проверяет память (auto-memory MEMORY.md +
  реальный статус подключения внешних источников вроде Obsidian, не факт их
  наличия в конфиге), сработал ли dispatcher (project_classifier из
  CLAUDE.md), и цитирует хуки, реально сработавшие на это же сообщение.
  Дополнительно — recall-check: если задача уже названа, реально ищет по
  ключевым словам в `patterns.md`/`pearl_registry/INDEX.md`/`null_results/INDEX.md`,
  учтён ли уже релевантный прошлый урок, а не просто записан и забыт.
  Жёсткий запрет на "да, всё подключено" без цитаты/доказательства — если
  что-то не подтверждается, скилл требует явно написать "не вижу
  подтверждения". Останавливается и ждёт подтверждения пользователя, не
  переходит к работе сам.
  Triggers: /boyko-preflight, самопроверка, "проверь что настройки
  подключены", preflight check, "проверь окружение перед работой",
  "используешь ли ты мои настройки", "это точно из ~/.claude".
  НЕ для: диагностики самой установки — файлы на диске, разрешение
  конфликтов, версия (→ /doctor), брифинга по содержанию проекта (→
  /orient), полного аудита архитектуры (→ /boyko-project-radar). Этот
  скилл — только про "прямо сейчас, в этой сессии, реально применяется
  или только теоретически доступно".
effort: low
tokens: ~400
triggers: [/boyko-preflight, самопроверка, "проверь что настройки подключены", preflight check, "проверь окружение перед работой", "используешь ли ты мои настройки"]
---

<!-- BSV — Brief Skill View | поиск: BSV
Скил   : boyko-preflight
TL;DR  : Честно перечисляет что РЕАЛЬНО загружено/сработало в ЭТОЙ сессии, не что "в принципе доступно". Останавливается, ждёт подтверждения.
Вызов  : /boyko-preflight, "самопроверка", "проверь что настройки подключены"
НЕ для : Диагностики установки на диске (→ /doctor), брифинга по проекту (→ /orient), полного аудита (→ /boyko-project-radar)
Выход  : 6 пунктов (правила, память, dispatcher, хуки, recall-check прошлых уроков, вердикт) + явный STOP до подтверждения пользователя
-->

# /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.]