Полный цикл сквозного анализа сложных систем с ≥3 взаимодействующими компонентами: Атомизация → Линзы → Связи с evidence-метками → Сборка → Фальсификация. Оркестрирует /multi-lens (линзы), /skeptic + falsification-ladder (проверка), /estimand-ops (научные claims). Использует confidence-labeled dependency map с [VERIFIED]/[INFERRED]/[WEAK]/[РАЗОРВАНА] на каждой связи. Применяй для: архитектурных решений, научных гипотез, production-багов, регуляторных workflows, антифрода, любого объекта где b...
Scanned 9/2/2026
Install to Claude Code
npx -y skills add sergeeey/Claude-cod-top-2026 --skill boyko-method --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Boyko Method?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sergeeey-boyko-method)More formats (shields.io, HTML) on the badges page.
---
name: boyko-method
description: "Полный цикл сквозного анализа сложных систем с ≥3 взаимодействующими компонентами: Атомизация → Линзы → Связи с evidence-метками → Сборка → Фальсификация. Оркестрирует /multi-lens (линзы), /skeptic + falsification-ladder (проверка), /estimand-ops (научные claims). Использует confidence-labeled dependency map с [VERIFIED]/[INFERRED]/[WEAK]/[РАЗОРВАНА] на каждой связи. Применяй для: архитектурных решений, научных гипотез, production-багов, регуляторных workflows, антифрода, любого объекта где broken links — главная находка. Триггеры: '/boyko', 'метод бойко', 'полный разбор', 'разложи и собери', 'системный анализ от и до', 'построй модель проблемы', 'атомизируй и проверь', 'evidence-labeled analysis'. НЕ для: простого вопроса с одним ответом, быстрого фикса, поиска факта."
allowed-tools: Read, Grep, Glob, Bash(git log:*), WebSearch
context: fork
version: "1.3.0"
---
# Метод Бойко — сквозной цикл «проблема → проверяемая модель»
Сложную систему нельзя надёжно понять с одной точки зрения и одним махом. Метод проводит объект через 5 этапов, превращая мутное в проверяемое. **Это оркестратор:** этапы Линзы и Проверка делегируются готовым скиллам — не дублируй их.
```
Объект → Атомизация → Линзы → Связи → Сборка → Гипотезы → Проверка → Уточнение
```
## Режимы запуска
| Режим | Команда | Время | Что даёт |
|---|---|---|---|
| **Quick** | `/boyko quick: <объект>` | ~10 мин | Только Атомизация + Связи + 3 ключевые гипотезы |
| **Standard** | `/boyko <объект>` | ~30 мин | Полный 5-этапный цикл |
| **Deep** | `/boyko deep: <объект>` | ~60 мин | Full + multi-lens по каждому атому + skeptic на все гипотезы |
**Output caps — жёсткие лимиты по режиму:**
| Режим | Макс. атомов | Макс. связей | Макс. гипотез |
|---|---|---|---|
| Quick | 8 | 20 | 3 |
| Standard | 20 | 60 | 7 |
| Deep | 40 | 120 | 12 |
Превышаешь лимит → агрегируй атомы в группы, не добавляй новые. Цель: модель, а не энциклопедия.
---
## Feasibility Gate (запустить ПЕРВЫМ — до старта любого режима)
Три вопроса. Если хоть один — «нет» → бери точечный скилл, не запускай полный цикл.
```
1. Объект сложный? (≥3 взаимодействующих компонента / нелинейные зависимости)
→ НЕТ: один вопрос → используй /multi-lens (только линзы) или /skeptic (только фальсификация)
2. Цена ошибки высока? (архитектурное решение / научный claim / production баг)
→ НЕТ: быстрый фикс → без метода вообще
3. Есть конкретный объект? (не "расскажи о теме X", а конкретная система/гипотеза/проблема)
→ НЕТ: уточни границы объекта, только потом запускай
```
**Quick-режим** — минимальный порог: объект сложный + цена ошибки средняя. Для высокой — Standard или Deep.
---
## Этап 1 — Атомизация (разложить на минимальные единицы)
Раздроби объект на «атомы анализа»: объект · функция · переменная · процесс · состояние · переход · связь · причина · следствие · ограничение · риск · ошибка · ресурс · сигнал · решение · допущение.
**Правило глубины:** дроби, пока атом не станет проверяемым/изменяемым по отдельности. Глубже — лишнее.
```markdown
| Атом | Тип | Описание | Почему важен |
```
---
## Этап 2 — Линзы (рассмотреть каждый атом с разных сторон)
**→ Делегируй скиллу `multi-lens`.** Прогони ключевые атомы через релевантные из 20 линз (логическая, причинная, системная, риск, антихрупкая…). Не переписывай каталог линз здесь — вызови `/multi-lens`.
В **Quick-режиме**: пропусти этот этап или возьми 2-3 линзы вручную без делегирования.
Выход линз: `Атом → Линза → Вопрос → Наблюдение → Гипотеза`.
---
## Этап 3 — Связи (построить карту зависимостей)
Найди связи между атомами. **Дисциплина доказательности (обязательно):** каждая связь несёт тег уровня уверенности И колонку «Как проверить». Связь без доказательства — это `[предположение]`, не факт.
**Строгие критерии — ставь метку только если выполнен критерий:**
| Метка | Критерий (требуется ДО постановки) |
|---|---|
| `[VERIFIED]` | Воспроизводимый тест, лог, документ, расчёт или цитата — **источник указан явно** (`file:line` или URL) |
| `[INFERRED]` | Логически выведена из ≥2 верифицированных фактов — **цепочка написана явно** |
| `[WEAK]` | Правдоподобно, но ≤1 источник или механизм неполный — **не использовать в решениях** |
| `[РАЗОРВАНА]` | Связь **заявлена** в тексте/архитектуре/документе, но доказательства нет — механизм отсутствует или не проверялся |
`[РАЗОРВАНА]` ≠ плохо. Это часто важнейшая находка: система притворяется связной, а на деле — нет.
**Fallback если `/multi-lens` недоступен:** пропусти Этап 2 или возьми 3 линзы вручную (логическая, причинная, риск) без делегирования.
```markdown
| Элемент A | Тип связи | Элемент B | Механизм | Уверенность | Как проверить |
```
**Заполненный пример (architecture review):**
| Элемент A | Тип связи | Элемент B | Механизм | Уверенность | Как проверить |
|---|---|---|---|---|---|
| hook_latency | причинная | user_perceived_lag | PostToolUse хук блокирует ответ Claude | [VERIFIED] | `time curl` до/после хука |
| plugin.json trigger | функциональная | skill_visibility | SessionStart парсит trigger поле | [INFERRED] | сравнить plugin.json видимых vs невидимых скиллов |
| null_results/INDEX.md | информационная | experiment_decisions | UserPromptSubmit читает INDEX перед стартом | [WEAK] | grep hook_trigger.jsonl на null_retroscan |
| FRAP_parameters | причинная | TAD_boundary_model | loop_extrusion_rate fitted to FRAP | **[РАЗОРВАНА]** | FRAP-данных нет в репо — связь заявлена, не верифицирована |
**Ищи особо:**
- **Петли обратной связи** — A усиливает B, B усиливает A
- **Ключевые узлы** — атом с ≥4 исходящими связями → точка отказа
- **РАЗОРВАННЫЕ связи** — заявлена, но доказательства нет → часто важнейшая находка
Типы связей: причинная · функциональная · временна́я · логическая · информационная · ресурсная · обратная связь · скрытая зависимость.
---
## Этап 4 — Сборка (собрать модель целого)
Из атомов → механизмы → модули → процесс → модель системы. Не просто список — **связная модель** с входами/выходами, точками управления и точками отказа.
```markdown
| Атомы | Механизм | Модуль | Роль в системе | Точка отказа |
```
**Анти-цель — ложная целостность.** Обязательно: явно перечисли **≥1 `<неизвестную зону>`**. Если их ноль — это red flag: модель слишком гладкая, ты что-то замазал.
Сильнейший выход этого этапа — **переопределение объекта** (напр. «это фильтр приоритизации, а НЕ предсказатель» — меняет всю интерпретацию).
---
## Этап 5 — Проверка (фальсифицировать модель)
**→ Делегируй `skeptic` + `falsification-ladder` (+ `estimand-ops` для research).** Не изобретай проверку — построй гипотезы и отдай их на разлом.
Каждая гипотеза в форме:
```
Если [причина/условие], то [следствие], потому что [механизм].
Проверка: [метод]. Подтверждается если [критерий]. Опровергается если [критерий].
```
**Если гипотез ≥2 одновременно живых** (не одна уточняемая версия, а реально конкурирующие) — используй `experiments/_template/ach_matrix.md` (Analysis of Competing Hypotheses): гипотезы × evidence, приоритет тестам, которые различают гипотезы, а не подтверждают все сразу. Опционально, только при ≥2 живых.
**Degeneracy-чек (обязателен при большом эффекте):** если видишь подозрительно сильный результат (Cohen d>2, F1>0.95, R²>0.99) — первый вопрос не «как хорошо!», а **«что вырождается?»**. Часто эффект завышен схлопыванием одного распределения в точку. Это требует оговорки — иначе рецензент/реальность поймают первыми.
Затем `/skeptic` на сильнейшие гипотезы (context asymmetry). Для научных — FL Full + estimand.
---
## Выход (обязательный формат)
```markdown
## 1. Объект и цель / границы
## 2. Атомы (таблица)
## 3. Линзы (из multi-lens, или краткие в quick-режиме)
## 4. Карта связей (таблица с уровнями уверенности)
## 5. Модель целого (+ ≥1 неизвестная зона)
## 6. Проверяемые гипотезы (с критерием опровержения)
## 7. План проверки (skeptic / FL / эксперимент)
## 8. Что результат НЕ будет значить
```
---
## Дисциплина честности (из integrity.md)
Разделяй: **факт** (проверяемое наблюдение) · **гипотеза** (с критерием опровержения) · **допущение** (явно помечено) · **неизвестная зона**. Не выдавай сборку за доказанную модель — она верна лишь до проверки на этапе 5.
---
## Чем НЕ является
Не замена `skeptic`/FL/estimand — он их **вызывает** на нужных этапах. Не для простых задач. Не «новая наука» — это операционная сборка системного мышления + декомпозиции + причинного моделирования + фальсификации в один воспроизводимый маршрут.
---
## Связанные скиллы (оркестрация)
| Этап | Скилл |
|---|---|
| Линзы | `multi-lens` |
| Проверка | `skeptic`, `falsification-ladder` (rule), `estimand-ops` (rule) |
| Конкурирующие гипотезы | `hypothesis-arbiter` |
| Доказательная база | `consilience` |
---
*Version: 1.3.0 — добавлены: context: fork в frontmatter, output caps по режимам, строгие evidence criteria для каждой метки (VERIFIED/INFERRED/WEAK/РАЗОРВАНА), fallback при недоступности /multi-lens, улучшен description для автороутинга*
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!