Boyko Project Radar

---
name: boyko-project-radar
description: >
  Спрашивает ОДИН явный вопрос — Задача или Весь проект — прежде чем что-либо
  делать, затем реально прогоняет существующие сканеры проекта (не гадает по
  дешёвым сигналам git status) и синтезирует находки в 4 обязательные категории:
  узкие места, сильные места, нерешённые места, слепые места. Заканчивается
  рекомендацией цепочки скиллов под именно эти находки — в формате /suggest, но
  на данных реально запущенных сканеров, а не на паттерне ситуации.
  Не дублирует сканеры — оркестрирует: atomize (bottlenecks), deletion-test
  (архитектурное здоровье, если есть в каталоге), research-audit (gaps, если проект
  исследовательский), sci-code-audit (доверие к коду, если есть в каталоге). Для
  задачи (TASK-режим) — целиком делегирует boyko-agent, не реализует заново.
  [STATUS: described] [CONFIDENCE раздельно по режимам — не смешивать: PROJECT-режим
  n=1 сессия (2026-08-26) — реальный прогон на этом же проекте нашёл живой баг
  (detection_expected drift) и 6 незарегистрированных хуков, но сам вердикт
  "МОЙ ВЫБОР" опирался на непроверенную находку суб-сканера, не перепроверенную
  на HEAD (см. HARD RULE 5) — внешняя оценка 6/10, рубрика оценки не проверена,
  указана как есть. TASK-режим — n=0, ни разу не запускался, чистый design.]
  Triggers: /boyko-project-radar, "какую цепочку скиллов запустить", "узкие места",
  "сильные места", "слепые места", "нерешённые места", "проанализируй весь проект",
  "что лучше всего запустить", "полный аудит проекта", "project health check",
  "blind spots", "какой скилл дальше".
  НЕ для: дешёвой рекомендации без реального скана (→ /suggest — read-only сигналы,
  60 сек), брифинга "где я оставил" (→ /orient), разбора ОДНОЙ гипотезы/эксперимента
  (→ /research-audit само по себе, /skeptic), проактивного ведения задачи с нуля
  (→ boyko-agent — этот скилл делегирует ему TASK-режим целиком, не заменяет).
effort: high
tokens: ~1800
triggers: [/boyko-project-radar, "какую цепочку скиллов запустить", "узкие места", "сильные места", "слепые места", "нерешённые места", "проанализируй весь проект", "что лучше всего запустить", "полный аудит проекта", "project health check", "blind spots", "какой скилл дальше"]
---

<!-- BSV — Brief Skill View | поиск: BSV
Скил   : boyko-project-radar
TL;DR  : Спрашивает Task/Project → реально сканирует → 4 категории находок → рекомендует цепочку
Вызов  : /boyko-project-radar, "узкие/сильные/слепые/нерешённые места", "какую цепочку запустить"
НЕ для : Дешёвых рекомендаций без скана (→ /suggest), брифинга (→ /orient), ведения задачи (→ boyko-agent)
Выход  : 4 категории находок (обязательно все 4, даже если пусто) + 2-3 рекомендованные цепочки
-->

# boyko-project-radar — сканер здоровья проекта → рекомендация цепочки скиллов

## Зачем

`/suggest` даёт быструю рекомендацию за 60 секунд по дешёвым сигналам (git status,
activeContext, CLAUDE.md) — это осознанный компромисс скорости против глубины, и он
остаётся правильным выбором, когда нужен именно быстрый ответ. Этот скилл — для
другого случая: когда пользователь хочет **реальный** ответ на "что у нас плохо, что
хорошо, что зависло, чего мы не видим" — а не догадку по логам git. Разница не в
формате вывода (он намеренно тот же, что у `/suggest`), а в том, что стоит за ним:
здесь фактически прогоняются существующие сканеры проекта, а не читаются их следы.

**Уникальное покрытие** (чего нет ни в одном другом скилле):
- Явный Scope Gate — вопрос "Задача или Весь проект" ЗАДАЁТСЯ, а не угадывается
- Синтез разнородных сканеров (atomize/deletion-test/research-audit/sci-code-audit)
  в ОДНУ структуру из 4 обязательных категорий
