Boyko Specialist

---
name: boyko-specialist
description: >
  Локализует наиболее релевантных VERIFIED специалистов именно твоей узкой ниши (не общую
  область — точный подраздел: "dipolar dark matter cosmology", не "физика") и атакует
  проблему их же методами, словарём и инструментарием инсайдера — вместо взгляда снаружи
  широким фронтом. Read-only ядро: локализовать нишу (2-3 seminal работы + 2-3 живых
  ключевых автора, ранжированных по specialist_score) → вжиться в её словарь и открытые
  проблемы → узкий прицельный лит-поиск → 3-5 методов инсайдера, ранжированных по
  применимости → честный вердикт (решено/кем/что подходит нам/дешёвый следующий шаг).
  Каждый автор, статья и метод обязаны быть [VERIFIED] реальным поиском (WebSearch/
  WebFetch) до того как войдут в вывод — claim "релевантный специалист" звучит
  убедительно и потому обязан заземляться на проверяемые источники, иначе это самый
  опасный тип инструмента: уверенно-ошибающийся. НЕ обещает "лучшего в мире" — это
  недоказуемый claim; обещает наиболее точно подходящих под нишу из того, что нашлось.
  Родился из паттерна "extract the skill from the win": вручную сузили проблему до
  dipolar dark matter → нашли Blanchet; сузили до J₃(𝕆)-масс → нашли Singh — этот скилл
  автоматизирует тот же путь сужения, а не изобретает новый.
  Триггеры: /boyko-specialist, "кто лучший специалист в этой нише", "вживись в эксперта",
  "как решил бы это специалист в узкой области", "найди мою нишу для этой задачи",
  "world expert in this niche", "кто уже это решал", "узкий специалист по X",
  "кто разбирается в этом лучше всех".
  НЕ для: широкого обзора литературы, где нужна ширина а не глубина одной ниши
  (→ /academic-research), панели из нескольких РАЗНЫХ экспертов
  (→ /hypothesis-lab — там 9 голосов, здесь один узкий), переноса решения ИЗ другой
  области (→ /cross-domain — там мост наружу, здесь — вглубь ТВОЕЙ ниши), генерации
  конкурирующих объяснений одного явления (→ /hypothesis-arbiter).
effort: medium
tokens: ~5500
allowed-tools: Read, Grep, Glob, WebSearch, WebFetch, Skill
triggers: [/boyko-specialist, "кто лучший специалист в этой нише", "вживись в эксперта", "world expert in this niche", "узкий специалист по X", "найди мою нишу для этой задачи"]
---

<!-- BSV — Brief Skill View | поиск: BSV
Скил   : boyko-specialist
TL;DR  : Вживание в наиболее релевантного VERIFIED узкого специалиста именно твоей ниши — не широкий обзор, а глубина в одной точке
Вызов  : /boyko-specialist <проблема>, "кто лучший специалист в этой нише", "вживись в эксперта"
НЕ для : Широкого обзора (→ /academic-research), панели разных экспертов (→ /hypothesis-lab), моста из другой области (→ /cross-domain)
-->

# Boyko Specialist — вживание в узкого специалиста

## Проблема, которую решает

По умолчанию LLM (и человек) атакует незнакомую проблему **широким фронтом своей области**:
"это физика — подумаем как физик", "это ML — подумаем как ML-инженер". Это работает,
но упускает узкую, специфичную нишу, где проблема уже могла быть решена или частично
закрыта — потому что "физик вообще" не знает того, что знает "специалист именно по
dipolar dark matter cosmology" или "специалист именно по J₃(𝕆)-октонионным массам".

**Принцип:** для любой достаточно узкой проблемы почти всегда существует человек (или
горстка людей), для кого это не экзотика, а рутинный вопрос их поднаправления. Задача
скилла — найти ЭТОГО человека (или его метод), а не притворяться им из общих знаний.

## Чем это НЕ является (проверено перед созданием)

| Скилл | Что делает | Почему не заменяет этот |
|---|---|---|
| `/academic-research` | 6-7 фаз, **широкий** обзор (35-80 статей) | ширина, а здесь нужна **глубина в одной точке** |
| `/hypothesis-lab` | панель из **9 разных** экспертов | это множество голосов, здесь — **один** узкий |
| `/cross-domain` | тянет решения ИЗ других областей | обратное направление — мост наружу, не вглубь ниши |
| `/hypothesis-arbiter` | конкурирующие объяснения ОДНОГО явления | это про "почему", не про "кто это уже решал" |

