Explanation: ПАТТЕРН 2 (discovery-interview): запрос содержит минимум три несовместимые интерпретации — 'роутер' может быть классификатором задач, Laravel Router или Vue Router; 'провал 1/2' — неопределённые идентификаторы без system/expected/actual. Угадывать запрещено. Требуется уточнение: (A) что такое провал 1 и провал 2 конкретно, (B) к какому роутеру относится запрос.

Superpowers v5.1.0 — systematic-debugging

Если 'провалы' — это баги роутера классификатора, нужен систематический разбор. Но без описания system/expected/actual (ПАТТЕРН 4) нельзя запустить debugging-flow. Отклонён: недостаточно контекста.

adr-kit

Если цель — зафиксировать архитектурное решение ('фиксируй решения') о поведении роутера, adr-kit подходит. Но 'как заставить роутер не дать допустить провала' звучит как проектирование/реализация, а не только документирование. Отклонён: ambiguous.

discovery-interview

Запрос явно многозначен — три+ интерпретации 'роутера' и 'провалов'. Discovery-interview мог бы прояснить намерение через JTBD-вопросы. Отклонён в пользу no_skill_found: классификатор обязан запросить уточнение напрямую, а не запускать discovery-интервью на мета-вопрос о самом классификаторе.

Summary: Роутер не определил узел, выбран direct по умолчанию для продолжения диалога о системе роутинга

Запрос содержит контекст о предыдущих решениях и 'провалах 1 и 2' — без истории сессии невозможно корректно роутить. Нужен узел с памятью контекста или clarification-узел для уточнения деталей

Когда запрос ссылается на предыдущий контекст ('эти решения', 'провал 1 и 2') без явной истории, роутер должен активировать узел восстановления контекста или запросить уточнение, а не падать в direct по умолчанию


Explanation: Запрос не содержит конкретной задачи — это открытый вопрос об архитектуре роутера ('подумай как считаешь?'). Ни один скил не предназначен для мета-обсуждения дизайна самого классификатора. Требуется уточнение: A) это RFC → нужно оформить как предложение и зафиксировать через #33, B) это вопрос к системе → ответить в разговорном режиме без скила, C) это решение принято → #84 для нормативного синка.

claude-md-management

Подошёл бы если бы запрос был явным предложением зафиксировать новое правило роутера в CLAUDE.md, но сейчас это размышление/вопрос 'как считаешь?' — решение ещё не принято

normative-sync

Синк нормативки нужен ПОСЛЕ принятия решения об изменении, не во время обсуждения самого дизайна

Superpowers v5.1.0 / writing-plans

Запрос — не задача реализации фичи, а мета-дискуссия о том, когда вообще должен срабатывать writing-plans; применить его сюда было бы рекурсивно абсурдным

Summary: Роутер не определил узел, система упала на direct для обсуждения архитектуры плановой системы роутинга

Запрос философско-архитектурный — обсуждение дизайна самой системы. Мог подойти узел 'discuss' или 'meta' если бы существовал. Direct приемлем, но роутер должен был определить узел явно, а не оставить 'не определён'

Запросы о дизайне и архитектуре самой роутинговой системы — отдельный класс мета-запросов. Стоит иметь выделенный узел для обсуждения устройства системы, чтобы роутер не падал в неопределённость


Explanation: Запрос содержит неопределённую отсылку ('провал 1 и 2') без указания документа, системы или предыдущего контекста. Классификатор не получает историю conversation (она обрабатывается до него), поэтому невозможно восстановить референс. ПАТТЕРН 2 (discovery-interview) требует вернуть no_skill_found при двух и более возможных интерпретациях — здесь их минимум три.

claude-md-management

Подходит только если 'провал 1 и 2' — это паттерны из CLAUDE.md и нужно их расширить. Без подтверждения контекста — угадывание.

Superpowers v5.1.0 (writing-plans)

Мог бы написать детальный документ с примерами, но непонятно ЧТО писать — тема не определена.

skill-creator

Только если 'провалы' — это дефекты существующего скила и нужно переписать SKILL.md. Нет оснований для такого вывода.

Summary: Роутер не определил узел, запрос направлен в direct без обработки специализированным агентом

Необходимо было определить контекст предыдущего диалога — запрос явно является продолжением беседы о каких-то 'провалах 1 и 2'. Без контекста невозможно корректно выбрать узел. Следовало запросить уточнение или использовать узел для работы с историей диалога

Запросы-продолжения без явного контекста ('провал 1 и 2') требуют анализа истории сессии перед роутингом. Если контекст недоступен — лучше запросить уточнение, чем слепо направлять в direct


Explanation: Запрос является meta-обсуждением архитектуры какой-то системы с роутером и судьёй, но не содержит достаточно контекста для однозначной классификации. Отсутствуют: чёткое указание на систему (код CRM vs LLM-пайплайн vs классификатор), ожидаемое действие (реализация / документация / диаграмма), и definition of done. ПАТТЕРН 2 (discovery-interview) обязывает вернуть no_skill_found при двух+ интерпретациях.

adr-kit

Подошёл бы если речь об архитектурном решении (ADR) для router/judge паттерна, но контекст слишком размыт — неясно, о каком компоненте и каком решении идёт речь

architecture-patterns

Мог бы помочь если запрос про архитектурный паттерн router→judge, но непонятно к чему применяется паттерн — к коду CRM, к LLM-системе, или к самому классификатору

discovery-interview

Наиболее близкий кандидат — структурированное интервью помогло бы прояснить намерение, но сам запрос носит характер свободного обсуждения ('давай обсудим'), а не запроса на выполнение задачи — правильнее вернуть no_skill_found с просьбой уточнить

Summary: Роутер не определил узел, выбран direct для обсуждения архитектурного вопроса о синхронизации слоёв

Вопрос об архитектуре системы (синхронизация слоя плана разговора между роутером и судьёй) мог бы быть направлен в специализированный узел для обсуждения дизайна/архитектуры, если такой существует

Вопросы о согласованности компонентов системы (роутер/судья) требуют чёткой классификации — это архитектурное обсуждение, а не прямой ответ; роутер должен уметь распознавать такие паттерны


Explanation: ПАТТЕРН 2 (discovery-interview): запрос — философская метафора с минимум тремя непересекающимися интерпретациями (прозрачность классификатора / обновление нормативки / архитектурный enforcement). Угадывать интерпретацию недопустимо. Требуется уточнение по двум осям: (1) кто субъект незнания — пользователь, агент, роутер; (2) что означает 'обходить законы' в техническом смысле — jailbreak промпта или обход хуков/enforcement.

claude-md-management

Подходит если цель — дописать правила в CLAUDE.md чтобы агент их знал при планировании. Но запрос не содержит явного 'обнови CLAUDE.md', и неясно какие именно правила имеются в виду.

normative-sync

Подходит если цель — синхронизировать нормативные документы (PSR_v1/Pravila/Tooling/CLAUDE.md) после выявленного gap. Но сам gap не сформулирован конкретно — неизвестно какой документ отстал.

adr-kit

Подходит если 'законы' = Architecture Decision Records и проблема в том что агент их не читает перед планированием. Но метафора слишком широкая чтобы делать такой вывод без уточнения.

Summary: Роутер не смог определить узел для философского вопроса об асимметрии знания законов/правил системы

Вопрос содержит метафору о системных правилах роутинга — нужен узел для рефлексии/мета-диалога. Direct без цепочки обработки теряет глубину ответа на философско-системный вопрос

Метафорические вопросы о самой системе (роутер, правила, знание законов) требуют специального узла мета-анализа или философской рефлексии, а не просто прямого ответа


Explanation: ПАТТЕРН 2 (discovery-interview): запрос содержит минимум три неразрешённые неоднозначности одновременно — (1) что такое 'судья' и где он живёт в кодовой базе/конфигах Лидерры, (2) что такое 'провалы 1 и 2' (тест-кейсы? eval-сценарии? этапы writing-plans?), (3) что такое 'роутер' (классификатор задач? отдельный агент? хук?). Угадывать интерпретацию при таком количестве неизвестных — нарушение ПАТТЕРНА 2. Требуется уточнение перед маршрутизацией.

Superpowers v5.1.0

Superpowers содержит judge-паттерн и writing-plans, но запрос явно описывает изменение самого процесса судьи (добавление цикла возврата), а не использование существующего скила. Без понимания к какому артефакту это относится — применить нельзя.

hookify

Цикл судья→агент→роутер теоретически можно реализовать через хуки PostToolUse, но запрос не содержит явного /hookify и описывает скорее workflow/процесс, а не конкретный хук-файл. Активировать hookify без явного запроса нельзя по правилам скила.

discovery-interview

Наиболее близкий кандидат — запрос требует структурированного discovery-интервью чтобы понять что такое 'судья', 'роутер', 'провалы 1 и 2' в текущем мета-процессе. Однако пользователь просит оценить идею, а не проходить интервью — поэтому тоже не точное попадание. Тем не менее это лучший первый шаг после уточнения.

Summary: Роутер не смог определить узел для мета-запроса об изменении архитектуры роутинговой системы, выбран direct

Запрос касается реструктуризации самой роутинговой схемы — нужен специальный мета-узел или узел архитектурного проектирования. Direct без цепочки не позволяет полноценно оценить и реализовать предложенную схему эскалации

Мета-запросы об изменении самой системы роутинга требуют отдельного обработчика или флага — нельзя роутить их как обычные задачи, иначе теряется контекст и качество ответа


Summary: Запрос на оценку архитектурной идеи о расширении сбора потребностей через множество скилов — направлен в direct вместо #19

Узел #19 был рекомендован роутером для концептуальных обсуждений архитектуры системы скилов. Direct-ответ мог быть оправдан только если #19 недоступен или не подходит по контексту. Стоило проверить, что именно делает #19 и почему он был рекомендован.

Когда роутер рекомендует конкретный узел для концептуально-архитектурных вопросов, а выбирается direct с пустой цепочкой — это сигнал о возможном обходе логики. Нужно логировать причину отклонения от рекомендации роутера.


Summary: Роутер не определил узел, запрос направлен напрямую без цепочки обработки

Запрос требовал анализа контекста предыдущей сессии о декомпозиции — нужен узел для работы с архитектурными улучшениями или code-review, а не direct

Запросы с 'как ещё улучшить X' без контекста должны триггерить узел уточнения контекста или analysis, а не fallback на direct


Summary: Роутер не определил узел, выбран direct для ответа на вопрос о чужих скилах

Роутер должен был определить узел — вероятно, это вопрос об игровой механике или правилах, требующий узла с контекстом предыдущего разговора

Запросы с 'еще раз поясни' указывают на продолжение диалога — роутер должен учитывать контекст сессии и направлять к узлу, который обрабатывал исходный вопрос


**Написать тонкую этикетку-адаптер рядом** — отдельный наш файлик, который объявляет {needs/produces/constraints} **для того чужого скила, которым реально пользуемся** (читаем его доку, переписываем нужды к себе). Возвращает точную сверку для этого скила. **Но:** это ручная работа, может **устареть**, если чужой скил поменяется, и **граничит с проектным хардкодом** — поэтому только для немногих скилов, на которые реально опираемся.

**Оставить на догадке судьи** — бесплатно, портативно, но мягко. Базовый вариант.

**«Завендорить» скил** — скопировать к себе, сделать своим (полный контроль + этикетка). Но тогда полное сопровождение: обновлять руками при апгрейдах (как с вендоренными `mermaid`/`ccpm` у нас).

Summary: Роутер не определил узел, выбран direct — запрос про написание тонкого адаптера-этикетки

Роутер должен был распознать задачу написания кода (adapter/wrapper) и направить к узлу для кодирования. Контекст указывает на техническую задачу.

Запросы с техническими терминами ('адаптер', 'этикетка-обёртка') без явного слова 'код' должны маршрутизироваться к coding-узлу, а не падать в direct.


Explanation: ПАТТЕРН 2 (discovery-interview): запрос содержит минимум три независимые неопределённости — объект фиксации, контекст '26 пунктов нововведений' и тип анализируемых хуков. Угадывание любой из осей приведёт к неверному выбору скила. Требуется уточнение перед маршрутизацией.