- Рекомендация цепочки, построенная на реальных находках, а не на паттерне ситуации

---

## HARD RULES (non-negotiable)

1. **Scope Gate — всегда первый шаг, без исключений.** Если вызов не содержит явного
   указания scope (`/boyko-project-radar задача` / `/boyko-project-radar проект` / аргумент во
   free-form промпте типа "на всём проекте"), задать РОВНО один вопрос
   (AskUserQuestion или текстом, если инструмент недоступен) с двумя вариантами:
   - **Задача** — то, чем сейчас занят пользователь. Быстрее, уже сегодня.
   - **Весь проект** — полный скан. Дольше, даёт полную картину.
   Не продолжать без ответа. Это единственное намеренное отличие от `/suggest`
   ("НЕ спрашивай, читай контекст сам") — здесь вопрос дешёвый, а цена ошибки
   (просканировать не то) высокая.
   Если ответ не сводится однозначно ни к одному из двух вариантов (например
   "оба", "не знаю", встречный вопрос, смена темы) — переспросить с уточнением
   ЕЩЁ РАЗ, не гадать и не выбирать вариант по умолчанию.

2. **Все 4 категории обязательны в выводе, даже если пустые.** Если сканер недоступен
   в текущем каталоге или не нашёл ничего для категории — написать явно
   "нет данных (сканер X недоступен)" или "не найдено", а не пропустить категорию
   молча. Пустая категория — тоже сигнал (значит, либо всё чисто, либо мы не смотрели).

3. **Не дублировать сканеры.** Если `atomize` уже посчитал bottleneck — взять его
   результат для категории "узкие места", не считать заново другим методом.
   Если два сканера легитимно кормят одну категорию (например `atomize` и
   `deletion-test` оба дают находки в "узкие места") — перечислить находки ОБОИХ
   с указанием источника, не выбирать один сканер произвольно. Если находки
   прямо противоречат друг другу (один считает модуль здоровым, другой —
   God-node) — написать оба вердикта explicitly и пометить как "противоречие
   сканеров", не разрешать конфликт молча в пользу одного из них.

4. **Не выполнять задачи.** Как и `/suggest`, этот скилл только анализирует и
   рекомендует. Запуск рекомендованной цепочки — отдельное действие пользователя
   или следующий шаг оркестратора, не часть этого скилла.