Если ни один из вышеперечисленных не покрывает "дана проблема → найди того, для кого
это рутина, и укради его метод" — это оно.

---

## Протокол (Phase 0 → Phase 5, включая 0.5, обязательны; Phase 6 опциональна)

### Phase 0 — Zero-Signal Gate (обязательно первым)

Прежде чем локализовать нишу, проверь: есть ли в запросе (∃ конкретная проблема) и
(∃ достаточно материала, чтобы сузить её хотя бы на 1-2 шага)? Если запрос — туман
("хочу разобраться в физике", без конкретики) → не выдумывай нишу из воздуха, попроси
уточнить: что именно не получается, какой конкретный вопрос/число/эффект озадачил.

**Kill signal:** если после уточнения ниша всё ещё не сужается — остановись, это не
задача для этого скилла (возможно нужен `/brainstorming` или `/academic-research`).

### Phase 0.5 — Premise Falsification Check (обязательно, дешевле поиска специалиста)

Прежде чем искать нишу и специалиста, проверь дёшево и локально: **правда ли то, что
заявлено в постановке проблемы?** Версии совпадают там, где сказано "совпадают"? ОС та,
что заявлена? env vars/plugin list/collection args/path filters — те, что предполагались?

**Правило:** если дешёвая локальная проверка инварианта (версия/OS/конфиг/флаг) уже
опровергает или меняет посылку задачи — **останови поиск специалиста и сначала доложи
опровергнутую посылку**, а не иди искать нишевого эксперта под задачу, которая
сформулирована неточно.

Два разных исхода этой фазы, не путать:
- **Falsified premise** — заявленный факт оказался ложным (напр. "версии совпадают",
  а на деле нет) → это само по себе находка, доложи её первой строкой.
- **Falsified hypothesis** — факт подтвердился, но прямой дешёвый эксперимент (не поиск,
  а фактическая проверка — напр. воспроизвести с исправленным инвариантом и посмотреть,
  меняется ли результат) уже опроверг напрашивающуюся причину → тоже репортится прежде
  чем идти дальше, экономит поиск специалиста под мёртвую гипотезу.

Если после этой фазы посылка держится и дешёвый эксперимент ничего не разрешил —
переходи к Phase 1 нормально, специалист действительно нужен.

*(Источник правила: dogfood-прогон 2026-07-09 — поиск "специалиста по cross-platform
pytest collection divergence" чуть не начался до проверки локальной версии pytest;
апгрейд версии оказался дешевле и информативнее любого поиска эксперта.)*

### Phase 1 — Локализовать нишу (ядро скилла)

Из проблемы назвать **точный** узкий подраздел — не область, а её под-под-раздел:

```
Плохо:  "физика", "космология", "machine learning"
Хорошо: "dipolar dark matter cosmology", "J₃(𝕆)-октонионные модели масс фермионов",
        "peeking-robust sequential A/B testing для малых выборок"
```

Для найденной ниши назвать:
- 2-3 seminal работы (основополагающие, на которые ссылается всё поднаправление)
- 2-3 живых ключевых автора (кто активно публикуется именно в этом под-разделе сейчас)

**🛑 Verification Gate (не опционально, это ядро защиты от галлюцинации):**
Каждый автор и каждая работа здесь ДОЛЖНА быть подтверждена реальным поиском —
`WebSearch`/`WebFetch` напрямую — ПРЕЖДЕ чем войти в вывод.

| Маркер | Когда ставить |
|---|---|
| `[VERIFIED]` | Нашёл реальную статью/автора — приложи URL/DOI/arXiv ID |
| `[UNKNOWN]` | Не смог подтвердить — так и скажи: "не смог верифицировать, вот ближайшее найденное" |

**Жёсткое правило:** имя, звучащее правдоподобно = не то же самое, что имя, существующее
в реальности. Модель обучена генерировать правдоподобные имена авторов и названия статей —
это ровно тот режим отказа, который делает "личность специалиста" самым опасным типом
уверенно-ошибающегося инструмента, если не заземлить на поиск. Ни один автор не входит
в финальный вывод без `[VERIFIED]` или явной пометки `[UNKNOWN]`.

**Ranking — если verified-кандидатов больше одного, не бери первого попавшегося:**