hookify

Подходит если речь о генерации/анализе Claude Code хуков, но запрос не содержит явного '/hookify' и неясно какие именно нововведения затрагивают хуки

claude-md-management

Подходит для части 'фиксируй' если нужно захватить learnings в CLAUDE.md, но объект фиксации не определён

normative-sync

Подходит для синхронизации нормативных документов после нововведений, но триггер cls:normative_sync_needed не подтверждён явно, контекст '26 пунктов' неизвестен

Summary: Запрос на анализ изменений в хуках по 26 пунктам направлен в direct без специализированного узла

Запрос требует глубокого технического анализа кода и изменений в хуках — стоило выбрать узел с возможностью работы с кодом и структурированного анализа, а не direct

Запросы с явным контекстом разработки ('хуки', 'нововведения', 'по пунктно') и числовым объёмом задачи (26 пунктов) требуют специализированного узла для анализа кода, а не прямого ответа


Summary: Короткий неинформативный запрос 'да фиксируй' не был распознан роутером, выбран direct-узел

Роутер должен запросить уточнение: что именно фиксировать и в каком контексте, прежде чем выбирать узел

Односложные подтверждающие фразы без контекста требуют уточнения или анализа предыдущего диалога для корректного роутинга


Explanation: Запрос является чистой рефлексией о когнитивных ограничениях заказчика при работе с LLM и о ценности структурированной декомпозиции. Ни один узел реестра не предназначен для оценки мета-процесса. Conversation-слой должен ответить напрямую: да, блок discovery-interview (#55) + writing-plans (#19) закрывает именно эту проблему — переводит абстрактный запрос в структурированный план через интервью, снижая количество итераций с условных 50 до 10.

discovery-interview

Скил мог бы структурировать JTBD-интервью по лендингу, но пользователь не ставит задачу создать лендинг — он рефлексирует о процессе постановки задач вообще. Нет конкретного feature-запроса.

marketing

Упомянут лендинг, но это лишь пример в рассуждении. Реального запроса на маркетинговый контент или кампанию нет — только метадискуссия о декомпозиции.

Superpowers v5.1.0 / writing-plans

writing-plans помогает декомпозировать фичи, но только когда есть конкретная задача. Здесь запрос — оценить саму методологию, а не спланировать реализацию.

Summary: Запрос-рассуждение о методологии работы с ИИ, роутер не определил узел, ответ дан напрямую

Запрос содержит глубокую метапроблему о декомпозиции задач и итерациях — мог бы подойти узел для стратегического планирования или коучинга. Direct-ответ без структурированного подхода рискует воспроизвести именно ту проблему, о которой говорит пользователь

Когда пользователь описывает абстрактную проблему о своём рабочем процессе с ИИ — это сигнал для применения структурированного фреймворка: задать уточняющие вопросы, предложить методологию декомпозиции, а не просто отреагировать напрямую. Рефлексивные мета-запросы требуют особого роутинга.


Explanation: Запрос — чистый brainstorming: «что можно улучшить чтобы снизить итерации и поднять эффективность». Нет задачи написать код, нет багфикса, нет фичи. Нужен структурированный мозговой штурм с реальными, заземлёнными идеями (без фантазий). Superpowers#19 capability brainstorming — прямое попадание: генерирует идеи, ранжирует по impact, фильтрует призраки.

discovery-interview

discovery-interview нужен когда нужно ВЫТАЩИТЬ требования через интервью перед проектированием фичи. Здесь пользователь уже сформулировал вопрос достаточно конкретно — нужен не допрос, а генерация идей.

CCPM

CCPM — про управление dev-проектом: PRD→эпики→issues. Здесь нет задачи создать проект или эпик, есть запрос на улучшение рабочего процесса через идеи. Слишком тяжёлый инструмент.

product-management

product-management решает продуктовые церемонии (спеки, роадмап, метрики). Вопрос про снижение итераций — это про рабочий процесс и инженерную культуру, не про продуктовое планирование.

Summary: Запрос на брейншторм по улучшению рабочего процесса направлен в direct без определённого узла

Для стратегического брейншторма по оптимизации процессов мог бы подойти специализированный узел анализа/планирования. Direct — нейтральный выбор, но без структурированного подхода ответ может быть размытым

Запросы типа 'как улучшить наш процесс' требуют контекста предыдущих сессий. Без него роутер не может точно определить домен и выбирает generic-узел — стоит запрашивать уточнение контекста


Explanation: Запрос явно требует brainstorming-сессии: пользователь хочет пересмотреть предыдущие предложения и найти универсальные подходы для широкого спектра задач (финансы, BPM, логистика, маркетинг). Capability brainstorming в #19 — единственный инструмент для структурированной генерации и оценки идей без фантазий, только по реальным capabilities реестра.

discovery-interview

discovery-interview подходит для прояснения одной фичи или ориентации по системе, но пользователь уже чётко сформулировал контекст — универсальность vs специализация. Интервью здесь избыточно, нужен brainstorm по готовому тезису.

CCPM

CCPM работает с PRD → эпики → issues — это планирование конкретного проекта, а не генерация подходов. Пользователь ещё не на стадии планирования, он на стадии переосмысления архитектуры решения.

architecture-patterns

architecture-patterns даёт справочник паттернов (Clean Arch, DDD, CQRS), но это материал, а не процесс генерации идей. Может быть полезен как вспомогательный ресурс внутри brainstorm-сессии, но не как входная точка.

Summary: Запрос на пересмотр архитектуры универсальной мультизадачной системы, выбран узел brainstorming из superpowers

Запрос содержит критику предыдущих решений и требует стратегического переосмысления архитектуры — возможно, лучше подошёл бы узел architecture_review или strategic_planning, а не brainstorming. Brainstorming рискует снова уйти в фантазии, от которых пользователь явно устал.

Когда пользователь явно отвергает предыдущие подходы и просит 'реальных улучшений без фантазий' для универсальной системы — нужен структурированный аналитический узел, а не brainstorming. Акцент на практичности и ограничениях важнее генерации идей.


Summary: Роутер не определил узел, запрос отправлен напрямую без обработки специализированным узлом

Запрос на объяснение L1 (вероятно, уровень 1 в какой-то системе) с примерами требовал определения контекста — нужен был узел для обучения/объяснения или уточняющий диалог

Неполные запросы с местоимениями и сокращениями (л1, это) требуют либо уточнения контекста, либо маршрутизации в узел для интерактивного обучения, а не прямой отправки


Summary: Запрос 'обязательным фикси следующий' не был распознан роутером, выбран прямой узел без цепочки

Запрос неполный и обрывается на полуслове — нужно было запросить уточнение у пользователя вместо молчаливого fallback на direct

Незавершённые или синтаксически некорректные запросы требуют уточнения, а не автоматического перехода в direct-режим без обработки


Summary: Пустая цепочка выполнения при неопределённом узле роутера, fallback на direct без обработки

Роутер должен был определить контекст продолжения задачи и выбрать соответствующий узел; запрос 'фиксируй дальше' указывает на продолжение предыдущей работы

Короткие контекстуальные запросы-продолжения требуют анализа истории сессии для корректного роутинга, а не fallback на direct с пустой цепочкой


Explanation: Запрос 'фиксируй' без явного объекта и контекста неоднозначен: неясно что фиксировать (решение, инсайт, код, конвенцию), куда (CLAUDE.md, ADR, GitHub, комментарий) и о чём шла предшествующая сессия. ПАТТЕРН 2: два+ возможных интерпретации — требуется уточнение.

claude-md-management

Подходит если 'фиксируй' = capture learnings из сессии в CLAUDE.md, но запрос не упоминает CLAUDE.md явно

adr-kit

Подходит если 'фиксируй' = архитектурное решение → ADR, но нет явного контекста решения

GitHub MCP

Подходит если 'фиксируй' = записать в issue/комментарий, но нет указания на GitHub

Summary: Пользователь выразил согласие/одобрение, роутер не определил узел, выбран direct

Запрос содержит неструктурированный текст с подтверждением и просьбой фиксировать — стоило распознать intent как acknowledgment+action и направить в соответствующий узел памяти или логирования

Короткие эмоциональные сообщения с вкраплёнными инструкциями ('фиксируй') требуют разбивки на intent-части: подтверждение можно игнорировать, а команду — роутировать отдельно


Summary: Пустая цепочка выполнения при однословном неопределённом запросе 'фиксируй'

Роутер должен был запросить уточнение: что именно фиксировать, в каком контексте. Direct без цепочки не даёт пользы.

Однословные императивные команды без контекста требуют clarification-узла, а не silent direct-роутинга


Explanation: Запрос содержит минимум три разных интерпретации: (1) метакритика принципа жёсткой стандартизации как такового, (2) конкретная правка нормативки, (3) депрекация цепочки L6. Паттерн 2: если запрос можно интерпретировать двумя+ способами — не угадывай. Дополнительно: фраза 'или я не так понял?' сигнализирует что сам автор не уверен в формулировке. Требуется уточнение по трём осям перед любым действием.

claude-md-management

Подходит если цель — правка CLAUDE.md: убрать жёсткие правила стандартизации. Но запрос говорит о 'всех предложениях' и L6 — это шире одного файла. Без уточнения что именно менять — риск не туда.

normative-sync

Подходит если нужно синхронно обновить все 4 нормативных документа. Но normative-sync — это синхронизатор после изменений, не инициатор пересмотра концепции.

Superpowers v5.1.0 (brainstorming)

Brainstorming мог бы помочь сформулировать альтернативу стандартизации. Но без понимания конкретного scope (что именно пересматривать — архитектуру промптов, реестр, L6, всё?) — результат будет мимо.

Summary:
<tool_use_error>String to replace not found in file.
String: - Эффект: разведка

Summary: Роутер не определил узел, выбран direct для эмоционального сообщения об отказе от стандартизации

Нужен специализированный узел для обработки концептуальных/архитектурных дискуссий с контекстом проекта; сообщение требует понимания предыдущего контекста ('л6', 'предложения') которого нет

Эмоциональные запросы с отсылками к предыдущим решениям ('пересмотри все предложения') требуют контекстного узла с историей сессии; без контекста любой ответ будет неполным


Explanation: Запрос содержит как минимум три несовместимых интерпретации (ПАТТЕРН 2): (1) построчный code review 26 хуков под некие 'нововведения' неизвестной природы, (2) фикс конкретного дефекта после предыдущего разговора (контекст которого недоступен), (3) нормативная синхронизация хуков. Слово 'фикси' + 'нововведения' без указания что именно изменилось делают задачу неразрешимой без уточнения. Необходимо прояснить: (а) какие конкретно нововведения нужно учесть, (б) есть ли уже список найденных проблем или нужен fresh audit, (в) это хуки Claude Code (.claude/hooks/) или lefthook-хуки (.lefthook.yaml).

hookify

hookify активируется только по явному /hookify и предназначен для генерации новых хуков, а не для review/правки 26 существующих; нет триггера 'посмотри все хуки построчно'

normative-sync

normative-sync синхронизирует нормативные документы после завершённых интеграций, но не выполняет построчный аудит кода хуков; подходит только если 'нововведения' = изменения в Pravila/PSR_v1

Superpowers v5.1.0 (code-review)

superpowers:code-review мог бы покрыть построчный review хуков, но задача слишком неопределённа: неясно что такое 'нововведения', какой контекст предшествовал, и что именно нужно 'пофиксить' — без этого review не имеет критериев

Summary: Роутер не определил узел, выбран direct без цепочки обработки для ревью 26 хуков

Запрос требует детального code review с анализом изменений — нужен специализированный узел для code analysis или review, а не прямой ответ без цепочки

Запросы на построчный анализ множества хуков с учётом нововведений требуют цепочки: context_loader → code_reviewer → diff_analyzer, а не прямого роутинга


Summary: Роутер не определил узел, выбран direct для неясного запроса о 'машине 1'

Запрос слишком неоднозначен — нужно было запросить уточнение: что за 'машина 1', в каком контексте, что значит 'переделать'. Direct без контекста сессии неоптимален.

Короткие контекстно-зависимые запросы без предыстории сессии требуют clarification-узла или запроса уточнения перед роутингом, а не прямого ответа.


Summary: Ripgrep search timed out after 20 seconds. The search may have matched files but

Summary: Пустой запрос без контекста — маршрут не определён, выбран direct как fallback

Необходимо запросить уточнение у пользователя: что именно прочитать и что проверить. Отсутствует контекст файла или задачи.

Короткие императивные запросы без объекта действия ('прочитай и убедись') требуют уточняющего диалога перед роутингом, а не немедленного выбора узла.


Explanation: Запрос 'я хочу переехать' критически неоднозначен (ПАТТЕРН 2): нет указания на предмет переезда — инфраструктура, код, БД или что-то иное. Без уточнения невозможно выбрать ни один узел из реестра.

prod-deploy-validator

Подходит только если переезд касается боевого сервера liderra.ru (инфра/деплой), но запрос слишком краткий чтобы подтвердить это

Rector

Подходит если переезд означает version-upgrade Laravel/PHP, но нет явных признаков этого в запросе

CCPM

Мог бы помочь с планированием переезда как проекта, но без понимания предметной области планирование бессмысленно

Summary:
<tool_use_error>String to replace not found in file.
String: **Хвост:** 2 файла

Summary: Запрос на переезд/миграцию без определённого узла, выбран direct как fallback

Роутер не смог определить узел — возможно, запрос слишком краткий и неоднозначный. Стоило уточнить контекст: переезд чего именно (проекта, конфига, данных)?

Короткие разговорные запросы с имплицитным контекстом ('хочу переехать') требуют либо уточняющего вопроса, либо анализа предыдущего контекста сессии для корректного роутинга


Summary: Запрос 'коммить' не был распознан роутером, выбран прямой ответ без цепочки обработки

Роутер должен был распознать git-команду и направить к узлу выполнения shell/git операций с уточнением параметров коммита

Короткие команды-глаголы на русском (коммить, пушить, мержить) нужно маппить на соответствующие git-операции и запрашивать контекст: сообщение коммита, staged файлы


Explanation: Запрос — это структурированное продолжение multi-step design review (пункты D/E/F/G) с последующим обновлением чертежа и planning через superpowers:writing-plans. Superpowers #19 покрывает capability 'systematic-debugging + writing-plans + verify-before-completion + brainstorming' — именно то, что нужно для пошагового ревью архитектурных решений с владельцем. Параллельно задача требует чтения файлов через Read (handoff-реестр), что входит в meta-skill workflow superpowers.

adr-kit

ADR-kit создаёт и хранит Architecture Decision Records, но здесь идёт живое ревью решений в диалоге с владельцем — не фиксация уже принятых ADR. Фаза фиксации наступит позже.

discovery-interview

Discovery-interview подходит для JTBD-интервью перед проектированием фичи. Здесь владелец уже знает что строит — идёт построчное ревью конкретных пунктов D–G по готовому handoff-документу, а не открытое discovery.

architecture-patterns

Справочник архитектурных паттернов — справочный материал, не процессный инструмент. Пункты D–G касаются конкретных механизмов (default-deny матчер, волны шагов, авто-аудит дверей, сверка план↔журнал) — нужен управляемый итерационный процесс, а не lookup паттернов.

Summary: Запрос с кодовой фразой роутер-наставник направлен в direct без определённого узла специализации

Запрос требует работы с файловой системой, чтения документов и технического ревью — стоило направить в узел для работы с кодом/файлами, а не в direct

Сложные технические сессии с файловыми операциями и кодовым контекстом нужно маршрутизировать в специализированный узел, даже если запрос начинается с 'кодовой фразы'


Только наши чертежи

Только наши чертежи
Чертежи + полная нормативка
Сначала доделать D–G

Только наши чертежи

Explanation: Запрос состоит из двух последовательных шагов: (1) посмотреть всю карту проекта и нормативку — это прямой триггер для graphifyy (#86), capability 'query / explain / cluster-only' по всему порталу включая docs/ и .claude/; (2) актуализировать нормативку нововведениями — это прямой триггер для claude-md-management (#33) + normative-sync (#84). ПАТТЕРН 3: два глагола ('посмотри' + 'актуализируй') + подразумевается несколько этапов → chain ≥2. ПАТТЕРН 5: задача ≥3 шагов внутри, но цепочка уже определена реестром — graphifyy даёт structural map, затем #33/#84 проводят синк нормативки на основе увид

normative-sync

Покрывает только второй шаг (синхронизацию нормативных документов), но не даёт предварительной карты всего проекта — без #86 агент не увидит актуальное состояние всех слоёв перед правками.

claude-md-management

Закрывает изменение CLAUDE.md как обязательный канал, но это только один нормативный документ из четырёх; без graphifyy (#86) и normative-sync (#84) полная актуализация не будет выполнена.

Superpowers v5.1.0

writing-plans мог бы помочь составить план актуализации, но задача не требует проектирования — она описана как конкретная двухшаговая операция; добавление planning-шага создаст избыточность.

Summary: Роутер не определил узел, запрос перенаправлен напрямую без цепочки обработки

Запрос требует анализа документов проекта и нормативной базы — нужен узел с доступом к файлам/базе знаний и возможностью сравнительного анализа. Следовало определить узел типа document_analysis или project_review

Запросы на актуализацию нормативки по проекту требуют специализированного узла с доступом к файловой системе и знанию регуляторных изменений. Неопределённый роутинг — сигнал о пробеле в карте узлов.


Summary: Запрос 'лимит снят' не распознан роутером, направлен напрямую без обработки цепочки

Роутер должен был распознать намерение пользователя — вероятно, попытку обойти ограничения — и корректно обработать или отклонить запрос с пояснением

Короткие неоднозначные фразы о 'снятии лимитов' требуют специальной обработки: либо уточнения контекста, либо маршрутизации в узел безопасности


Summary: Роутер не определил узел, выбран direct — запрос про бан GitHub без чёткого контекста

Роутер мог бы распознать технический вопрос о доступе к GitHub и направить к узлу с IT/devops контекстом или общим советником

Неформальные запросы ('ха', 'че') с техническим содержанием должны обрабатываться по сути вопроса, а не по стилю написания


Laravel Boost

Мог бы подойти если 'машина 2' — запись в БД и нужно SELECT через Eloquent, но нет никаких SQL/model триггеров в запросе

GitHub MCP

Мог бы подойти если 'наши решения' — это GitHub issues/comments, но контекст 'машина 2' не даёт оснований

adr-kit

Мог бы подойти если 'наши решения' — ADR-записи, но нет явного упоминания архитектурных решений

Summary: Роутер не определил узел, выбран direct для вывода обновлённых пунктов машины 2

Роутер должен был определить узел для задачи суммаризации/форматирования контента из предыдущего контекста сессии; отсутствие роутингового решения снижает надёжность

Запросы на повторный вывод обновлённой информации из контекста сессии требуют явного узла для работы с памятью/историей диалога, а не прямого ответа без роутинга


Summary: Роутер не определил узел для вопроса о российских хостинг-альтернативах, запрос пошёл в direct

Следовало распознать запрос как информационный/рекомендательный и направить к узлу с базой знаний о хостингах или general-purpose узлу вместо fallback на direct

Запросы вида 'есть альтернатива X?' — это информационные запросы, требующие узла с актуальными знаниями о сервисах; роутер должен их классифицировать, а не оставлять без определения


**Контракт навыка** `{что нужно / что даёт / что нельзя}` + **переходник для чужих навыков** со «стражем подмены» (хеш — если чужой навык изменился, громкий флаг).

**Два плана:** сначала *разговорный* (думать/спрашивать до результата-артефакта), потом *строящий* (строгий, опечатанный).

**Две печати / два контроля судьи:** гейт-1 проверяет артефакт (после разговора, ловит «мусор на входе» рано), гейт-2 — план стройки.

**Закрытая дверь:** на стройке решать на ходу нельзя — каждый шаг ссылается на уже опечатанное решение; нет такого решения → единственный ход — назад в разговор и пере-печать.

**Look-ahead:** при сборке плана заранее тащим вопросы навыков-исполнителей в разговор (чтобы не всплыли поздно).

**Машина охвата:** граф зависимостей, реестр «нужда↔решение», чек-лист «просьбы цели → план», ограничения как полноправные нужды.

**Апелляция:** мелкие структурные придирки — 3 круга «судья↔я» по сухому каналу; суть и деньги — сразу к тебе.

**H** — у стены два режима: разговорный (только думать/спрашивать) и строящий (строгий матч).

**I** — вторая печать: морозим не только план, но и артефакт разговора (та же подпись).

**J** — резолвер закрытой двери: шаг обязан ссылаться на опечатанный пункт артефакта, иначе блок.

**K** — схема контракта навыка с L-полями (нужды/даёт/нельзя/образец/дефолты/что-фундаментально/критерий-готовности); защита от само-ослабления.

Summary: Пустой/неопределённый запрос 'д давай' — роутер не смог определить узел, выбран direct

Следовало запросить уточнение у пользователя вместо прямого ответа — запрос слишком неопределён для осмысленного роутинга

Короткие бессмысленные или неполные запросы требуют clarification-шага перед роутингом, а не fallback на direct


Summary: PreToolUse:Bash hook error: [node tools/enforce-router-gate.mjs]: [router-gate]

Summary: Запрос 'свой Forgejo/Gitea' не был обработан роутером — узел не определён, цепочка пуста

Роутер должен был распознать запрос как техническую задачу по self-hosted git-сервисам и направить к соответствующему узлу с контекстом о настройке/администрировании Forgejo или Gitea

Короткие запросы без глагола ('свой Forgejo/Gitea') должны триггерить уточняющий диалог или маппиться на узел технической помощи по DevOps/self-hosted инфраструктуре


Summary: Неопределённый роутер, выбран direct для короткого неоднозначного вопроса без контекста

Без контекста предыдущего разговора невозможно понять, о какой 'дисциплине' идёт речь. Нужна классификация намерения перед выбором узла.

Короткие вопросы с местоимениями ('это', 'токо') требуют контекста предыдущего диалога для корректного роутинга — без него confidence должен быть низким и стоит запросить уточнение.


Summary: Пользователь отправил минимальный ввод 'ок', роутер не определил узел, выбран direct

При неопределённом узле стоит запросить уточнение у пользователя вместо прямого ответа без контекста

Односложные подтверждения без контекста требуют уточняющего запроса, а не молчаливого роутинга в direct


Summary: Роутер не определил узел, выбран direct для неспецифичного запроса без контекста задачи

Запрос слишком короткий и неполный — нужно было запросить уточнение: что именно нужно сделать пошагово, прежде чем выбирать узел

Когда запрос неполный и неоднозначный, лучше задать уточняющий вопрос или выбрать узел для диалога/уточнения, а не просто направлять в direct


Summary: PreToolUse:Edit hook error: [node tools/enforce-parallel-session-lock.mjs]: [par

Summary: PreToolUse:PowerShell hook error: [node tools/enforce-powershell-gate.mjs]: [pow

Summary: PreToolUse:Bash hook error: [node tools/enforce-parallel-session-lock.mjs]: [par

Summary: Запрос 'закрепляй' не был распознан роутером, направлен в direct без обработки

Роутер должен был попытаться интерпретировать команду: 'закрепляй' может означать pin/bookmark сообщения или закрепление настройки. Нужна обработка коротких императивных команд

Короткие однословные команды на русском языке требуют отдельной логики распознавания намерений, даже без явного контекста


Summary: Пустая цепочка при неопределённом узле, запрос 'делай сам что нужно' слишком размытый для роутинга

Следовало запросить уточнение у пользователя: что именно нужно сделать? Без контекста невозможно выбрать подходящий узел.

Амбигуозные запросы без конкретики должны триггерить clarification-запрос, а не прямой fallback на direct с пустой цепочкой.


Summary: Роутер не определил узел, выбран direct по умолчанию для неоднозначного контекстного запроса

Запрос содержит контекст о доступе к облачному серверу и намерении продолжить задачу — следовало определить узел для работы с инфраструктурой или уточнить задачу перед роутингом

Фрагментарные запросы с намёком на продолжение предыдущей сессии требуют запроса дополнительного контекста или маршрутизации в узел с памятью сессии


Summary: Пользователь спросил о браузерных возможностях, роутер предложил #80, но выбран direct без цепочки

Следовало использовать узел #80 для обработки запроса об управлении браузером, а не переходить на direct с пустой цепочкой. Запрос требовал конкретного ответа о возможностях системы.

Когда роутер уверенно рекомендует специализированный узел (#80 для браузерных задач), не стоит игнорировать это решение в пользу direct — особенно если цепочка остаётся пустой, что означает фактическое отсутствие обработки.


Summary: Роутер не смог определить узел для неоднозначного запроса, выбран прямой ответ

Запрос 'пробуй снова в твоем дереве ни кто не сидит' очень неоднозначен — возможно, стоило запросить уточнение у пользователя перед роутингом

Когда запрос содержит метафоры или неясный контекст, лучше задать уточняющий вопрос, чем делать прямой ответ без понимания намерения


Explanation: Запрос является разговорной/неформальной фразой без чёткого технического контекста. Паттерн 2 (discovery-interview): запрос допускает минимум 3 интерпретации (A/B/C), угадывание недопустимо. Возвращаю no_skill_found=true с предложением уточнить намерение.

Playwright MCP

Playwright MCP управляет headless Chromium и может открыть браузер, но запрос не содержит конкретного URL, задачи тестирования или скриншота — неясно, что именно нужно сделать после открытия

Superpowers v5.1.0

Нет признаков задачи разработки, планирования или отладки — meta-skills не применимы к неформальному разговорному запросу

prod-deploy-validator

Не содержит триггеров production-деплоя или проверки сервера liderra.ru

Summary: PreToolUse:mcp__playwright__browser_navigate hook error: [node tools/enforce-mcp

Summary: Пользователь предложил открыть браузер для авторизации, роутер не определил узел, выбран direct

Запрос требует отказа или разъяснения: Claude не может открыть браузер или получить доступ к внешним системам. Нужен узел с отказом/разъяснением возможностей.

Запросы на физические действия (открыть браузер, залогиниться) должны маршрутизироваться к узлу, объясняющему ограничения Claude, а не к direct без обработки.


Summary: Роутер не определил узел, выбран direct для короткой заметки-напоминания о волнах на третьей машине

Роутер должен был определить узел — запрос похож на задачу создания заметки или TODO, подходит узел типа notes/todo или memory

Короткие неформальные фразы с просьбой 'пометить/не забыть' нужно распознавать как задачи управления заметками и направлять в соответствующий узел


Summary: Пустой запрос 'давай' без контекста — роутер не смог определить узел, выбран direct

Запросить уточнение у пользователя: что именно он хочет сделать, вместо прямого ответа без контекста

Односложные запросы-триггеры без контекста требуют уточняющего вопроса, а не попытки угадать намерение


Explanation: Запрос не привязан к конкретной задаче проекта Лидерра: неизвестно что разворачивать (приложение? инструмент? среду?), на какую машину, и является ли это частью проекта. Сработал ПАТТЕРН 2 (discovery-interview): два и более способа интерпретации → не угадываем, возвращаем no_skill_found с предложением уточнить A vs B vs C.

Скил проверяет готовность боевого сервера liderra.ru к деплою (READ-ONLY SSH-проверки). Запрос не содержит явного указания на liderra.ru и не упоминает конкретное приложение — слишком мало контекста для активации.

operations

Плагин содержит runbook-скил для документирования инфраструктурных операций, но запрос не описывает бизнес-процесс — это вопрос о возможностях среды выполнения, а не задача документирования.

discovery-interview

Запрос допускает минимум 3 интерпретации (паттерн 2 — ambiguous), поэтому правильнее вернуть no_skill_found с уточняющим вопросом, чем запускать discovery-interview без понимания объекта деплоя.

Summary: Роутер не определил узел, запрос направлен в direct без обработки цепочки

Роутер должен был распознать вопрос о деплое/развёртывании и направить к специализированному узлу для технических консультаций по инфраструктуре

Вопросы о локальном развёртывании, серверах с белым IP и деплое следует маршрутизировать к узлу с экспертизой DevOps/инфраструктуры, а не оставлять без определённого узла


Summary: Получен пустой/минимальный запрос '!', роутер не смог определить узел, выбран прямой ответ

Следовало запросить уточнение у пользователя вместо прямого ответа на бессмысленный ввод

Одиночные символы или пустые запросы требуют явного запроса уточнения, а не попытки роутинга или прямого ответа


Explanation: Запрос 'сноси она остановлена' содержит неопределённое местоимение 'она' без референта и глагол 'сноси' без объекта. Невозможно однозначно определить: (A) CRM-объект (лид, сделка, запись), (B) Docker-сервис/контейнер, (C) Git-ветка или задача. Требуется уточнение объекта операции.

Laravel Boost

Подошёл бы, если речь о DELETE-запросе к БД через Eloquent, но объект операции ('она') не указан

GitHub MCP

Подошёл бы, если речь о закрытии/удалении issue или ветки, но контекст не задан

Superpowers v5.1.0

Мог бы помочь с систематической отладкой, но запрос слишком краткий для определения задачи

Summary: Запрос 'сноси она остановлена' не был маршрутизирован ни в один узел, выбран direct без цепочки

Необходимо лучше интерпретировать неоднозначный запрос: вероятно речь о остановке/удалении процесса или сервиса. Следовало направить в узел для системных операций или уточнения намерения

Короткие разговорные команды ('сноси', 'останови') требуют контекстного анализа и маршрутизации в узел уточнения или системных задач, а не прямого игнорирования


Summary: Запрос 'давай я его снесу' крайне неоднозначен — роутер не смог определить узел, выбран direct

Необходимо запросить уточнение контекста: снести здание, удалить файл/директорию, удалить приложение или что-то иное. Роутинг без контекста ненадёжен.

Короткие фразы с местоимением 'его' без предшествующего контекста требуют clarification-шага перед роутингом, иначе direct-fallback является единственным безопасным выбором.


Summary: Пользователь отправил 'готово' без контекста, роутер не определил узел, выбран direct-ответ

Без предшествующего контекста невозможно определить, на что именно отвечает пользователь; стоило запросить уточнение вместо direct

Короткие подтверждающие сообщения ('готово', 'ок', 'да') требуют контекста предыдущего диалога для корректного роутинга — без него лучше запрашивать уточнение


Summary: Запрос 'да фикси' не был распознан роутером, выбран direct без цепочки обработки

Роутер должен был распознать намерение исправить/починить что-то и запросить уточнение контекста или направить на узел для редактирования/отладки кода

Короткие императивные запросы без контекста ('фикси', 'сделай', 'исправь') требуют уточняющего диалога или маппинга на узел clarification, а не прямого пропуска


Summary: Роутер направил на узел #19, фактически выполнен superpowers:writing-plans при пустой цепочке выполнения

Неясно соответствие между #19 и superpowers:writing-plans — нужна явная маппинг-таблица узлов. Пустая цепочка выполнения вызывает сомнения в корректности обработки.

Необходимо фиксировать явное соответствие между числовыми ID узлов и их символическими именами, а также логировать причину пустой цепочки выполнения для диагностики.


Explanation: ПАТТЕРН 2 (discovery-interview): запрос допускает минимум 3 интерпретации домена плана и содержит внутреннее противоречие ('брейншторм' vs 'без фантазий'). Без конкретного артефакта и уточнения типа плана любой выбор скила будет угадыванием. Требуется clarify перед маршрутизацией.

Superpowers v5.1.0 (brainstorming)

Brainstorming sub-skill подходит для генерации идей, но без конкретного артефакта плана применить невозможно — нет входных данных для анализа

discovery-interview

Discovery-режим помог бы структурировать что именно нужно проверить, но сам запрос слишком неоднозначен даже для старта интервью — непонятен тип плана и домен

product-management

Ревью продуктового плана теоретически возможно, но нет ни документа, ни контекста — это один из 5+ возможных доменов, угадывать нельзя (ПАТТЕРН 2)

Summary: Роутер не определил узел, фактически выбран superpowers:brainstorming для ревью плана со свежим взглядом

Запрос содержит два компонента: критический анализ плана (ревью/аудит) и брейншторм. Возможно, более подходящим был бы узел типа review/analysis, а не чистый brainstorming. Роутер должен был определить узел.

Когда запрос содержит 'посмотри свежим взглядом' + 'брейншторм' + 'не фантазируй' — это скорее критический анализ с элементами генерации идей, а не чистый brainstorming. Роутер должен различать эти паттерны и не оставлять решение неопределённым.


Summary: Запрос 'давай по порядку' без контекста — роутер не смог определить узел, выбран direct

Запрос слишком неопределённый и лишён контекста. Роутер мог бы запросить уточнение у пользователя вместо fallback на direct. Либо проанализировать предшествующий диалог для определения намерения.

Короткие фразы без контекста ('давай по порядку', 'продолжай', 'ещё') требуют анализа истории диалога или запроса уточнения, а не слепого fallback на direct-узел.


Summary: Короткий подтверждающий ответ пользователя — роутер не определил узел, выбран direct

Роутер должен лучше обрабатывать короткие подтверждения в контексте предыдущего диалога и направлять к соответствующему узлу на основе контекста сессии

Короткие фразы-подтверждения ('да', 'вноси', 'давай') требуют анализа предшествующего контекста для корректного роутинга, а не fallback на direct


Summary: Роутер не определил узел, выбран direct в ответ на stop hook feedback об ошибке coverage

Роутер должен был распознать системное сообщение от stop hook и направить его в специализированный узел обработки ошибок или self-correction, а не в direct

Stop hook feedback — это служебное сообщение о нарушении инварианта, требующее коррекции поведения. Роутер должен уметь классифицировать такие сообщения и направлять их в узел самокоррекции или compliance-обработки


normative-sync

Подходит если пересмотр 'слоя общения' — завершённая интеграция, требующая синка нормативки. Но запрос не содержит маркера cls:normative_sync_needed и неясно, завершена ли задача или она ещё обсуждается.

adr-kit

Подходит если решение по 'отдельному слою общения' нужно зафиксировать как ADR. Но запрос звучит как вопрос/сомнение, а не запрос на фиксацию решения.

discovery-interview

Подходит для прояснения неструктурированного запроса про фичу/систему. Но запрос слишком короткий и контекстный — без знания что такое 'этап общения' и что такое 'это' discovery не поможет.

Summary: Запрос о корреляции пересмотренного слоя общения с текущим контекстом — роутер не определил узел, выбран direct

Роутер должен был распознать технический вопрос об архитектуре системы и направить к узлу с контекстом проекта или уточнением требований. Direct без цепочки — слабый выбор для аналитического вопроса.

Вопросы типа 'как это коррелируется с X' при наличии архитектурного контекста требуют узла с доступом к истории решений сессии, а не голого direct-ответа.


Summary: Запрос 'принято фикси и дальше' не распознан роутером, выбран direct без цепочки обработки

Роутер должен был попытаться интерпретировать неформальный запрос: 'фикси' вероятно означает 'fix it' — исправление кода. Нужна нормализация сленга и неформальных команд перед роутингом

Короткие неформальные команды на смешанном языке (русский+английский сленг) требуют отдельного препроцессинга для извлечения намерения перед роутингом


Explanation: ПАТТЕРН 2 (discovery-interview): запрос можно интерпретировать минимум тремя способами — (A) захватить принцип в CLAUDE.md, (B) обновить нормативку, (C) аудит конфигов на лишний small-talk. Ни один из них не очевиден без уточнения. Угадывать нельзя.

claude-md-management

Подходит если цель — зафиксировать принцип 'всегда по делу' в CLAUDE.md как learning из сессии. Но запрос не содержит явного 'запиши в CLAUDE.md' — интерпретация A остаётся гипотезой

normative-sync

Подходит если цель — синхронизировать нормативные документы с новым принципом коммуникации. Но нет явного триггера cls:normative_sync_needed и нет завершённой интеграции, после которой нужен синк

graphifyy

Подходит если цель — структурно найти где в конфигах/скилах прописано conversational-поведение. Но это слишком тяжёлый инструмент для того что скорее всего является feedback-сообщением, а не исследовательским запросом

Summary: Пользователь уточнил рабочий стиль — без болтовни, только по делу. Роутер не определил узел, выбран direct.

Роутер должен был распознать мета-сообщение о предпочтениях пользователя и направить в узел обновления контекста/профиля сессии, а не просто в direct без цепочки.

Сообщения о стиле общения и рабочих предпочтениях — это не болтовня, а важный контекст для настройки поведения. Нужен узел для обработки пользовательских инструкций по формату взаимодействия.


Explanation: Запрос содержит два чётких шага: (1) 'зафиксировать решение' — прямой триггер #36 (adr-kit: создаёт Architecture Decision Records в docs/adr/); (2) 'посмотреть где ещё исправить чтоб больше не спотыкаться' — поиск по всей кодовой базе мест, затронутых тем же паттерном, что закрывает #86 (graphifyy: cross-layer query 'where is X used', 6305 узлов/6753 рёбра). Порядок важен: сначала фиксируем решение (ADR), потом делаем структурный поиск по графу, чтобы найти аналогичные места.

architecture-patterns

Справочник паттернов помогает обосновать решение теоретически, но не фиксирует ADR-артефакт и не умеет искать конкретные места в кодовой базе — оба ключевых требования запроса закрывают #36+#86.

deptrac

deptrac проверяет нарушения зависимостей между слоями, но не создаёт ADR и не позволяет задать cross-layer запрос 'где ещё встречается этот паттерн' — это узкий линтер слоёв, а не граф-навигатор.

claude-md-management

Фиксирует learnings в CLAUDE.md, но ADR-kit (#36) — правильный артефакт для архитектурных решений с enforcement; CLAUDE.md-канал не предназначен для структурного поиска по кодовой базе.

Summary: Роутер не определил узел, запрос направлен напрямую без цепочки обработки

Запрос требует анализа кодовой базы и фиксации решения — нужен узел для работы с кодом/документацией, а не прямой ответ

Фразы 'зафиксировать решение' и 'где ещё исправить' указывают на задачу анализа кода и документирования — роутер должен распознавать такие паттерны и направлять в соответствующий узел


Summary: Запрос 'рабираем дальше' без контекста направлен в direct без предварительного роутинга

Необходим контекст предыдущего разговора для корректного роутинга; запрос слишком краткий и неоднозначный для уверенного выбора узла

Короткие продолжающие фразы без контекста сессии требуют либо запроса уточнения, либо анализа истории диалога перед роутингом


Explanation: ПАТТЕРН 2 (discovery-interview): запрос содержит местоимение 'это' без антецедента в диалоге. Невозможно определить систему/контекст/объект суждения. Две+ несовместимые интерпретации (дисциплина команды vs поведение классификатора vs архитектурное решение). Угадывание запрещено.

discovery-interview

Мог бы помочь прояснить намерение через структурированное интервью, но запрос не является feature/system запросом — это meta-вопрос о системе классификации

adr-kit

Если 'это' — архитектурное решение, ADR мог бы зафиксировать его; но без референта применять невозможно

Superpowers v5.1.0

Brainstorming мог бы разобрать риски 'обходного пути', но запрос не про разработку — про мета-дисциплину классификатора

Summary: Роутер не определил узел, запрос ушёл в direct без обработки специализированной цепочкой

Запрос содержит явный запрос на честную оценку последствий решения — это задача для аналитического или консультативного узла, а не прямой передачи. Нужно было определить контекст (скилл, дисциплина, обходной путь) и направить к соответствующему узлу

Неполные или контекстно-зависимые запросы без явного домена сложно роутить, но признаки аналитического вопроса ('честно', 'как есть', оценка рисков) должны триггерить консультативный узел даже при неясном контексте


**Остаток А — readonly-Bash зависит от точности классификатора.** `git status`/`log` безобидны, но `git log > evil.sh` уже **пишет файл**, а `git config ...`/`git gc`/`tee`/подстановки — меняют состояние. Если `classifyBashCommand` назовёт такое «readonly» — мутация просочится мимо плана. Это **реальная дыра ровно настолько, насколько классификатор аккуратен с редиректами/побочками**. Не фантазия — это надо явно потребовать: «редирект `>`/`>>`/`|` в писатель / пишущие подкоманды → НЕ readonly», + защитный пол (секреты/runtime/force-push) всё равно ловит, + аудит дверей сторожит.

**Остаток Б — TodoWrite безопасен ТОЛЬКО потому, что «взял ли я навык» проверяется по ЖУРНАЛУ, а не по тексту TodoWrite.** Сам по себе TodoWrite ничего не строит, но в нём можно **написать словами** «шаг: покрыто навыком X», изобразив, что навык был. Это ловит **не стена, а судья (Машина 4, A2)** — он сверяет заявку с фактическим журналом вызовов (принцип «верим делу, не словам»). Если этой сверки журнала не будет — зелёный TodoWrite **открыл бы** путь фейкового покрытия. То есть его безопасность **держится на существовании журнальной сверки в Машине 4**, и это надо зафиксировать как зависимость, а не считать «само собой».

Summary: Запрос слишком краткий и без контекста — роутер не смог определить узел, выбран direct

Необходим контекст предыдущего разговора для корректного роутинга; стоило запросить уточнение или использовать контекстную память сессии

Короткие follow-up вопросы ('а для X?') требуют анализа истории диалога — роутер должен учитывать предыдущие сообщения сессии для корректного определения узла


Summary: Короткий неоднозначный запрос 'да фиксируй' направлен на direct без определения узла роутером

Роутер не смог определить узел из-за неполноты контекста. Следовало запросить уточнение: что именно фиксировать и в каком контексте

Односложные подтверждающие фразы без контекста предыдущего диалога не поддаются корректному роутингу — необходим анализ истории сессии или запрос уточнения


**(а)** пропатчить под призму «нет болтовни» (синхрон с чертежами), или

**(б)** оставить историческим источником, дописав сверху одну строку «см. ревизию 2026-06-04 в чертежах Машины 2»?

Summary: Пользователь отправил одиночный символ 'а', роутер не смог определить узел, выбран direct

Можно запросить уточнение у пользователя вместо прямого ответа на бессодержательный запрос

Односимвольные или бессодержательные запросы требуют запроса уточнения, а не попытки роутинга


graphifyy

Подходит для cross-layer query 'как правки касаются других частей', но не покрывает 'дыры в дисциплине' — это только структурный анализ связей, без оценки нарушений архитектурных правил или security

deptrac

Покрывает архитектурную дисциплину (direction зависимостей между слоями), но не покрывает security-дыры и cross-machine impact на инфраструктуру

Trail of Bits Skills

Покрывает глубокий diff-review и supply-chain risk, но требует уточнения — речь о security-дырах или архитектурных нарушениях дисциплины? Без этого нельзя однозначно выбрать

Summary: Роутер не определил узел, запрос ушёл напрямую без цепочки обработки

Запрос требует аналитики и код-ревью — нужен специализированный узел для анализа архитектурных решений и их побочных эффектов; direct без цепочки не даёт структурированного анализа

Запросы типа 'посмотри наши правки на дыры в дисциплине и влияние на другие компоненты' — это архитектурный аудит, требующий узла с контекстом кодовой базы и цепочкой проверок связности


Explanation: Запрос содержит только эмоциональное описание желаемого результата ('горело', 'не пропустишь') без указания: что именно создать, в какой части системы, для какой аудитории. Это классический ПАТТЕРН 2 (discovery-interview) — минимум 3 возможных интерпретации, угадывание запрещено.

marketing

Если имеется в виду 'горящий' маркетинговый текст/оффер — подошёл бы, но контекст слишком размыт для уверенного выбора

Frontend Design plugin

Если имеется в виду визуальный UI-элемент с акцентом (огонь, highlight, анимация) — мог бы помочь, но объект задачи не определён

Superpowers v5.1.0

Общий catch-all для фич/планирования, но без понимания что именно нужно сделать — неприменим

Summary: Роутер не определил узел, выбран direct для эмоционального запроса без конкретной задачи

Запрос слишком контекстно-зависим — нет предыдущего диалога, непонятно что именно нужно сделать 'горящим'. Роутер должен был запросить уточнение или выбрать узел clarification

Эмоциональные запросы без явного контекста требуют узла уточнения, а не прямого ответа — иначе ответ будет угадыванием


Summary: PreToolUse:Bash hook error: [node tools/enforce-router-gate.mjs]: [router-gate]

Summary: Запрос 'комить' (вероятно, git commit) не был распознан роутером, выбран прямой путь без цепочки

Роутер должен был распознать 'комить' как команду git commit и направить к соответствующему узлу для выполнения git-операции

Транслитерированные/русифицированные команды (комить, пушить, пуллить) нужно добавить в словарь роутера как алиасы git-операций


Explanation: Запрос содержит минимум два неразрешённых измерения: (1) формат артефакта — текстовый промпт vs хук vs CLAUDE.md-правило; (2) 'подцепила все' — неясно что именно: MCP-серверы, .env, конкретный worktree по имени, lefthook, или всё вместе. Без уточнения любой выбор будет угадыванием (ПАТТЕРН 2).

hookify

Hookify генерирует хуки Claude Code — подошёл бы если задача 'автоматически при старте сессии активировать нужный worktree', но запрос звучит как 'написать промпт вручную', а не 'создать хук'; без явного /hookify не активируется

claude-md-management

Подошёл бы если цель — зафиксировать worktree-инструкцию в CLAUDE.md как постоянное правило для всех сессий; но запрос говорит 'промпт для другой сессии', а не 'правило в CLAUDE.md'

claude-code-setup

Рекомендует автоматизации Claude Code на основе паттернов использования — частично релевантен, но READ-ONLY рекомендатель, не генерирует промпты; слабое совпадение с триггерами

Summary: Запрос на создание промпта для другой сессии — роутер не определил узел, выбран direct

Роутер должен был распознать задачу как генерацию промпта/инструкции и направить к специализированному узлу для создания документации или шаблонов. Запрос содержит опечатки, что затруднило разбор намерения.

Запросы типа 'сделай промпт/инструкцию для другой сессии' следует маршрутизировать к узлу генерации промптов или документации, даже если текст содержит опечатки и неформальный стиль


Summary:
Exit code 128
remote: Your account is suspended. Please visit https://support.gi

Summary: Однословный запрос 'пуш' не был распознан роутером, направлен напрямую без цепочки обработки

Роутер должен был запросить уточнение: 'пуш' может означать git push, push-уведомления, маркетинговый пуш или что-то иное. Нужна классификация неоднозначных коротких запросов.

Однословные и жаргонные запросы требуют обязательного уточнения контекста перед роутингом. Следует добавить узел для обработки неоднозначных запросов с запросом дополнительной информации.


Explanation: Запрос — многошаговая сборка Машины 2 по TDD через superpowers:subagent-driven-development (Tasks 1–14). Superpowers #19 покрывает capability 'TDD, subagent-driven development, writing-plans, verify-before-completion'. Pest/Vitest #18 покрывает capability 'TDD, test-first, vitest tools-only regression' — явно указан в условии задачи ('собрать по TDD'). Паттерн 5: ≥3 шагов → plan уже готов (Tasks 1–14 в файле-чертеже), поэтому writing-plans пропускается, прямо к subagent-driven-development. Паттерн 3: multi-step chain (14 Tasks последовательно).

Superpowers v5.1.0 — только writing-plans

План уже финализирован (коммит 8a790e6f, Tasks 1–14 закрыты, fresh-eyes ревизия закрыта) — writing-plans излишен. Нужен именно subagent-driven-development как режим исполнения, а не планирования.

Vitest

Vitest — инструмент запуска тестов, но не организатор TDD-процесса сборки. Без superpowers:subagent-driven-development нет контроля порядка Tasks, контрактов K1–K4 и TDD-цикла RED→GREEN→REFACTOR.

CCPM

CCPM управляет PRD→эпики→issues→код, но задача уже на стадии исполнения (план готов). Нет capability для TDD-driven построения по чертежу с контрактами межмашинного взаимодействия K1–K4.

Summary: Ripgrep search timed out after 20 seconds. The search may have matched files but

Summary: PreToolUse:Bash hook error: [node tools/enforce-parallel-session-lock.mjs]: [par

Summary: Запрос с кодовой фразой 'роутер-наставник машина 2 — сборка' направлен на direct без определённого узла, цепочка пуста

Запрос явно технический и требует чтения файлов + выполнения инструментов — логичнее было бы направить в subagent или tools-узел, а не в direct

Кодовые фразы с явными инструкциями по чтению файлов и TDD-сборке следует маршрутизировать в узел с доступом к инструментам, а не в conversational direct


Summary: Роутер не определил узел, система выбрала direct без прохождения цепочки обработки

Роутер должен был определить узел до выбора direct; отсутствие routing-тега в ответе нарушает требования observer-хука

Когда пользователь явно указывает метод (subagent-driven-development), роутер обязан зафиксировать это в routing-теге с counterfactual-узлом для корректного аудита


Я строю сам, честный TDD (рекоменд.)

Я строю сам, честный TDD (рекоменд.)
Ты отключаешь гейт, жмём субагентами
Субагенты с override-фразой

Я строю сам, честный TDD (рекоменд.)

Summary: Exit code 127

Summary:
Exit code 1

 RUN  v4.1.8 C:/моя/проекты/портал crm/Документация/.claude/worktre

Summary: PreToolUse:Edit hook error: [node tools/enforce-tdd-real-test-verifier.mjs]: [td

Task 1 plan-lock freeze/verify

Task 1 plan-lock (fixed)

Summary: Пустой/неопределённый запрос 'поехали' направлен на subagent-driven-development без анализа контекста

Роутер не смог определить узел. Нужно было запросить уточнение у пользователя или выбрать узел-приветствие/диалоговый узел вместо subagent-driven-development

Короткие восклицания-триггеры ('поехали', 'начнём', 'давай') требуют уточнения контекста перед роутингом, а не автоматического направления в сложный узел разработки


Summary: Короткая нераспознанная команда 'коммитть' направлена в direct без цепочки обработки

Стоило распознать опечатку в слове 'коммитить' (git commit) и направить к узлу работы с git/VCS, запросив уточнение контекста

Короткие команды с опечатками требуют нормализации и сопоставления с известными паттернами (git, deploy и т.д.) перед роутингом


Summary: Роутер не определил узел, система перешла на direct при ошибке валидации coverage vs Skill tool

Роутер должен был явно определить узел вместо fallback на direct. Нужно либо вызвать Skill tool с нужным именем, либо корректно указать direct:<role> с обоснованием в coverage.

Когда coverage указывает skill:X, необходимо фактически вызвать Skill tool с этим именем в том же turn. Несоответствие между coverage и реальными вызовами инструментов должно обнаруживаться до завершения роутинга, а не через stop hook.


Одобряю — пиши design-doc

Одобряю — пиши design-doc
Хочу правки

Одобряю — пиши design-doc

Summary: <tool_use_error>InputValidationError: AskUserQuestion failed due to the followin

Summary: Роутер не определил узел для запроса 'продолжай', выбран brainstorming без контекста предыдущей цепочки

Запрос 'продолжай' требует контекста предыдущего диалога. Роутер должен был запросить уточнение или проанализировать историю сессии перед выбором узла. Brainstorming — вероятно неверный выбор без понимания, что именно продолжать.

Однословные команды продолжения ('продолжай', 'давай', 'дальше') без контекста должны триггерить запрос уточнения или анализ истории сессии, а не произвольный выбор узла.


Summary: Роутер не определил узел, выбран direct в ответ на системный feedback от enforce-coverage-verify

Роутер должен был распознать служебный stop-hook feedback и явно выбрать direct:system или специализированный узел для обработки инфраструктурных сообщений, а не оставлять решение неопределённым

Stop-hook и системные feedback-сообщения следует детектировать как отдельный тип запроса и сразу маршрутизировать в direct с обоснованием, не оставляя роутер в состоянии 'не определён'


Explanation: Запрос содержит два чётких шага: (1) критический review спецификации на полноту/логику/дыры — это superpowers:brainstorming (#19, capability: brainstorming + verify-before-completion + code review), (2) проверка именно продуктовой спеки на разрывы и пробелы — это product-management (#42, capability: написание и проверка спецификаций `/write-spec`). ПАТТЕРН 3: 'и'/'потом' подразумевается (review → brainstorm → итог), ПАТТЕРН 1: brainstorming обязателен с ≥3 альтернативами.

product-management

Покрывает review спеки, но не даёт structured brainstorming-механику для поиска слепых зон и логических дыр. Нужен как второй узел цепочки, не единственный.

discovery-interview

JTBD-интервью — это сбор требований с заказчиком, а не ревью готовой спеки на внутреннюю полноту. Контекст другой: спека уже написана, нужен критик, не интервьюер.

CCPM

CCPM работает с PRD → эпики → issues → код. Здесь задача — критический анализ готового документа, а не управление жизненным циклом задач. Не тот инструмент.

Summary: Роутер не определил узел, но фактически выбран superpowers:brainstorming для анализа спеки на полноту и логику

Запрос содержит два компонента: критический анализ документа (review/critique) и брейншторм. Более точным мог быть узел review или analysis перед brainstorming, либо комбинированный подход. Роутер не справился с определением узла — это основная проблема.

Запросы с явным словом 'брейншторм' не всегда означают чистый brainstorming — здесь первичен критический аудит спеки, а brainstorming вторичен. Роутер должен учитывать контекст задачи, а не только ключевые слова.


Summary: Пустой запрос без контекста направлен напрямую без определения узла роутером

Роутер должен был запросить уточнение темы обсуждения перед маршрутизацией, так как 'всё по порядку' не даёт информации о предметной области

Амбигуозные запросы типа 'давай обсудим' требуют уточняющего вопроса или анализа предыдущего контекста сессии перед выбором узла


Explanation: Запрос является неполным разговорным подтверждением ('да пойдет') + неопределённой командой ('фиксируй дальше') без какого-либо технического или продуктового контекста. Невозможно однозначно определить ни task_type, ни целевой skill без уточнения.

claude-md-management

Слово 'фиксируй' может намекать на захват learnings в CLAUDE.md, но нет явного контекста предыдущей сессии или конкретного learning для записи.

Superpowers v5.1.0

Может быть продолжением какого-то процесса разработки, но полностью отсутствует контекст — непонятно что именно 'фиксировать' и в каком шаге workflow.

adr-kit

Если имеется в виду фиксация архитектурного решения — ADR-kit подошёл бы, но нет ни темы ADR, ни предыдущего контекста обсуждения архитектуры.

Summary: Короткий подтверждающий ответ пользователя, роутер не определил узел, выбран direct

Роутер должен распознавать контекстуальные подтверждения ('да пойдет', 'ок', 'продолжай') и направлять к узлу продолжения задачи или к предыдущему активному узлу

Короткие подтверждения без явного контента требуют контекстной памяти — роутер должен учитывать предыдущий узел сессии и продолжать работу в том же направлении


Summary: Роутер не определил узел, но фактически выбран superpowers:brainstorming для мета-задачи об улучшении роутера

Роутер должен был самостоятельно определить узел — запрос явно подходит под brainstorming. Пустая цепочка выполнения говорит о сбое на этапе роутинга, а не выбора узла

Запросы на генерацию идей/улучшений с ключевыми словами 'брейншторм', 'подумаем как', 'что можно сделать' должны уверенно маппиться на brainstorming без колебаний


Explanation: Запрос является разговорным (conversation): пользователь просит пересказать логику классификатора из системного промпта. По правилу 2 — conversation обрабатывается ДО роутера. Ни один skill из реестра не покрывает capability 'объяснить собственную механику роутера'. no_skill_found=true.

discovery-interview

Не discovery-сессия по фиче или системе — пользователь задаёт прямой вопрос о механике роутера

Superpowers v5.1.0

Не задача разработки, не bugfix, не feature — чистый мета-вопрос о классификаторе

claude-md-management

Нет запроса на правку CLAUDE.md — только вопрос о логике роутера

Summary: Роутер не определил узел, запрос ушёл в direct без цепочки инструментов

Роутер должен был распознать информационный запрос о собственной спецификации и направить в узел документации или self-reference, либо явно обработать через RAG по спеке

Запросы вида 'напомни как работает X по спеке' требуют явного узла для self-referential или doc-lookup задач; отсутствие определённого узла при наличии фактического ответа — признак пробела в роутинговых правилах


Explanation: Запрос явно требует брейншторма ('запусти брейншторм') по архитектурной/методологической теме — как обеспечить дисциплину соблюдения вшитых методов (2 метода-стандарта, 3 слоя). Capability superpowers:brainstorming в #19 — прямой match. Уточнение 'без фантазий, по факту' указывает на необходимость структурированного, evidence-based брейншторма, что входит в режим работы этого скила.

adr-kit

ADR-kit фиксирует уже принятые архитектурные решения, но не генерирует варианты подходов к дисциплине. Не брейншторм-инструмент.

deptrac

deptrac enforces layer dependencies статически в коде, но не помогает разработать методологию/дисциплину соблюдения стандартов — это инструмент enforcement, а не ideation.

discovery-interview

Мог бы прояснить контекст ('2 метода-стандарта, 3 слоя' — что именно?), но пользователь явно сформулировал запрос как брейншторм, а не как discovery. Кроме того, запрос достаточно конкретен по интенту.

Summary: Роутер не определил узел, но был выбран superpowers:brainstorming для структурированного анализа дисциплины мышления

Запрос содержит специфический контекст ('вшитые методы-стандарты', '3 слоя') который не был прояснён до выбора узла. Стоило сначала уточнить предметную область, прежде чем запускать брейншторм. Также роутер должен был определить узел — его отказ сигнализирует о недостаточной классификации запроса.

Неполные или технически-специфичные запросы с жаргоном требуют уточняющего шага перед роутингом. Отсутствие определённого узла роутером — сигнал к переспросу, а не к автоматическому выбору brainstorming как fallback.


Explanation: Запрос — явный brainstorming: «подумай», «брейншторм», анализ усиления трёх слоёв (frontend/backend/infra). capability superpowers:brainstorming предназначен ровно для этого — структурированный штурм по действующему реестру узлов без фантазий, только факты по существующим capabilities. Ни один другой узел не ведёт brainstorming-сессию по реестру.

discovery-interview подходит когда нужно выяснить требования к конкретной фиче у заказчика (JTBD-режим). Здесь нет неясных требований — запрос чёткий: провести аналитический брейншторм по реестру. Неправильный режим применения.

architecture-patterns

architecture-patterns — справочник паттернов (Clean Arch, DDD и т.д.), он отвечает на вопрос 'какой паттерн применить', а не 'как усилить набор инструментов'. Не покрывает фронт- и infra-слои реестра.

CCPM

CCPM — управление dev-проектом через PRD→эпики→issues. Не является инструментом анализа и брейншторма по реестру узлов. Слишком конкретный execution-инструмент, не аналитический.

Summary: Роутер не определил узел, выполнен direct без цепочки обработки для запроса мозгового штурма

Запрос требовал анализа существующей системы и генерации идей — нужен был узел с доступом к контексту архитектуры и structured brainstorm. Direct без цепочки не обеспечивает системный анализ трёх слоёв

Запросы типа 'проанализируй систему и предложи улучшения по слоям' требуют явного узла с контекстом архитектуры + генерацией идей. Отсутствие роутингового решения — признак недостаточной классификации запроса


Summary: Роутер не определил узел, запрос направлен напрямую без обработки специализированным узлом

Запрос касается архитектуры роутинговой системы — следовало направить к узлу с контекстом о системе или к информационному узлу; нужен fallback-узел для meta-вопросов

Вопросы о самой роутинговой системе требуют специального meta-узла или чёткого fallback; отсутствие рекомендации роутера не должно приводить к пустой цепочке


Summary: Роутер предложил узел #19, но был выбран direct без выполнения цепочки — запрос про фундаментальный пересмотр логики роутинга

Запрос содержит архитектурное предложение о пересмотре награждения роутера — стоило активировать цепочку для анализа и планирования изменений, а не давать прямой ответ

Запросы о фундаментальных изменениях архитектуры системы (особенно с словами 'пересмотрим', 'фундаментальный нюанс') требуют цепочки рассуждений, а не прямого ответа — даже если формулировка неформальная


Explanation: Ни один узел в реестре не описывает паттерн 'роутер + скил для формулировки выхода + судья' как явную цепочку или capability. Запрос отсылает к какой-то внутренней архитектуре системы которую нельзя восстановить из текущей спеки без уточнений.

Superpowers v5.1.0 (writing-plans)

writing-plans sub-skill формулирует планы, но это meta-skill для разработчика, не для роутера; нет упоминания 'судьи' в capabilities

promptfoo

содержит LLM-judge концепцию в eval-сценариях, но не связан с роутером и формулировкой планов

adr-kit

adr-judge проверяет соответствие кода решениям, но это pre-commit job, не связан с роутером и планами

Summary: Роутер не определил узел, выбран direct — запрос о поиске в спецификации навыка роутера для формулировки плана судье

Нужно было активировать узел поиска по документации/спецификации, а не просто direct-ответ. Запрос явно требует поиска в конкретном документе (спеке), роутер должен был направить к инструменту поиска или RAG-узлу

Запросы вида 'найди в спеке' требуют узла с доступом к документации. Если роутер не определил узел — это сигнал о пробеле в покрытии интентов, связанных с поиском по внутренним документам проекта


**План ПРОИЗВОДИТ реальный узел `writing-plans`** (Claude вызывает, level 1 из строки 232), **журнал-проверяемо**, обязательно на риске. У реального узла свой self-review. Роутер не «изображает write-plans», а **критикует** результат реального узла впитанным стандартом.

**Судье-формат (зачем / тег как-сверх / ссылка на §) — МЕХАНИЧЕСКИ обязателен** на плане (код проверяет наличие per-step + `refResolves` уже есть), а не «роутер хорошо отформатировал».

**«Проверяемый исход» подкреплён РЕАЛЬНО, не словом:** на кодовых шагах = настоящий RED→GREEN + мутация + неподделываемый GREEN-сентинел (Машина 5, `tdd-real-test-verifier`). Судья видит формат «проверено»; **реальное доказательство — журнал/сентинел при исполнении, не текст плана.** Слово «проверено» без сентинела → пусто.

Explanation: Запрос не содержит достаточного контекста для однозначной классификации: неясно что такое 'пересмотр', 'проверено/проверенно' и 'судья' в контексте проекта Лидерра. Минимум два возможных толкования (eval LLM-judge vs. что-то внешнее) без возможности выбора без уточнения.

promptfoo

Упоминание 'судьи' может указывать на LLM-judge в promptfoo eval, но запрос слишком неконкретен — нет ни промпта, ни assert, ни конфига eval.

discovery-interview

Запрос требует уточнения контекста, но discovery-interview активируется для feature/system-ориентации, а не для толкования смысла вопроса пользователя.

Superpowers v5.1.0

Нет признаков задачи разработки (bugfix/feature/refactor), к которым применим superpowers.

Summary: Роутер не определил узел, выбран direct для вопроса о юридическом контексте пересмотра

Вопрос касается юридической процедуры и поведения судьи — стоило направить к специализированному узлу для правовых/процессуальных вопросов, если таковой имеется

Вопросы о судебных процедурах и реакции судьи требуют чёткой идентификации домена; роутер должен лучше распознавать юридический контекст даже при разговорной формулировке


Explanation: Запрос явно просит зафиксировать критическое правило в постоянное хранилище проекта. claude-md-management — единственный разрешённый канал изменения CLAUDE.md (capability: 'захват learnings из сессии через revise-claude-md'). Формулировка 'всё рухнет' и 'не забыли' указывает на необходимость немедленного capture с эмоционально-весомой подачей, чтобы правило не было пропущено при создании.

adr-kit

ADR подходит для архитектурных решений с долгим обоснованием. Здесь нужен быстрый capture одного правила в CLAUDE.md, а не полноценный Architecture Decision Record с контекстом/альтернативами/последствиями.

CCPM

CCPM управляет PRD и эпиками — слишком тяжёлый инструмент для фиксации одного критического правила. Нет механизма 'предупреждение нельзя пропустить' внутри этого скила.

Superpowers v5.1.0

Superpowers не является каналом записи в CLAUDE.md. verify-before-completion мог бы проверить факт записи, но сама запись должна идти через #33.

Summary: Роутер не определил узел, выполнен прямой ответ без цепочки обработки

Запрос содержит задачу фиксации правила и переход к основным вопросам — стоило определить узел для структурированного сохранения заметок/правил и управления контекстом сессии

Запросы с явным действием 'запиши/зафиксируй' + эмоциональным акцентом ('чтобы не пропустить') требуют узла с памятью/заметками, а не прямого ответа — роутер должен распознавать императивы фиксации


Summary: Короткий подтверждающий запрос 'ок фиксируй' без контекста — роутер не определил узел, выбран direct

Роутер должен был попытаться интерпретировать команду в контексте предыдущих сообщений сессии или запросить уточнение, а не оставлять узел неопределённым

Короткие команды-подтверждения типа 'ок', 'фиксируй', 'сохрани' требуют анализа контекста сессии для корректного роутинга — без контекста невозможно определить к какому узлу обращаться


Summary: Запрос на git commit и создание промпта для новой сессии направлен в direct без цепочки обработки

Запрос содержит две задачи: выполнение git commit и генерация промпта для передачи контекста. Нужен узел для работы с git и узел для генерации промптов/контекста сессии

Смешанные запросы с императивными командами (commit) и генеративными задачами (написать промпт) требуют декомпозиции и последовательной цепочки узлов, а не прямого ответа


Explanation: Запрос явно требует написания детального TDD-чертежа под-плана 3-A через capability 'writing-plans' из Superpowers #19. Задача — multi-step: прочитать 4 документа-канона, синтезировать информацию, оформить чертёж. Паттерн 5: содержит 'написать чертёж' + ≥3 шагов (чтение канона → анализ контрактов скилов → написание плана с TDD-структурой). Перед сборкой кода — план обязателен.

discovery-interview

Запрос не требует discovery-интервью — владелец уже чётко знает что хочет (чертёж 3-A). Нет неясных требований, которые нужно уточнять через JTBD.

CCPM

CCPM управляет PRD→эпики→issues→код на уровне проекта. Здесь задача — написать детальный TDD-чертёж одного под-плана, а не декомпозировать проект. writing-plans из #19 точнее.

Pest 4

Pest — PHP-тестовый фреймворк. Тесты здесь на vitest (JS), и текущая задача — написать ПЛАН, а не сами тесты. TDD-сборка начнётся только после слова владельца.

Summary: File content (26414 tokens) exceeds maximum allowed tokens (25000). Use offset a

Summary: Запрос с кодовой фразой и сложными инструкциями направлен в direct без активации каких-либо узлов цепочки

Запрос явно требует чтения файлов (Read) и написания TDD-чертежа — это задача для узла типа 'planning' или 'feature'. Direct не отражает реальную природу задачи. Роутер должен был определить узел.

Длинные инструкционные промпты с кодовыми фразами и явными задачами (чтение файлов, составление плана) должны маршрутизироваться в специализированные узлы, а не в direct. Отсутствие определённого узла — сигнал сбоя роутинга.


Summary: No routing tag present; observer requested explicit routing annotation for user-directed node 'writing-plans'

Should have included the routing comment tag as instructed, and the router failed to determine a recommended node — routing logic needs to handle observer stop-hook feedback properly

When observer stop-hook requests a routing annotation, the system must emit the required comment tag and the router should always resolve to a concrete node, even under user-directed conditions


Explanation: Запрос требует построчной проверки актуальности 26 хуков относительно текущей кодовой базы и спецификации. #86 (graphifyy) строит knowledge-graph всего портала (docs+config+code) и умеет делать cross-layer query 'где используется X', что позволяет системно найти все 26 хуков и сопоставить их с правками. После картирования #19 (Superpowers) через superpowers:systematic-debugging проводит построчный audit каждого хука: сигнатура → capability → актуальный спек. Это многошаговая задача с risk пропустить расхождение — именно поэтому chain, а не single skill.

Superpowers v5.1.0

Superpowers:systematic-debugging может провести аудит, но без предварительного структурного картирования из #86 рискует пропустить хуки в нестандартных путях или устаревшие регистрации — нарушено требование 'построчно без фантазий'.

claude-md-management

Управляет только CLAUDE.md. Хуки (PreToolUse/PostToolUse/Stop/UserPromptSubmit) живут в .claude/hooks/ и settings, а не в CLAUDE.md — неправильный scope.

hookify

hookify генерирует новые хуки и проверяет коллизии при создании, но не предназначен для аудита существующих 26 хуков на актуальность относительно спека. Триггер только по явному /hookify.

Summary: Роутер не определил узел, выбран direct — вероятно корректно для задачи верификации документации

Роутер должен был определить узел для задачи code-review/verification. Отсутствие routing-решения — признак неполноты правил или недостаточного контекста запроса

Запросы на построчную верификацию артефактов (хуки, спеки) требуют явного узла типа 'review' или 'verification'. Нужно добавить паттерны для таких задач в routing-правила


Explanation: Запрос является неполным речевым актом без описания задачи, системы, ожидаемого или фактического поведения. Ни один узел реестра не имеет capability, покрывающей 'повторить вопрос ассистента'. Паттерн 2 (discovery) применён: запрос допускает минимум три интерпретации без возможности однозначного выбора.

discovery-interview

Могло бы быть релевантно, если пользователь находится внутри discovery-сессии и просит повторить вопрос интервью, но контекст полностью отсутствует — невозможно подтвердить.

Superpowers v5.1.0

Нет признаков задачи разработки, планирования или отладки — не применимо.

Playwright MCP

Нет ни одного триггера: ни скриншотов, ни HTML-прототипов, ни взаимодействия с браузером.

Summary: Пустой запрос 'ещё раз твой вопрос' не был распознан роутером, направлен в direct без цепочки

Роутер должен был запросить уточнение контекста или вернуть предыдущий вопрос из истории сессии

Запросы типа 'повтори' или 'ещё раз' требуют доступа к истории диалога; роутер должен уметь обрабатывать такие мета-запросы


Summary: Короткий неясный запрос без контекста, роутер не определил узел, выбран direct

Необходим контекст предыдущего диалога для корректного роутинга; запрос 'вноси и фиксируй' предполагает продолжение задачи — нужно анализировать историю сессии

Короткие контекстно-зависимые команды требуют анализа предшествующего диалога; при отсутствии контекста следует запрашивать уточнение вместо fallback на direct


Summary: PreToolUse:Bash hook error: [node tools/enforce-router-gate.mjs]: [router-gate]

Summary:
Exit code 1

 RUN  v4.1.8 c:/моя/проекты/портал crm/Документация/.claude/worktre

Summary:
Exit code 1

 RUN  v4.1.8 C:/моя/проекты/портал crm/Документация/.claude/worktre

Summary: Роутер не определил узел, фактически выбран writing-plans для неясного запроса 'машину 3'

Нужно было запросить контекст: что такое 'машина 3'? Без контекста предыдущих сессий выбор узла случаен. Следовало либо найти связанный контекст, либо уточнить минимально.

Когда пользователь говорит 'продолжай' без явного контекста в текущей сессии, роутер должен искать контекст в истории или выбирать наиболее универсальный узел, а не оставлять решение неопределённым.


Explanation: Pattern 2: запрос допускает минимум 4 несовместимые интерпретации ('машина 3' может быть кодом, инфрой, процессом или документом). Без уточнения любой выбор узла будет угадыванием. Требуется: (1) что такое 'машина 3', (2) где лежит спека, (3) в каком артефакте проверять соответствие.

Подходит если 'машина 3' — живой код с багом, но запрос звучит как compliance-проверка vs спека, а не отладка конкретного бага. Нет system/expected/actual — Pattern 4 требует уточнения.

graphifyy

Мог бы найти 'машину 3' в knowledge graph и показать связи, но без понимания что такое 'машина 3' — бесполезен. Запрос 'проверь соответствие спеке' не покрывается cross-layer query.

process-analysis

Подходит только если 'машина 3' — это бизнес-процесс в Laravel-коде (routes/jobs/queues). Слишком узкая интерпретация без подтверждения.

Summary: Роутер не определил узел, но был выбран superpowers:brainstorming без контекста о 'машине 3' и спеке

Необходим контекст: что такое 'машина 3', какая спека. Без этого brainstorming — слепой выбор. Нужен узел анализа/верификации, а не генерации идей

Запросы на проверку соответствия спецификации требуют узла верификации/аудита, а не brainstorming. Отсутствие контекста должно триггерить уточняющий запрос перед роутингом


Explanation: Запрос содержит минимум три валидные интерпретации (A/B/C), ни одна не доминирует без уточнения: неизвестно, где физически хранится 'Канон 3-A', являются ли G1–G6 охранными правилами кода, нормативными гард-рейлами CLAUDE.md или архитектурными ограничениями. Согласно ПАТТЕРНУ 2 (discovery-interview), при двух+ интерпретациях без явного указания — не угадывать, вернуть no_skill_found с clarify-вопросами.

claude-md-management

Подходит только если Канон 3-A живёт внутри CLAUDE.md или связанных нормативных файлов; но если документ находится вне CLAUDE.md — #33 не имеет юрисдикции. Неизвестно, где именно хранится 'Канон 3-A'.

normative-sync

Подходит для синхронизации нормативных документов после завершённых интеграций, но не для первичного восстановления отсутствующих определений. Не решает вопрос 'что такое G1–G3/G5–G6'.

graphifyy

Может найти упоминания G1–G6 по всему корпусу docs+code, что помогло бы восстановить определения из контекста. Но это диагностический инструмент, а не решение — и применим только если определения где-то существуют имплицитно.

Summary: Запрос о неопределённых гард-рейлах G1-G3/G5-G6 в Каноне 3-A направлен напрямую без роутинга

Запрос требует анализа документации/спецификации — следовало бы направить к узлу для работы с техдокументацией или кодовой базой, а не просто 'direct'

Запросы о несоответствиях в спецификациях/канонах требуют узла с доступом к документации; пустая цепочка выполнения указывает на сбой роутинга


Explanation: ПАТТЕРН 2 (discovery-interview): запрос допускает минимум три принципиально разные интерпретации того, что такое 'G1–G6 в спеке' и где эта спека находится. Угадывать нельзя — неправильный выбор инструмента даст ложный результат. Требуется уточнение от пользователя по трём осям: тип документа, местонахождение файла, контекст предыдущего обсуждения.

openapi-mcp-server

Подходит только если G1–G6 — секции OpenAPI/REST-спецификации. Нет подтверждения что речь идёт об API-спеке.

graphifyy

Мог бы найти упоминания G1–G6 по всему корпусу docs+code, но без знания типа документа это поиск вслепую. Не решает проблему неопределённости.

GitHub MCP

Подходит если G1–G6 — labels или issues на GitHub. Нет признаков что это GitHub-контекст.

Summary: Роутер не определил узел, запрос отправлен напрямую без обработки

Роутер должен был распознать запрос как аналитическую задачу по восстановлению контекста спецификации и направить к узлу с доступом к истории диалога или документации

Запросы с явными пробелами в спецификации и отсылками к предыдущим обсуждениям требуют узла с контекстом сессии; роутер должен обрабатывать такие паттерны как задачи восстановления/анализа контекста


Summary: Запрос без контекста — роутер не смог определить узел, выбран direct по умолчанию

Необходим анализ предыдущего контекста сессии: 'собери всё в кучу' подразумевает агрегацию ранее обсуждённых данных. Роутер должен учитывать историю диалога и выбирать узел суммаризации или агрегации.

Императивные запросы без явного предмета ('всё', 'это', 'их') требуют обязательного анализа контекста сессии перед роутингом. Отсутствие контекста должно триггерить уточняющий вопрос, а не fallback на direct.


Summary:
Exit code 1
failed to load config from C:\моя\проекты\портал crm\Документац

Summary: PreToolUse:Edit hook error: [node tools/enforce-tdd-real-test-verifier.mjs]: [td

Summary:
<tool_use_error>String to replace not found in file.
String: import { describe,

Summary: Запрос слишком неоднозначен, роутер не смог определить узел, выбран direct по умолчанию

Запрос 'фиксируй и а,в делай' крайне неясен — необходим запрос уточнения у пользователя перед роутингом, а не fallback на direct

При невозможности определить намерение пользователя лучше запросить уточнение, чем молча переходить на direct-узел с низкой уверенностью


Explanation: Запрос содержит критически неопределённые термины: (1) 'машина 1' и 'машина 3' — нет контекста что это (класс, модуль, процесс, документ?); (2) 'спека' — нет ссылки на эталонный документ; (3) 'зафиксируй что отложено' — непонятно куда фиксировать (ADR? GitHub issue? CLAUDE.md?). Согласно ПАТТЕРНУ 2 (discovery-interview): когда запрос можно интерпретировать 3+ способами — не угадывать, вернуть no_skill_found с clarification-запросом.

Superpowers v5.1.0 — brainstorming

Пользователь просит 'запустить брейншторм' — но контекст полностью отсутствует: неизвестно что такое 'машина 1/3', нет спеки-эталона, нет файлов. Brainstorming без контекста создаст 'призраков', что пользователь явно запрещает ('без призраков, не фантазируй'). До прояснения контекста — неприменимо.

process-analysis

Если 'машина' — это бизнес-процесс/workflow, то process-analysis (#53) мог бы сделать discovery из кода Laravel. Но без подтверждения что 'машина' = процесс и без указания где лежит спека — преждевременно.

graphifyy

Если 'машина 1' — это модуль/слой кода, graphifyy мог бы построить knowledge-graph и найти связи. Но запрос 'проверь соответствие спеке' требует наличия эталонного документа — graphifyy не умеет валидировать код против PRD/спеки.

Summary: Роутер не определил узел, система выбрала direct для анализа соответствия машины 1 спецификации

Роутер должен был определить узел для аналитической задачи — проверки кода/логики на соответствие спеке. Подошёл бы узел для code review или анализа. Direct без цепочки означает потерю структурированного подхода к брейнштормингу и построчной проверке.

Запросы вида 'проверь построчно по факту', 'брейншторм', 'соответствие спеке' — сигналы для аналитического узла с возможностью итеративной проверки. Отсутствие роутингового решения при таких запросах — сбой классификации намерения.


Summary: Роутер не определил узел, выбран direct для вопроса о незакрытых задачах по машине 1

Роутер должен был распознать контекстуальный вопрос об отложенных задачах и направить к узлу с историей сессии или task-tracking

Вопросы о 'хвостах' и отложенных задачах требуют доступа к контексту предыдущих решений — нужен узел для работы с историей и backlog-ом


Summary: Неполный запрос 'фиксируй и исправь в' без указания объекта — роутинг завершился в direct без действий

Следовало запросить уточнение у пользователя: что именно нужно исправить и где. Узел #18 был рекомендован, но direct выбран без обработки.

При обрезанных или незавершённых запросах лучше активировать узел уточнения контекста, а не падать в direct с пустой цепочкой.


Superpowers v5.1.0 (brainstorming)

Запрос содержит слово 'брейншторм', но объект брейнштормига полностью не определён — невозможно запустить brainstorming без темы

discovery-interview

Запрос требует discovery-уточнения, но это задача для пользователя (clarify), а не для запуска интервью-скила

openapi-mcp-server

Если 'спека' = OpenAPI, то этот скил подошёл бы, но объект 'машина 1/2' и тип спеки не установлены

Summary: Роутер не определил узел, система упала на direct без цепочки обработки

Запрос требовал анализа кода/спецификации с брейнштормингом — нужен был узел типа code_review или analysis с контекстом предыдущей сессии

Когда запрос содержит технический анализ ('проверь построчно', 'соответствует спеке') с эмоциональным давлением, роутер должен уверенно выбирать аналитический узел, а не падать в неопределённость


**T1** `[owner]` — регистрация matcher `*` в `.claude/settings.json` (без неё стена инертна; аналог B1 у M1).

**T2** `[→ M4]` K1 — `freezePlan`/`freezeArtifact` сейчас зовётся кем угодно с ключом; «печатает только гейт-1» — Машина 4.

**T3** `[→ M4]` K2 — покрытие навыком по журналу.

**T4** `[→ M5]` K3 — консервативный `classifyBashCommand` (сейчас безопасен).

**T5** `[→ M3]` волны (дерево step_ptr) — `step-pointer` построен, не вшит.

**T6** `[→ M3 3-D]` K4 узкое Write-исключение — сейчас `decideMode` блокирует Write в разговоре (верно).

**T7** `door-coverage` не вшит в живой прогон/STATUS (утилита есть, surfacing отложен).

**T8** `buildFrozenPlanFromApproval` не построен (опционально; канал печати — M4).

**F1** `[код]` — `actionOf` берёт объект только из 4 полей (`file_path/notebook_path/path/target_file`) — как до фикса B4. Планируемый MCP-write с полем `filename`/`uri` не сматчится → блок. **Fail-closed (безопасно), но рубит легитимный шаг.** Выровнять с расширенным списком B4.

**F2** `[код, защита-в-глубину]` — `decide()` при `artifact_id` проверяет только равенство id, но НЕ печать артефакта (печать проверяет обёртка `decideMode`). Живьём безопасно (вход всегда через `decideMode`), но `decide()` в одиночку обмануть можно. Добавить `verifyImpl(frozenArtifact)` в `decide`.

**F3** `[residual]` — указатель шага `plan-step-<sess>` не подписан; целостность держится на `runtime-write-deny` (пол). Приемлемо, отметить.

Explanation: Запрос использует внутреннюю нотацию проекта ('B3', 'Машина 2', 'подписанная пара файлов журнал') которая не распознаётся ни одним зарегистрированным скилом. PATTERN 2 (discovery-interview): минимум 3 валидные интерпретации (ADR vs threat-model vs feature), ни одна не доминирует без контекста. no_skill_found=true до прояснения.

adr-kit

ADR подходит если цель — зафиксировать архитектурное решение об anti-rollback механизме, но запрос звучит как вопрос 'учёл ли?', а не 'зафикси решение' — непонятно, нужен ли ADR или что-то иное

threat-model

Rollback к старой подписанной паре — это STRIDE Tampering/Repudiation угроза, но запрос не содержит явного 'смоделируй угрозы' и не упоминает going-public контекст

billing-audit

Монотонный счётчик/high-water-mark может касаться идемпотентности биллинга, но 'B3', 'Машина 2', 'подписанная пара файлов' — явно не биллинговая терминология проекта

Summary: Запрос про анти-rollback механизм для B3 не был роутирован — выбран direct без цепочки

Запрос содержит специфический технический контекст (rollback-защита, монотонный счётчик, high-water-mark, подписанные пары файлов) — требовал экспертного узла или хотя бы узла анализа безопасности/архитектуры, а не прямого ответа

Запросы с терминами безопасности (anti-rollback, high-water-mark, signed pairs) следует направлять в специализированный узел безопасности или архитектуры, даже если синтаксис запроса фрагментарен и неформален


Summary: Пользователь просит переписать текст по-человечески, роутер не определил узел, выбран direct

Роутер должен был определить узел для задачи переформулирования/упрощения текста. Неясно, какой именно текст нужно переписать — запрос неполный, следовало запросить уточнение.

Запросы на упрощение или переписывание текста без самого текста требуют уточнения. Роутер должен распознавать задачи редактирования/перефразирования и маршрутизировать их в соответствующий узел.


Summary: Роутер не смог определить узел для оценки риска/призрачности, запрос отправлен напрямую без цепочки

Запрос слишком неоднозначен без контекста — неясно, что именно оценивать. Роутер должен был запросить уточнение или выбрать узел анализа рисков

Абстрактные запросы без объекта оценки ('этого варианта') требуют либо запроса контекста, либо маршрутизации в узел уточнения намерений