5. **Перепроверить свежесть находки перед тем, как поставить её в "МОЙ ВЫБОР".**
   (Найдено на первом реальном dogfood-прогоне, 2026-08-26, оценка 6/10: bottleneck
   #1 в выдаче опирался на находку `atomize` "5 патчей за ~15 коммитов на один
   класс бага" — исторически верный факт, но не проверенный на текущий HEAD. Все
   эти коммиты оказались уже смёржены; проблема была фактически закрыта до
   прогона. Ошибка обнаружилась только на шаге "иду чинить".) Суб-сканер может
   дать [INFERRED]-вывод по паттерну истории ("часто чинили → вероятно ещё
   хрупко") и это законная находка для категорий Шага 3 — но её нельзя молча
   повышать до [VERIFIED]-статуса при выборе главной рекомендации. Перед тем как
   назвать находку суб-сканера причиной "МОЙ ВЫБОР", явно проверить (Read/Grep/
   git log --all -- <файл> на предмет уже смёржённых фиксов той же проблемы,
   или прямой тест на репродукцию), что цитируемая проблема действительно жива
   на текущем HEAD, а не только существовала в истории коммитов. Если проверить
   нельзя быстро (сканер тяжёлый, времени нет) — пометить рекомендацию явно как
   "[INFERRED из истории, не перепроверено на HEAD]", не как факт.

---

## Шаг 0 — Scope Gate

См. HARD RULE 1. После ответа — перейти в соответствующий режим ниже.

---

## Режим TASK

Не реализовывать заново — этот режим **целиком делегирует** в `boyko-agent`
(проактивный discovery-ассистент, уже покрывает ровно этот случай: "калибрует
неопределённость, подбирает адекватно различающий тест, находит смежные
возможности"). Вызвать `Agent(boyko-agent, ...)` с текущей задачей как целью и
вернуть его результат пользователю без изменений. Если пользователь явно попросил
именно 4-категорийный формат даже для задачи — можно постфактум переразметить
результат boyko-agent в 4 категории (узкое/сильное/нерешённое/слепое место
применительно к этой конкретной задаче), но не пересчитывать его логику заново.

---

## Режим PROJECT

### Шаг 1 — Определить доступные сканеры

Проверить (Glob/Read), какие из перечисленных ниже реально есть в текущем каталоге
скиллов — набор личный, не все установлены везде:

| Сканер | Что даёт | Категория-получатель |
|---|---|---|
| `atomize` | 7±2 атома, interface map, top-3 bottleneck | Узкие места |
| `deletion-test` | Виртуальное удаление модулей → DEAD/DUPLICATE/GOD/HEALTHY/CRITICAL | Сильные места (HEALTHY/CRITICAL) + узкие (GOD-nodes) |
| `sci-code-audit` | 10-layer аудит доверия к коду (если проект research/production) | Слепые места (что не проверено) |
| `research-audit` | Полный мета-аудит (null_results/parked/experiments), только если есть research-артефакты | Нерешённые места (gaps, zombie-гипотезы) |
| `skill-audit` | Здоровье набора скиллов (не кода проекта) | Слепые места (какие инструменты не используются) — опционально, если вопрос касается самого тулинга |

Отсутствующий сканер — не ошибка. Отметить в выводе "сканер X недоступен в этом
каталоге" и не пытаться заменить его импровизацией такого же уровня строгости.

### Шаг 2 — Прогнать доступные сканеры

Реально вызвать каждый доступный сканер (Skill tool), не пересказывать их описания.
Можно параллельно, если независимы (atomize и sci-code-audit не пересекаются).
Если сканер тяжёлый (research-audit, sci-code-audit) и пользователь просил "быстро" —
предупредить о времени явно перед запуском, не запускать молча в фоне неограниченно.

### Шаг 3 — Синтез в 4 категории

Обязательный формат вывода (порядок фиксирован):

```markdown
## boyko-project-radar — [название проекта]

**Scope:** Весь проект | **Сканеры:** [список реально запущенных] | **Пропущено:** [недоступные, если есть]

### 🔴 Узкие места (bottlenecks)
[из atomize/deletion-test, конкретно, с файлом/модулем]

### 🟢 Сильные места
[из deletion-test HEALTHY/CRITICAL, или из dogfooded-скиллов если вопрос про тулинг]

### 🟡 Нерешённые места
[из research-audit gaps, открытых PR, zombie-гипотез — если применимо к проекту]

### ⚫ Слепые места
[то, что НИ ОДИН сканер не покрывает — назвать явно, это не "нет находок", а "мы не смотрели"]
```

### Шаг 4 — Рекомендация цепочки (реюз формата `/suggest`)

Взять ровно тот же визуальный формат вывода, что в `suggest/SKILL.md` Шаг 4
("🔗 N. [НАЗВАНИЕ] → Цепочка → Результат → Когда" + "▶ МОЙ ВЫБОР") — не изобретать
новый UX для одной и той же задачи "порекомендовать цепочку". Единственное отличие:
цепочки здесь строятся под конкретные находки Шага 3 (например, если "узкие места"
указали на конкретный God-node — цепочка начинается с `architect` или `deletion-test`
повторно после фикса, а не с общего шаблона по ситуации).

Максимум 3 цепочки, всегда явный "Мой выбор" — как в `/suggest`.

---

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

- `/suggest` — быстрая альтернатива без реального скана (60 сек, дешёвые сигналы)
- `/atomize` — источник данных для "узкие места" в PROJECT-режиме
- `/research-audit` — источник данных для "нерешённые места", только research-проекты
- `deletion-test` — источник данных для "сильные/узкие места" (если есть в каталоге)
- `sci-code-audit` — источник данных для "слепые места" (если есть в каталоге)
- `boyko-agent` — TASK-режим делегирует туда целиком