```
specialist_score =
    3 × exact_niche_fit        (работает точно в этом под-разделе, не в родительской области)
  + 2 × seminal_contribution   (его работа — одна из тех 2-3 seminal, а не косвенная ссылка)
  + 2 × recent_activity        (публикация в последние ~3 года, не только историческая)
  + 2 × method_relevance       (его метод буквально применим к НАШЕЙ проблеме, не просто по теме)
  + 1 × network_signal         (цитируется/ссылается другими verified-авторами этой ниши)
  − 2 × only_broad_field_match (найден по родительской области, не по точной нише)
  − 2 × no_recent_publications (последняя работа >5-7 лет назад, если ниша активна)
  − 3 × unverifiable_identity  (не удалось подтвердить существование — не должен доходить
                                 сюда вообще, [UNKNOWN] отсекается раньше; страховка на случай
                                 слабой верификации)
```

Не обязательно считать вслух каждый раз — но если 2+ кандидата прошли `[VERIFIED]`,
эксплицитно скажи, почему выбран именно этот (какие компоненты формулы перевесили),
а не просто "вот специалист".

**Niche Confidence (обязательное поле, идёт вместе с локализацией ниши):**

```
Niche confidence: High / Medium / Low
Почему не выше: [что делает локализацию шаткой — мало seminal работ, ниша сама
                 расплывчата, авторы работают на стыке нескольких под-разделов, ...]
Что изменило бы нишу: [какой доп. сигнал сузил бы или скорректировал бы выбор]
```

Low confidence — не повод остановиться, это честный сигнал читателю: выводы из
Phase 4-5 наследуют ту же неуверенность и должны читаться с поправкой на неё.

### Phase 2 — Вжиться в специалиста

Прими рамку ниши как свою: её словарь (не переводи термины наружу), её стандартный
инструментарий (какие методы/техники там default, а не экзотика), её известные открытые
проблемы (что в этом под-разделе сейчас реально не решено, а не "открытые проблемы физики
вообще").

### Phase 3 — Узкий прицельный поиск

Лит-поиск СТРОГО по нише из Phase 1 (не по родительской области) — словарём из Phase 2.
Используй `WebSearch`/`WebFetch` напрямую. Цель — не 50 статей широко,
а 5-10 статей, которые специалист этой ниши сам бы назвал "стандартные ссылки по теме".

### Phase 4 — Атаковать методами инсайдера (read-only, без вычислений)

Перечисли 3-5 подходов, которые попробовал бы именно специалист этой ниши (не общий
список "попробуй ML, попробуй симуляцию") — ранжируй по применимости и дешевизне.
**Ничего не считай и не запускай на этом шаге** — это список рекомендаций, не действие.

### Phase 5 — Вердикт (обязательно, всегда)

```
Решено ли уже? [да/нет/частично]
Кем? [VERIFIED автор + работа, или "не найдено — открытая проблема ниши"]
Какой путь из Phase 4 подходит НАМ конкретно? [1 подход, с обоснованием]
Дешёвый следующий шаг: [конкретное действие на минуты/часы, не месяцы]
```

Честное "открыто, не решено" — валидный и ценный вердикт, не провал скилла.

### Phase 6 — Опциональное исполнение (ТОЛЬКО по явному "го"/"запусти")

Если пользователь явно просит — выполни самый дешёвый ранжированный подход из Phase 4
(численная проверка, короткий расчёт, точечный доп.поиск). Это отдельный явный шаг,
скилл НЕ переходит сюда автоматически после Phase 5 — иначе теряется read-only
гарантия ядра.

---

## Anti-patterns (никогда)

| Антипаттерн | Почему опасно |
|---|---|
| Уверенно назвать автора/работу без реального поиска | "звучит правдоподобно" ≠ "существует" — ядро риска этого скилла |
| Спутать нишу с областью ("физика" вместо конкретного под-раздела) | теряется весь смысл — это снова широкий фронт |
| Выполнить Phase 6 без явного "го" | ломает read-only гарантию ядра, пользователь не просил считать |
| Смешать с `/cross-domain` (перенос решения СНАРУЖИ) | направление обратное — здесь ищем ВНУТРИ ниши, не аналогию извне |
| Смешать с `/hypothesis-lab` (9 разных экспертов) | здесь один узкий специалист, не панель мнений |
| Пропустить Phase 5 честное "не решено" ради красивого ответа | ложный позитив хуже честного "открыто" |
| Пропустить Phase 0.5 и сразу искать специалиста | тратишь дорогой поиск на задачу, чья посылка могла быть опровергнута дешёвой локальной проверкой за минуту |

## Формат вывода

```markdown
## Niche: [точный узкий подраздел]
Niche confidence: [High/Medium/Low] — [почему не выше]

## Seminal works + key authors
- [VERIFIED] Автор, Год, "Название" — URL/DOI
  - Evidence: [DOI/arXiv/ORCID/homepage]
  - Почему эта ниша: [точное совпадение темы/метода, не косвенная связь]
  - Текущая активность: [публикация после YYYY / лаба / недавний препринт]
  - specialist_score: [число] — [1 фраза, что перевесило, если кандидатов было ≥2]
- [UNKNOWN] (если не нашёл) — ближайшее найденное вместо

## Специалист видит проблему так: [1-2 предложения рамкой ниши, её словарём]

## Targeted search results (Phase 3)
[5-10 статей, строго по нише]

## Методы инсайдера (ранжировано)
1. [метод] — применимость X, дешевизна Y
2. ...

## Вердикт
Решено: [да/нет/частично]
Кем: [VERIFIED ссылка или "не найдено"]
Подходит нам: [1 метод + почему]
Следующий дешёвый шаг: [конкретное действие]
```

## Связанные скилы

- `/academic-research` — если после Phase 1 выяснилось, что нужна ширина, а не глубина
- `/skeptic` — если вердикт Phase 5 слишком уверен, атаковать его до принятия
- `/cross-domain` — обратное направление: перенос механизма ИЗ другой области
- `/hypothesis-arbiter` — если вопрос "почему", а не "кто уже это решал"

---

**Version:** 1.2.0
**Status:** experimental, частично dogfooded (честно, не `[STATUS: confirmed]`) — протокол
Phase 0-5 прогнан вручную один раз на реальной проблеме этого репозитория (расхождение
pytest collection count Windows vs CI), НЕ через автоматический вызов `Skill` tool (скилл
не попал в снапшот доступных скиллов на старте той сессии). Реальная находка того прогона:
первая гипотеза (версионный дрейф pytest) была опровергнута дешёвым локальным экспериментом
ДО того, как дошло до поиска специалиста — что и породило Phase 0.5 в v1.2.0. Полный
end-to-end прогон через `Skill("boyko-specialist", ...)` ещё не выполнялся.
**Created:** 2026-07-09, по паттерну "extract the skill from the win" — рождён из
ручного сужения проблемы в этой же сессии (dipolar TM → Blanchet, J₃(𝕆)-массы → Singh),
не из абстрактного дизайна.

**Runtime Loading Note:** если скилл установлен, пока сессия Claude Code уже идёт, он
может не появиться через `Skill` tool до перезапуска. Список доступных скиллов фиксируется
снапшотом на старте сессии; свежескопированный скилл может физически лежать в
`~/.claude/skills/` и в репозитории, но всё равно вернёт `Unknown skill` внутри текущей
сессии. Это не значит, что файл скилла невалиден. Чтобы проверить реальный вызов —
начните новую сессию Claude Code после установки и вызовите `/boyko-specialist <проблема>`.
Не создавайте постоянные дубли в project-scoped `.claude/skills/` только чтобы форсировать
обнаружение — временная копия допустима исключительно для отладки и должна быть удалена
сразу после.
**Changelog v1.2.0:** добавлена Phase 0.5 (Premise Falsification Check) — если дешёвая
локальная проверка инварианта (версия/OS/конфиг/env/plugin list) опровергает посылку
задачи или напрашивающуюся гипотезу ДО поиска специалиста — остановиться и доложить это
первым, не тратить дорогой поиск на неточно сформулированную/уже опровергнутую задачу.
Различает falsified premise (заявленный факт ложен) и falsified hypothesis (факт верен,
но прямой дешёвый эксперимент уже опроверг причину). Источник: реальный dogfood-прогон
этой версии, не абстрактный дизайн — см. Status выше.
**Changelog v1.1.0:** снят overclaim "лучший в мире" → "наиболее релевантные verified"
(недоказуемый superlative заменён на проверяемое утверждение); добавлена ranking formula
`specialist_score` для случая ≥2 verified-кандидатов; добавлено обязательное поле
`Niche confidence: High/Medium/Low`; добавлены evidence-подполя на каждого автора
(DOI/почему-ниша/активность/score). Frontmatter-парсинг перепроверен `yaml.safe_load` —
парсится штатно, внешний аудит здесь ошибся (принял свёрнутый `description: >` в raw-вьюере
GitHub за одну строку).