claude-md-management

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

discovery-interview

Мог бы помочь прояснить запрос через structured interview, но сам по себе не 'переписывает' документы — нужно сначала понять объект

Отдаёт документацию библиотек, не переписывает тексты на русском

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

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

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


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

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

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


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

product-management

Отклонён: запрос не описывает продуктовую задачу — нет объекта (фича, спека, роадмап), нет критериев выбора варианта.

discovery-interview

Частично подходит (ПАТТЕРН 2): запрос ambiguous и требует discovery-интервью. Но даже для запуска discovery-interview нужен минимальный контекст домена — его нет.

Superpowers v5.1.0 (brainstorming)

Отклонён: brainstorming требует чёткой проблемы или домена. Без контекста невозможно сгенерировать осмысленные варианты — результат будет случайным.

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

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

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


C:\моя\проекты\портал crm\Документация\docs\observer\STATUS.md

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

Summary: Запрос на проверку логов мозга направлен в direct вместо узла #25

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

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


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

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

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


Explanation: Запрос описывает дефект LLM-классификатора (собственного, судя по контексту): в ~50% случаев он не может разобрать собственный ответ. Это классический bugfix с неполным описанием: есть system (LLM-классификатор) и actual (не разбирает ответ в ~50% случаев), но нет явного expected и не указан конкретный механизм сбоя. ПАТТЕРН 4 предписывает superpowers:systematic-debugging (#19) — он сам запросит прояснение system/expected/actual. ПАТТЕРН 6 расширяет до chain: после диагностики нужен regression-тест через Pest #18, чтобы зафиксировать воспроизводимый сценарий разбора ответа (парсинг JSON/text,

promptfoo

promptfoo покрывает eval и регрессионное тестирование LLM-промптов, что релевантно для финальной проверки после фикса. Однако запрос звучит как 'копай' — диагностика первопричины, а не запуск eval-сюиты. Кроме того, не ясно, есть ли уже набор ассертов. Подходит как третий шаг после systematic-debugging + Pest, но не как стартовый.

Sentry MCP

ПАТТЕРН 7 требует Sentry когда есть явное упоминание продакшн-ошибки ('в проде', 'клиент сообщил', 'в логах'). Здесь этого нет — речь идёт о самом классификаторе как артефакте, а не о production runtime. Sentry не поможет разобрать логику парсинга ответа LLM.

Data Scientist skill

Упоминание '~50% случаев' может навести на мысль о статистическом анализе, но задача не ML-воркфлоу. Это инженерный дефект (парсинг/формат ответа), а не проблема распределения данных или модельных метрик. Data Scientist не имеет capability для отладки кода классификатора.

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

Роутер должен был распознать паттерн 'LLM не может разобрать собственный ответ' как классическую задачу отладки и сразу направить к debugging-узлу без неопределённости

Запросы с глаголом 'копай' и описанием нестабильного поведения системы (~50% failures) однозначно указывают на systematic-debugging; роутер должен улавливать эти сигналы раньше


Explanation: Запрос не является задачей для CRM-проекта Лидерра. Это мета-вопрос о поведении самого классификатора. Ни один узел реестра не покрывает: (а) интроспекцию истории классификации промтов, (б) подсчёт ошибок truncation из логов сессий, (в) расчёт необходимого расширения context window. Согласно ПАТТЕРНУ 2: запрос интерпретируется тремя разными способами — clarify A vs B vs C обязателен.

graphifyy

graphifyy строит knowledge-graph по коду/доксам проекта, не анализирует историю промтов классификатора и не имеет доступа к логам сессий

skill-creator

skill-creator помогает создать новый скил, но запрос не формулирует явно 'создай новый скил' — он задаёт аналитический вопрос о поведении классификатора

claude-md-management

claude-md-management управляет CLAUDE.md, не системным промтом классификатора; изменение самого классификатора вне его scope

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

Запрос требует анализа данных сессии (статистика ошибок роутинга из-за длины промта) и технической экспертизы — стоило направить в аналитический или диагностический узел

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


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

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

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


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

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

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


**Метрики + дашборд** (сколько лидов через DaData/Россвязь/тег) — **в проекте вообще нет механизма метрик**, это инфраструктурная задача, не быстрый хвост.

**Закоммитить** — оформить 6 аккуратных коммитов (по сессиям). Нужно твоё «добро» на каждый git-шаг (так устроена защита) + по ходу может попросить пару мелких правок (орфография/проверки).

**Авто-ревью кода** — прогнать проверку «нет ли ошибок/недочётов» перед вливанием. Качество.

**Влить ветку в основную (main)** — чтобы фича стала частью проекта, а не отдельной веткой.

**3 чужих падающих теста** (Billing/Incidents/SnapshotBackfill) — они портят друг друга, не моя поломка. Гляну: если чинится за ~15 минут (изоляция) — починю; если глубже — оставлю с пометкой как отдельную задачу.

**Отметить фичу в «мозге»** (CLAUDE.md, короткая запись) — чтобы карта проекта знала про неё.

**Постепенное включение (1% → 100%)** — сейчас рубильник «всё или ничего». Для безопасного запуска нужен «кранчик» на долю лидов. ~полдня.

**Кнопка отката импорта реестра** (`phone-ranges:rollback`) — на случай кривого импорта. ~1-2 часа.

**Маскирование в дампах + полный аудит ПДн/152-ФЗ** — перед боевым запуском, отдельным прогоном.

Нужны **ключи DaData в YC Lockbox** + твоё «запускаем». Дальше по инструкции: миграция → импорт реестра → деплой с выключенным рубильником → smoke → включение. Это операции на боевом, не код.

Summary: Запрос '8 распиши кратко но простым языком' — неполный контекст, роутер выбрал #19, но выполнение пошло напрямую без цепочки

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

Короткие запросы с числами-ссылками ('8') требуют проверки контекста диалога перед роутингом; несовпадение рекомендованного узла и фактического выбора указывает на сбой в исполнении цепочки


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

Запрос слишком неоднозначен: неясно что такое '6' — тема, пункт, глава. Нужно было либо запросить уточнение, либо применить узел #19 как рекомендовано

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


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

Если узел #19 специализирован для self_assessment запросов, его игнорирование могло снизить качество ответа; стоило проверить релевантность #19

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


Explanation: Запрос требует capability 'writing-plans' из Superpowers (#19): нужно создать структурированный промпт для следующей сессии Claude, который: (1) переключает worktree через git-команды, (2) восстанавливает контекст задач из текущей сессии, (3) обеспечивает continuity без потерь. Это multi-step orchestration задача (worktree-setup → context-capture → prompt-generation), которая является прямым применением superpowers:finishing-branch + superpowers:writing-plans.

claude-md-management покрывает только правки CLAUDE.md и capture learnings, но не генерацию произвольных handoff-промптов для следующей сессии с worktree-контекстом

CCPM

CCPM управляет PRD/эпиками/issues, но не занимается session-handoff и worktree-переключением между сессиями

GitHub MCP

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

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

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

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

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


Explanation: Запрос — классический пример многоэтапной задачи без чёткого ТЗ: пользователь не знает с чего начать, задача требует discovery → планирование → дизайн → копирайт → маркетинг → реализация → QA. Это прямой триггер для цепочки L1 (feature discovery & implementation), расширенной доменными скилами лендинга. Один скил здесь невозможен — нет ни артефакта, ни чёткого глагола-действия.

CCPM управляет dev-проектом через PRD→эпики→issues, но не проводит discovery и не имеет маркетинговых/дизайн-компетенций. Полезен позже — для трекинга задач после планирования.

Закрывает РФ-специфику (Яндекс.Директ, ВК, конверсия лендинга), но это специализация, а не точка входа. Должен активироваться внутри шага #74, не первым в цепочке.

Дизайн-критика и UX-копирайт нужны, но это 4-й шаг, не первый. Без discovery и маркетингового оффера дизайн-критика не имеет критериев оценки.

Summary: Роутер не смог определить узел для сложного многодисциплинарного запроса о создании лендинга

Запрос явно требовал мультиагентного подхода: декомпозиция задачи, затем параллельное привлечение навыков дизайна, копирайтинга, маркетинга, верстки. Роутер должен был распознать мета-запрос (объяснение системы) и ответить описанием своей логики, а не молчать

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


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

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

Вопросы о процедурах работы с сессиями следует направлять в специализированный узел для мета-запросов или help-узел, а не оставлять без маршрутизации


Но как только ты пишешь снова — он **запускается заново** и переоценивает. То есть в длинном диалоге он работает не «один раз на весь проект», а «один раз на каждую реплику», и его подсказка **сдвигается вперёд по ходу работы.**

Классификатор срабатывает **один раз на каждое ТВОЁ сообщение.** Написал промпт → он один раз подобрал тип задачи и подсказал скил/цепочку → дальше молчит **до твоего следующего сообщения.** Внутри одного моего ответа он себя не передёргивает.

И главное: классификатор только **советует.** Саму цепочку скилов исполняю **я** — это я вызываю скилы по очереди. Он не «дирижёр», он «штурман, который на каждой развилке говорит, куда дальше».

`discovery-interview` — берёт интервью у **тебя**: кто клиент, в чём оффер, что значит «продающий», что обязательно на странице. Раз ты не дизайнер/маркетолог — скил сам вытащит требования из тебя вопросами.

`brainstorming` — раскладываем подходы: структура, акценты, 3 варианта концепции, а не один наугад.

`writing-plans` — выбранную концепцию превращаем в конкретный пошаговый план (что, в каком порядке, чем делаем).

`marketing` + `brand-voice` + `marketing-ru` — позиционирование, продающий текст, единый тон Лидерры, РФ-специфика.

`Design plugin` + `Frontend Design` — дизайн/UX, макет, эстетика (строго в рамках брендбука Forest — палитра/шрифты не на усмотрение плагина).

`Frontend Design` + Vue/Vuetify — собственно сборка страницы.

`Pa11y` — проверка доступности.

На **первом** твоём сообщении он, скорее всего, скажет: «это крупная фича / неоднозначно → начни с разбора и плана» (то есть укажет на `discovery-interview` / `brainstorming` / `writing-plans`), а **не** на «#19 coder».

По мере диалога (ты ответил на вопросы → выбрали концепцию → пошли делать) **каждое твоё следующее сообщение** он классифицирует заново, и подсказка едет дальше по конвейеру: разбор → план → конкретный домен (текст / дизайн / сборка).

Сам «веер» на маркетинг/дизайн/фронт раскрывают **процессные скилы** (brainstorming → writing-plans → выполнение), а не классификатор в одиночку.

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

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

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


Покрывает только GitHub issues/PR-хвосты, но не нормативные или технические долги — слишком узко для размытого запроса

normative-sync

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

CCPM

Управление проектными эпиками/issues — возможная интерпретация, но без уточнения 'проект дисциплины' неясно что именно собирать

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

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

Запросы типа 'собери хвосты/итоги по проекту' должны роутиться к агенту-аналитику контекста или memory-агенту, а не в direct


**Рекомендованная цепочка на реальном действии** — хук меня **заблокирует**, если я её не выполнил И не написал вслух причину отказа (`chain-override: …`). То есть отклониться можно, но **с обязательным обоснованием, и это пишется в лог.**

**Совет по типу задачи** — могу проигнорировать свободно.

**Судья и жёсткие правила** — **вообще не обойти** (или только владелец рубильником).

Пока ты **подробно описываешь** задачу (как сейчас, целым абзацем) — классификатор богат на слова и выдаёт осмысленную цепочку (тот самый #55→#19→#74→#30→#32). Тут он полезен.

Как только пойдут **короткие реплики** («делай», «дальше», «ок») — он слепнет. И тогда цепочку дизайнер/копирайтер/программист тащит **не он**, а: **я (помню разговор) + написанный план.**

Explanation: Запрос содержит минимум три возможные интерпретации (A/B/C выше) и не имеет ни одного однозначного технического триггера. ПАТТЕРН 2 (discovery-interview): когда запрос интерпретируется двумя+ способами — не угадывать, вернуть no_skill_found с clarification.

adr-kit

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

claude-md-management

Принцип 'классификатор → enforcement → оценщик' мог бы быть зафиксирован в CLAUDE.md, но пользователь не просил этого явно — он выражает недовольство и предлагает концепцию.

product-management

Это может быть продуктовый feedback о governance-архитектуре системы, требующий /write-spec, но задача не сформулирована в виде продуктового артефакта.

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

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

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


**Merge PR #29** — когда a11y станет зелёным. Это оживит Z/F/G на main для **всех** сессий.

**Зарегистрировать `enforce-runtime-write-deny.mjs`** в settings.json (PreToolUse Edit|Write|MultiEdit|NotebookEdit) — иначе **Z Часть 1 (защита транскриптов) инертна**.

**Добавить `enforce-parallel-session-lock.mjs` в `SessionEnd`** (пункт C) — надёжный release замка.

**Результат re-run a11y** на Node 22 — я его не видел (зелёный/красный?).

**F (event.cwd)** — что `event.cwd` стабильнее `process.cwd()`, документацией не подтверждено; фикс «не хуже», полная проверка — наблюдением после merge.

**Замок прямо сейчас** меня блокирует от сессии `435ab498` — это либо реальная вторая сессия, либо та самая cross-worktree коллизия (F её чинит, но F ещё не на main).

Explanation: Запрос состоит из двух шагов: (1) сформулировать handoff-промпт для следующей сессии — это capture learnings / session handoff, покрывается claude-md-management (#33) через revise-claude-md / session-capture capability; (2) корректно закрыть текущую сессию без потерь — покрывается Superpowers #19 через superpowers:finishing-branch + verify-before-completion. ПАТТЕРН 3: два явных глагола ('напиши' + 'закрой') → chain ≥2 узлов.

Superpowers v5.1.0

Покрывает только шаг 2 (finishing-branch, verify-before-completion), но не имеет специализированного канала для генерации handoff-промпта следующей сессии. Один узел недостаточен.

GitHub MCP

Мог бы помочь зафиксировать незакрытые issues/PR, но не генерирует промпт для следующей сессии и не управляет закрытием Claude-сессии.

CCPM

Управляет артефактами PRD/эпиков/issues, но не предназначен для session handoff или генерации промптов перехода между сессиями.

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

Следовало использовать chain: сначала сгенерировать промпт для следующей сессии, затем корректно завершить текущую с сохранением контекста

Запросы с несколькими последовательными действиями (написать + закрыть) требуют chain-обработки; игнорирование рекомендации роутера ведёт к потере задач пользователя


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

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

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


**Перенос состояния вперёд.** Уже есть зачаток (он умеет ловить «продолжаем/отмена»). Расширить: незакрытая задача и её цепочка **наследуются** на короткие реплики.

**Якорь на план-файл (самый надёжный).** Когда мы через `writing-plans` записали план большой задачи — классификатор читает **«текущий шаг активного плана»** и маршрутизирует под него. Тогда «делай» = «делаю шаг 3 плана лендинга», а не пустое слово. Плюс: план переживает даже сжатие моего контекста — это **долговременная память**, которой слепой модели как раз и не хватает.

**Краткая сводка диалога.** Давать классификатору не только последнее сообщение, а пару строк «о чём речь + на каком этапе». Тогда «делай» он трактует в контексте.

**Намерение сессии.** Когда ты описал большую задачу — фиксируется «намерение», и короткие «делай/дальше/ок» решаются **относительно него**, а не с нуля.

**Сначала** — научить классификатор контексту (план/намерение).

**Потом** — затянуть дисциплину (судья проверяет послушание).

**Параллельно** — замкнуть петлю оценщик → правка классификатора.

Explanation: Сообщение содержит два элемента: (1) директиву 'не делаем пункт 3' — это instruction, не задача; (2) вопрос о механике классификатора (до/после writing-plans). Оба элемента являются conversational/meta, должны обрабатываться до классификатора. Ни один skill из реестра не покрывает ответы на вопросы о самом классификаторе.

Superpowers v5.1.0 (writing-plans)

Запрос не просит написать план — он спрашивает о том, как работает механика writing-plans. Это мета-вопрос, не задача разработки.

discovery-interview

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

adr-kit

Не запрашивается архитектурное решение для записи в ADR — это оперативный вопрос о поведении системы.

Summary: Запрос на уточнение логики работы системы — до/после написания плана. Выбран direct без цепочки.

Роутер не определил узел, что привело к fallback на direct. Стоило классифицировать как meta/clarification запрос и возможно подключить контекст предыдущей сессии для точного ответа.

Вопросы о внутренней логике системы (рефлексивные/мета-запросы) должны явно распознаваться роутером и направляться в специализированный узел, а не в direct по умолчанию.


Explanation: Запрос является чистым conversation-сообщением: пользователь фиксирует наблюдение и просит 'ничего не делать, давай дальше рассуждать'. Обработка должна произойти до классификатора (conversation-слой). Ни один скил не активируется.

Superpowers v5.1.0 — writing-plans

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

CCPM

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

discovery-interview

discovery-interview мог бы структурировать неопределённость, но здесь нет ambiguity о фиче — есть чёткое опасение о методе работы. Интервью излишне.

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

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

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


Следовало определить узел для объяснения схемы простым языком — например, 'explain' или 'educational' узел с адаптацией под нетехнического пользователя

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


git commit -m "docs(claude-md): v2.45 — lead region resolution feature note (§6/§9)" -- CLAUDE.md

Стоп — не коммитить

c:\моя\проекты\портал crm\Документация\CLAUDE.md

Explanation: Задача — довести готовую зелёную фичу до merge без хвостов. Это классический superpowers:finishing-a-development-branch + requesting-code-review флоу (#19). Pest #18 нужен явно для шага A (прогон регрессии 101 passed) и F (изоляция чужих падающих тестов). GitHub MCP #3 покрывает шаги B и D — атомарные коммиты с гейтами и влитие ветки в main. claude-md-management #33 закрывает шаг G (§6 запись о фиче). Шаги C (code review) и E (правка runbook) выполняются инструментами superpowers (#19) и прямым Edit соответственно. Паттерн 3 (multi-step): 7 явных шагов A–G с зависимостями → chain ≥2. Паттерн 5

Superpowers v5.1.0 (solo)

Superpowers сам по себе не вызывает Pest и GitHub MCP напрямую — без явного указания #18 и #3 в цепочке оркестровка неполна: регрессия и коммиты останутся на усмотрение агента без конкретных инструментов

CCPM

CCPM ориентирован на PRD→эпики→issues, то есть на старт новой задачи. Здесь задача УЖЕ реализована и нужен finishing-флоу, а не project-management scaffolding

normative-sync

Нормативный синк (Pravila/PSR_v1/CLAUDE.md cross-refs) явно отмечен как НЕ нужный: шаг G — только §6 app-фича запись, §0 cross-refs не трогать. normative-sync избыточен и опасен риском случайного затронуть §0

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

Для задачи редактирования файла с конкретными инструкциями и ограничениями (не коммитить лишние файлы, не пушить) мог быть полезен специализированный узел file-editing или docs-update с проверкой git status перед коммитом

Задачи обновления CLAUDE.md с явными git-ограничениями (staged files из параллельной сессии) требуют осторожного узла с проверкой окружения; direct подходит, но стоит логировать подобные случаи как требующие git-aware обработки


Разобрать требования      → [интервьюер]        ✅ сделано

Текст и позиционирование  → [маркетолог + копирайтер бренда]

Дизайн страницы           → [дизайнер]

Собрать на сайте          → [программист-сборщик]

Проверить доступность     → [Pa11y]

Юр. футер / политика      → [нет специалиста]  ПРИЧИНА: ждём текст юриста, вставим вручную

Дизайн страницы           → [дизайнер]

Explanation: PATTERN 2: запрос содержит минимум три интерпретации (A: образовательный текст про роутер/классификатор; B: переписать конкретный план/документ; C: архитектурный вопрос про динамическую инжекцию скилов в цепочку). Ни один узел не может быть выбран без уточнения целевого артефакта и контекста 'действие 2/4' — эти метки указывают на существующий документ/план, который не предоставлен.

Superpowers v5.1.0 (writing-plans)

writing-plans подходит если нужно переписать план с ≥3 шагами, но неясно какой именно артефакт является целью переписывания — без этого нельзя построить chain

discovery-interview

запрос содержит два концептуальных вопроса (роутер vs классификатор; динамический скил в mid-chain) — это сигнал PATTERN 2, нужно уточнение контекста перед любым действием

CCPM

CCPM управляет PRD→эпики→issues, но запрос не про создание нового проекта — он про переосмысление концепции роутинга/плана; не подходит без уточнения артефакта

Summary: Запрос на переработку объяснения с учётом двух уточнений; роутер не определил узел, выбран direct

Роутер мог бы явно определить узел типа 'educator' или 'explainer' — запрос концептуальный, требует объяснения и переформулировки, а не генерации контента или кода

Запросы с 'перепиши заново' + концептуальные уточнения — это задача для специализированного узла-объяснителя, а не просто direct; стоит добавить паттерн распознавания образовательно-уточняющих запросов


Текст и позиционирование  → [маркетолог + копирайтер]

Дизайн страницы           → [дизайнер]

Проверить доступность     → [Pa11y]

Юр. футер / политика      → [нет специалиста]  ПРИЧИНА: ждём текст юриста

Дизайн страницы           → [дизайнер]

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

Следовало направить запрос через узел #19, если он отвечает за объяснение архитектуры планировщика; прямой ответ без цепочки лишает пользователя структурированного объяснения

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


Superpowers writing-plans

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

discovery-interview

Это не discovery фичи — это мета-диалог об архитектуре роутера и поведении скилов

claude-md-management

Обсуждение ещё не завершено, фиксировать нечего

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

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

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


Explanation: Запрос — открытое design-размышление о пайплайне классификатора (глубина writing-plans, замена родительского скила когда подплан не нужен). Ни один узел реестра не покрывает мета-рефлексию над routing-логикой как задачу. ПАТТЕРН 2: два+ способа интерпретации (нормативная правка vs новый скил vs просто разговор) — не угадываем, требуем уточнения.

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

skill-creator

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

Superpowers writing-plans

Сам writing-plans и есть предмет вопроса — использовать его для ответа на вопрос о нём самом — circular, не подходит

Summary:
<tool_use_error>String to replace not found in file.
String:   Поэтому: **план н

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

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

Запросы вида 'думаем дальше' о внутренней архитектуре системы планирования требуют специализированного узла для метa-обсуждений, если он существует; иначе direct — приемлемый fallback


C:\моя\проекты\портал crm\Документация\tools\llm-judge-per-tool.mjs

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

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

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


**YES** → пропускает. **NO или сомнение** → **блокирует.**

Безобидное чтение (`git status`, `git log`, `grep`) и прогон тестов он **не трогает** (мы это откалибровали).

Я внутри нерасписанного шага «Дизайн» полез делать анимацию (это работа моушн-специалиста, а шагу назначен дизайнер).

Судья видит: **действие не похоже на специалиста этого шага** → **NO** → **блок.**

Я **обязан остановиться** → роутер переназначает специалиста на эту под-задачу → если такого специалиста нет, **всплывает к тебе** (D3).

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

Это всё равно **вызов модели на действие** → деньги + риск **ложных блокировок** (ты уже видел, как судья тормозил безобидный `git status` — расширение добавит таких рисков, теперь он может ошибочно решить «действие не от того специалиста»).

**Сам судья — тоже LLM**, он может неверно распознать «область» действия.

Всё упирается в **качество эталона**: если шаг плохо описан или роутер назначил не того специалиста — судья честно сверит с **кривой** линейкой и пропустит/заблокирует неправильно.

Explanation: Запрос описывает многошаговую архитектурную концепцию: (1) writing-plans (#19 superpowers:writing-plans) — формализовать план-протокол 'prompt → plan → router → judge → execute'; (2) CCPM (#41) — структурировать эпики и issues для реализации этого pipeline (plan-gate, router-integration, judge-enforcer); (3) product-management (#42) — написать спецификацию нового governance-слоя. Паттерн 5 сработал: задача явно ≥3 шагов, содержит 'переосмысли', 'расписать', 'подумаем', требует проектирования нового механизма контроля исполнения. Точечный подход явно отклонён самим пользователем в п.1.

discovery-interview

Запрос достаточно конкретен в своей идее (plan-gate + router + judge). Discovery уместен для неопределённых хотелок, здесь же пользователь сам ведёт discovery вслух и просит помочь структурировать. Дублировал бы усилие.

adr-kit

ADR нужен ПОСЛЕ того как архитектурное решение принято и оформлено. Сейчас идёт стадия проектирования самого механизма — сначала plan/spec, потом ADR как артефакт фиксации решения.

Superpowers writing-plans only (single)

Только writing-plans без CCPM и product-management даст план без структуры хранения артефактов (.claude/prds/, epics) и без спецификации нового governance-протокола. Паттерн 3: задача явно multi-step, chain обязателен.

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

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

Когда пользователь описывает многоуровневую архитектуру системы (plan→router→judge→executor), это задача для structured reasoning, а не просто conversational direct. Роутер должен распознавать мета-обсуждения о самой системе роутинга как особый класс запросов.


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

claude-md-management

Запрос затрагивает правило 'всегда начинать с чтения графа' — это потенциальный CLAUDE.md-инвариант, но пока не ясно, дошли ли до финального решения, которое нужно зафиксировать

skill-creator

Описанная логика (write-plan → чтение файлов → роутер → цепочка) звучит как новый скил или суперсила, но запрос ещё в фазе обсуждения, артефакт не заказан

hookify

Поведение 'судья пропускает чтение файлов' — это потенциальный PreToolUse-хук, но hookify активируется только по явному /hookify, не по описанию желаемого поведения

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

Запрос содержит архитектурное обсуждение workflow: план → чтение графа → роутинг. Стоило распознать intent как design/discussion и направить в узел для диалога или planning-узел, а не просто direct без цепочки

Когда пользователь обсуждает саму архитектуру роутинга и flow скиллов — это мета-запрос о системе. Нужно уметь распознавать такие запросы и либо маршрутизировать в discussion-узел, либо явно фиксировать как planning-сессию с сохранением контекста вопроса


`writing-plans` — чистый (только планирует, не читает)? **(да/нет)**

Ритм «план-разведка → план-дела» как норма? **(да/нет)**

Семя одно (`writing-plans`) или два (+вопрос владельцу)? **(1/2)**

Контекст запроса слишком фрагментарен — ответы '1.да 2.да 3.да' без предшествующего диалога делают оценку невозможной. Нужен полный контекст сессии для валидной оценки роутинга

Для оценки роутинговых решений необходим полный контекст диалога, а не только последний фрагмент. Фрагментарные запросы типа 'да/да/да' без истории — признак mid-session роутинга, требующего особой логики


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

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

Фразы типа 'давай посмотрим на примере' сигнализируют о запросе демонстрации/объяснения — нужно маппить на соответствующий узел, а не оставлять неопределённым


Explanation: Ни один скил в реестре не имеет capability 'аудит логики классификатора' или 'защита от adversarial prompt routing'. Запрос честно диагностирует реальную уязвимость: роутер работает на поверхностном matching и не выполняет принудительную декомпозицию при no_skill_found. Возврат no_skill_found с конкретными рекомендациями по патчу паттернов роутера — единственный честный ответ.

promptfoo

promptfoo покрывает eval и регрессионное тестирование промптов роутера, но не отвечает на вопрос 'как защититься прямо сейчас' — это инструмент для CI-тестирования, а не для архитектурного решения проблемы

skill-creator

skill-creator мог бы помочь оформить 'decomposition-guard' как новый скил с eval-набором, но сам по себе не решает проблему — нужно сначала сформулировать правило, потом его закрепить

discovery-interview

запрос сформулирован достаточно чётко — это не ambiguous discovery-кейс, это конкретный архитектурный вопрос о роутере; discovery здесь избыточен

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

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

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


Explanation: Запрос является мета-разговором ('стоп объясни') о механике классификатора, планов и судьи — это conversation/micro-тип, который должен обрабатываться ДО классификатора. Ни один skill из реестра не закрывает задачу объяснения внутренней логики системы классификации.

Superpowers v5.1.0 (writing-plans)

Запрос про план разработки, но сам запрос — не задание написать план, а вопрос о механике работы плана и судьи. Writing-plans здесь не нужен.

adr-kit

Упоминается 'судья' (adr-judge), но вопрос не про создание ADR и не про enforcement — это мета-вопрос о поведении системы.

discovery-interview

Запрос можно интерпретировать как confusion о процессе — discovery мог бы помочь прояснить, но сам запрос требует прямого ответа, а не интервью.

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

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

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


Необходимо было следовать рекомендации роутера и использовать узел #19; прямой ответ без цепочки может не соответствовать контексту запроса

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


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

Роутер должен был распознать вопрос как meta-вопрос о поведении системы и направить к узлу разъяснения правил или FAQ-узлу, если таковой существует

Вопросы о внутренней логике системы (когда эскалировать, когда нет) требуют отдельного узла или чёткого паттерна распознавания meta-запросов


Это чужая инфра — пусть чинит router-gate

Вы сами выполните npm install

Разобраться глубже

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

Роутер должен обрабатывать пустые/символьные запросы и запрашивать уточнение у пользователя вместо тихого fallback на direct

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


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

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

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


Explanation: Запрос — 'собери всё в кучу, пробегись свежим взглядом, найди разрывы логики, незакрытые дыры, забытые вопросы'. Это классический multi-step synthesis + gap-analysis + brainstorming паттерн. Superpowers #19 покрывает capability: brainstorming (генерация идей/дыр), writing-plans (структурирование выкладки), systematic-debugging (поиск разрывов логики). Ни один single-skill не покрывает все три фазы одновременно.

discovery-interview подходит для структурированного JTBD-интервью перед проектированием фичи. Здесь нет новой фичи — задача синтез и gap-analysis уже накопленного контекста сессии. Режим SYSTEM ближе, но не покрывает brainstorming + gap-поиск.

CCPM

CCPM управляет PRD→эпики→issues→код. Здесь нет задачи создать новый PRD или issue — нужен ретроспективный анализ и синтез. CCPM — инструмент планирования вперёд, а не gap-review назад.

graphifyy

graphifyy силён в structural cross-layer query и поиске orphan-концептов, но сам по себе не генерирует 'список дыр' и не делает brainstorming незакрытых вопросов. Полезен как второй шаг в цепочке после #19, не как первый.

Summary: Роутер не определил узел, система перешла на direct без анализа; запрос требовал синтеза/анализа большого контекста

Следовало выбрать узел для глубокого аналитического синтеза (summarization/analysis agent), а не direct — запрос явно требует агрегации и критического анализа накопленного материала

Запросы типа 'собери всё вместе + найди пробелы' требуют специализированного аналитического узла, а не прямого ответа; роутер должен распознавать паттерн 'synthesis + gap analysis'


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

Нужно было распознать амбигвитет: вопрос может быть о API-ключах (технический контекст) или бытовой метафорой. Следовало уточнить контекст или задать clarifying question

Короткие бытовые фразы без контекста требуют уточнения перед роутингом — 'ключи' может означать API keys, SSH keys или физические ключи, что кардинально меняет обработку


Полный запуск сразу

Поэтапно (рекомендую)
Полный запуск сразу
Только влить в main

Поэтапно (рекомендую)

c:\моя\проекты\портал crm\Документация\.github\workflows\deploy.yml

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

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

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


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

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

Многоточечные запросы вида д1/д2/д3 с ссылками на предыдущий контекст требуют узла с памятью сессии; отсутствие роутинга при неясном контексте лучше решать уточняющим вопросом, а не silent direct


Explanation: Запрос является продолжением диалога с ответами на нумерованные вопросы (д2, д3, д4), но классификатор получает каждый промпт без истории сессии. Без исходного контекста невозможно определить ни задачу, ни подходящий skill. ПАТТЕРН 2: два+ способа интерпретации без возможности выбора.

discovery-interview

Похоже на продолжение discovery-интервью, но без исходного контекста сессии классификатор не может восстановить состояние. Discovery обрабатывается до классификатора как micro/conversation.

Superpowers v5.1.0

Нет явных признаков feature/bugfix/planning задачи — только фрагментарные ответы без объекта работы.

CCPM

Упоминание 'д2/д3/д4' может быть нумерацией пунктов PRD/эпика, но контекст полностью отсутствует для подтверждения.

Summary: Пользователь подтверждает ответы д2/д3/д4 и просит задать забытые вопросы пошагово. Роутер не определил узел, выбран direct.

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

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


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

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

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


**мало** строк (скажем, ≤5),

правка в **одном** файле,

**мало** строк (скажем, ≤5),

**без** новых файлов и **без** запуска команд.

**1** — без исключений, даже опечатка через план (максимум строго, но медленно);

**2 (рекомендую)** — узкий закрытый список мелочи + всё прочее через план;

**3** — свой вариант.

правка в **одном** файле,

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

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

Для однозначных или слишком коротких запросов без контекста лучше запрашивать уточнение, а не применять fallback напрямую


**Дешёвая модель для рутины.** Где ИИ всё же нужен — брать быструю дешёвую модель (типа Haiku), а дорогую — только на по-настоящему рискованное. Полнота не страдает, цена/скорость — резко вниз.

**Сначала бесплатная проверка кодом, ИИ — только на непонятное.** Большинство действий очевидно совпадают с планом (этот файл, этот специалист — есть в текущем шаге). Это проверяет **простая программа за 0 копеек и мгновенно** → пропуск. К **живому ИИ-судье** идут только **спорные/непохожие** случаи. Так покрытие полное (проверяется **каждое** действие), но 90% проверок — бесплатные.

**Кэш.** Похожие проверки внутри сессии переиспользуются (уже частично есть).

**Батчинг чтений** (уже в схеме — список файлов одним планом).

Summary: Пользователь отправил только '2' — роутер не определил узел, выбран direct без цепочки

Следовало запросить уточнение у пользователя, так как одиночная цифра '2' не несёт достаточного контекста для осмысленного роутинга

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


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

Запрос требовал классификации — относится ли навык/MCP-сервер к операциям чтения. Нужен узел для анализа/классификации или clarification-узел для уточнения контекста

Вопросы о классификации инструментов (skill, MCP-сервер) по типу операций (чтение/запись) должны маршрутизироваться к узлу анализа возможностей или clarification, а не оставаться без определённого узла


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

Superpowers v5.1.0 (writing-plans)

Запрос не содержит конкретной фичи или задачи для планирования — нет объекта для writing-plans; это мета-вопрос о самом процессе составления плана

discovery-interview

Частично подходит для прояснения неоднозначности, но запрос слишком короткий и контекст неясен — непонятно, это вопрос о процессе работы ИИ-ассистента или о конкретной задаче в проекте

Не вопрос о документации конкретного SDK/библиотеки; MCP здесь упоминается в контексте workflow-решения, а не как пакет требующий документации

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

Вопрос касается архитектуры системы и поведения роутера — мог бы быть направлен к узлу с мета-знаниями о системе или к planning-узлу для разъяснения приоритетов

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


Summary: PreToolUse:mcp__github__create_or_update_file hook error: [node tools/enforce-mc

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

Роутер мог запросить уточнение контекста: 'готово' к чему? Без контекста невозможно определить намерение пользователя

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


Explanation: Запрос описывает новую фичу классификатора (router расширяется механикой self-nomination + score-gate + escalation). PATTERN 5: задача содержит ≥3 шагов — нужен план перед кодом. PATTERN 2: запрос содержит несколько неуточнённых развилок (кто держит реестр скилов роутера? как роутер узнаёт о новых MCP? что именно эскалируется — весь JSON или краткая выжимка?), поэтому цепочка начинается с #55 discovery-interview для уточнения механики, затем brainstorming для проектирования протокола, затем writing-plans для пошаговой декомпозиции реализации, затем CCPM для трекинга.

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

writing-plans один без предварительного discovery не закроет развилки: непонятно как роутер «узнаёт» новые скилы, какой порог (70% hardcoded?), формат эскалации. Нужен #55 сначала.

claude-md-management

Фича касается логики классификатора, а не документа CLAUDE.md. После реализации — да, возможно потребуется обновить CLAUDE.md, но это не основной инструмент решения.

CCPM (первым в цепочке)

CCPM хорош для трекинга, но если запустить его первым — получим эпик без понимания деталей механики. Правильная позиция — последним после discovery + brainstorming + plan.

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

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

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


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

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

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

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

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

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


Explanation: Запрос описывает системное изменение мета-слоя (роутер + исполнитель + оценщик + эскалация + feedback-loop) — это минимум 4-5 взаимосвязанных решения. По ПАТТЕРНУ 2: когда запрос можно интерпретировать тремя и более способами — не угадываем, возвращаем no_skill_found с конкретными вариантами для уточнения. Выбор неправильного узла здесь дорог — можно начать писать хук когда нужен ADR, или наоборот.

discovery-interview

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

adr-kit

Концепцию стоит зафиксировать как ADR, но сначала нужно понять что именно фиксируем — три открытых вопроса выше не решены, ADR преждевременен

skill-creator

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

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

Роутер должен был определить узел — это разговор об архитектуре системы, подходит узел типа 'planning' или 'dialogue'. Отсутствие роутингового решения само по себе сбой.

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


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

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

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


Superpowers v5.1.0 — writing-plans

Фраза 'только по плану' намекает на writing-plans, но без конкретной задачи неясно что планировать и какие MCP исключать

claude-code-setup

Мог бы рекомендовать настройки разрешений MCP, но запрос не про конфигурацию автоматизации Claude Code

claude-md-management

Возможно просьба зафиксировать правило в CLAUDE.md, но это предположение без явного указания

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

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

Короткие команды с неясным контекстом (МСП, план) требуют либо уточняющего вопроса, либо анализа предыдущего контекста сессии для корректного роутинга


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

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

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


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

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

Короткие неоднозначные фразы типа 'поехали' требуют либо узла уточнения intent, либо conversational-узла, а не прямого прохода без обработки


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

**Пропускать всё** (как сейчас) — я работаю, но защиты ноль.

**Блокировать всё** — защита держится, но при любом чихе API я вообще не могу работать.

Действие, которому **нужно было суждение ИИ** (тонкая оценка «то ли это»), а ИИ лежит → **СТОП**, и два выхода: либо **ждать**, пока ИИ вернётся, либо **эскалация тебе** — «судья недоступен, подтвердишь вручную?». На время сбоя **ты — запасной судья.**

Если упал **роутер** (на этапе планирования) — я не получу разметку специалистов. Тогда либо планирование ждёт ИИ, либо «роутер недоступен — утверди план вручную?» к тебе. На время сбоя ты ещё и **запасной роутер.**

Чтобы код мог «однозначно сверить», план должен быть **точным** (код матчит действие с шагом). Если шаги размыты — код не сверит → всё уйдёт к тебе → при сбое тебя завалит. То есть устойчивость к сбою зависит от точности плана (это связано с Л2).

Это **сложнее в реализации**, чем «пропускай всё» или «блокируй всё». Но это **единственный режим, который и безопасен, и работаем.**

**1** — пропускать всё при сбое ИИ (как сейчас; просто, но дыра);

**2** — блокировать всё мутирующее при сбое (безопасно, но при сбое не работаю);

**3 (рекомендую)** — деградация: код пускает явное-по-плану, неясное → стоп + эскалация тебе как запасному судье (безопасно и работаемо, но сложнее и грузит тебя при сбое);

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

Необходимо понять контекст: это может быть часть диалога о финансах или эмоциональное высказывание. Узел #66 не был использован, цепочка пуста — решение не обосновано

Фрагментарные запросы без контекста (начинающиеся с числа '3') требуют анализа предыдущих сообщений перед роутингом; прямой маршрут без обработки — слабое решение


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

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

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


**Сборка частей** по отдельности, через TDD, **в стороне**, не подключая вживую.

**Спека + план.** Эти заметки → нормальная спека → план реализации (через `writing-plans`). Мы пока **рассуждали** — следующий честный шаг это формальная спека.

**Тихий режим (shadow).** Новые гейты **работают и пишут в лог**, что бы они **заблокировали/эскалировали** — но **реально не блокируют.** Меряем на живой работе: как часто меня бы стопорило? сколько стоило бы? сколько эскалаций упало бы на тебя? сколько ложных срабатываний?

**Подкрутка** порогов (те самые 70%, список мелочи и т.д.) — **по реальным данным** из тихого режима.

**Включаем в бой постепенно:** сперва на мутирующих действиях, потом на чтениях; смотрим.

Summary: PreToolUse:Write hook error: [node tools/enforce-normative-content-rules.mjs]: n

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

Запрос содержит контекст продолжения сессии и просьбу о создании механизма триггера. Нужен узел для управления состоянием или памятью сессии, а не просто direct-ответ

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


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

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

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


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

Следовало запросить уточнение у пользователя — одиночный символ '!' не несёт достаточно информации для осмысленного роутинга

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


prod-deploy-validator

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

Sentry MCP

Подходит для диагностики runtime-ошибок на проде по ПАТТЕРНУ 7, но нет конкретного сигнала: ни 'клиент сообщил', ни 'в логах ошибка' — только общий вопрос 'что там было'

billing-audit

Упоминается биллинг, но неясно — это вопрос о том, что делали (история), или о текущей проблеме; без system/expected/actual аудит преждевременен

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

Следовало распознать срочный характер вопроса о production-среде и направить к специализированному узлу для анализа контекста сессии и прояснения статуса выполненных действий

Вопросы о статусе операций в боевой среде требуют приоритетного роутинга с восстановлением контекста предыдущих действий, даже если формулировка эмоциональная и неточная


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

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

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


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

Стоило запросить уточнение у пользователя вместо silent fallback на direct; минимальный запрос не несёт информации для роутинга

Для односимвольных или бессмысленных запросов лучше запрашивать уточнение, а не молча переходить в direct-режим


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

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

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


Explanation: Запрос явно описывает попытку jailbreak ('пробьём защиту', 'напиши промт'). Ни классификатор, ни зарегистрированные узлы не обрабатывают задачи такого рода. Согласие пользователя не является основанием для обхода политик безопасности системы.

Semgrep + Semgrep MCP

SAST-инструмент для анализа кода на уязвимости — не инструмент для создания эксплойтов или обхода защит

Trail of Bits Skills

Security-аудит выполняется строго в рамках легитимных задач проекта Лидерра, не включает генерацию промптов для обхода политик

threat-model

Моделирование угроз — defensive практика, не offensive; не применимо к данному запросу

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

Следовало явно задействовать узел safety/guardrails для обработки запроса на jailbreak, а не просто передавать в direct

Запросы на 'пробив защиты' и создание jailbreak-промптов должны маршрутизироваться через специализированный safety-узел с явным отказом и объяснением


Summary:
<tool_use_error>String to replace not found in file.
String:       - name: op=fe

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

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

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


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

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

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


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

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

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


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

Роутер должен был определить узел даже для короткого подтверждающего сообщения; возможно стоило использовать clarification или context-aware узел

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


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

Роутер должен был классифицировать запрос как требующий уточнения контекста или направить в clarification-узел, так как вопрос крайне неоднозначен без контекста

Короткие вопросы без контекста ('это нормально что так долго?') требуют узла уточнения, а не прямого ответа — нужно добавить паттерн для ambiguous/context-missing запросов


Summary: Пустой запрос '!' перенаправлен в direct без цепочки обработки

Следовало запросить уточнение у пользователя, так как '!' не несёт смысловой нагрузки и намерение неясно

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


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

Следовало запросить уточнение у пользователя: что именно проверить? Без контекста выбор direct — лишь fallback, не осознанное решение

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


Запускаем на DaData сейчас

Запускаем на DaData сейчас
Сначала загрузим реестр через GitHub

Запускаем на DaData сейчас

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

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


Следовало запросить уточнение у пользователя вместо fallback на direct, либо вернуть сообщение об ошибке неполного запроса

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


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

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

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


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

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

Символ '!' без контекста — потенциальный сигнал о намерении пользователя (восклицание, shell-команда, ошибка ввода). Стоит добавить узел классификации коротких/непонятных запросов для запроса уточнений


Догрузить реестр Россвязи через GitHub

Догрузить реестр Россвязи через GitHub

Зафиксировать запуск в документах/памяти

Другая задача

Догрузить реестр Россвязи через GitHub

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

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

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


Сделать вручную сейчас

Сделать вручную сейчас
Отложить реестр

Сделать вручную сейчас

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

Можно было запросить уточнение у пользователя вместо silent fallback на direct

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


Summary: Запрос на русском с опечатками о 3 прошедших файлах и 1 непрошедшем — роутер не определил узел, выбран direct

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

Короткие сообщения с опечатками и неполным контекстом требуют узла-уточнителя, который задаёт clarifying questions, а не прямого ответа без обработки


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

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

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


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

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

Следовало запросить уточнение у пользователя вместо молчаливого fallback на direct — непонятно, что именно хотел пользователь

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


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

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

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


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

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

При получении минимальных или бессмысленных запросов (один символ, пустая строка) лучше запрашивать уточнение, чем молча выбирать direct


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

Роутер должен обрабатывать невалидные/пустые запросы явно — возвращать ошибку или запрашивать уточнение вместо silent fallback в direct

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


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

Роутер должен обрабатывать неинформативные запросы и запрашивать уточнение вместо молчаливого fallback на direct

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


Explanation: Запрос является micro-conversational ('что мы можем делать ещё') без указания домена, контекста или объекта работы. Ни один узел реестра не имеет capability обработки открытого запроса о возможностях без входных данных. Паттерн 2 (discovery-interview): запрос допускает ≥3 интерпретации — требуется уточнение перед маршрутизацией.

discovery-interview

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

Superpowers v5.1.0

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

CCPM

CCPM управляет dev-проектом и мог бы показать открытые эпики/issues, но для этого нужен явный запрос на ревью backlog

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

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

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


Explanation: Запрос 'делаем по порядку' не содержит ни объекта действия, ни контекста предыдущего шага, ни названия задачи/процесса/фичи. ПАТТЕРН 2 (discovery-interview): три возможных интерпретации — A) продолжение chain из предыдущего сообщения (нет истории), B) старт нового последовательного плана (нет предмета), C) meta-инструкция без actionable содержимого. Ни один узел реестра не может быть активирован без уточнения.

Superpowers v5.1.0

writing-plans/subagent-driven-development могли бы применяться, но нет объекта — неизвестно, план чего строить или какую фичу декомпозировать

CCPM

управление порядком задач в эпике возможно, но нет ни PRD, ни эпика, ни issue — нечего упорядочивать

discovery-interview

запрос можно интерпретировать как минимум тремя способами (A/B/C выше) — ПАТТЕРН 2 требует не угадывать, а запросить уточнение

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

Запросить уточнение у пользователя: что именно делаем и в каком порядке? Без контекста предыдущих шагов невозможно корректно маршрутизировать

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


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

Роутер должен был определить контекст — запрос на поиск ссылки/ресурса требует либо узла поиска, либо узла с доступом к предыдущему контексту сессии

Краткие контекстно-зависимые запросы ('для второго пункта') требуют анализа истории диалога перед роутингом; отсутствие контекста не должно приводить к silent fallback на direct


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

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

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


Перетащи zip-архив → впиши в поле commit любой текст → **жми зелёную «Commit changes»** (это ключевой момент — без неё файл не попадает в репозиторий!)

https://github.com/CoralMinister/lidpotok → **Add file → Upload files**

Вернись в репозиторий и **глазами проверь**, что zip появился в списке файлов.

Скажи мне — я запущу доставку + импорт, добавится ABC-4xx.

Explanation: Запрос «2 файла загружены» не содержит ни одного из обязательных элементов: нет описания system/expected/actual (ПАТТЕРН 4), нет глагола действия (ПАТТЕРН 3), нет контекста типа файлов. Применим ПАТТЕРН 2 (discovery-interview): запрос допускает ≥5 интерпретаций, угадывать намерение запрещено.

Laravel Boost

Нет упоминания SQL, Eloquent или Laravel-документации — контекст файлов полностью отсутствует

Semgrep + Semgrep MCP

Нет оснований предполагать, что нужен SAST-анализ — тип файлов и цель не указаны

Superpowers v5.1.0

Невозможно выбрать meta-skill без понимания задачи — «2 файла загружены» не содержит ни глагола, ни объекта работы

Summary: Пользователь загрузил 2 файла, роутер не определил узел, выбран direct без цепочки обработки

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

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


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

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

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


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

Следовало запросить уточнение у пользователя, что именно означает '!' — команда, восклицание или ошибка ввода

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


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

При неопределённом узле и минимальном входе стоит запросить уточнение у пользователя, а не молча направлять в direct

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


Summary: PreToolUse:Edit hook error: [node tools/enforce-normative-content-rules.mjs]: no

Summary: File does not exist. Note: your current working directory is C:\моя\проекты\порт

Summary: <tool_use_error>Found 2 matches of the string to replace, but replace_all is fal

Summary: Сложный документационный запрос (обновление CLAUDE.md + runbook + memory) направлен напрямую без специализированного узла

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

Запросы с явными diff-инструкциями к нескольким MD-файлам и changelog-записями стоит направлять в документационный/редакторский узел, даже если они выглядят как 'обновление заметок'


Explanation: Запрос просит сгенерировать промпт для переезда в новую сессию с правильным выбором worktree и захватом всех незавершённых хвостов. Это точно покрывается capability 'finishing-branch' из Superpowers #19: скил умеет инвентаризировать текущее состояние (ветки, uncommitted изменения, pending задачи) и формировать structured handoff для следующей сессии. Дополнительно задействуется 'verify-before-completion' для проверки, что все хвосты учтены перед генерацией промпта.

claude-md-management управляет именно файлом CLAUDE.md (аудит, правки, захват learnings). Запрос не про обновление CLAUDE.md — он про генерацию промпта для смены сессии с учётом worktree и незакрытых задач. Это разные цели.

GitHub MCP мог бы помочь прочитать открытые PR/issues как часть 'хвостов', но не умеет формировать handoff-промпт и не знает о локальных worktree и uncommitted изменениях. Это вспомогательный инструмент, не решатель.

adr-kit фиксирует архитектурные решения, не предназначен для захвата операционного состояния сессии (worktree, незакрытые задачи, pending изменения). Не релевантен.

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

Запрос на генерацию промта для переезда между сессиями с контекстом worktree мог бы выиграть от специализированного узла — например, prompt-writer или context-transfer handler, который знает структуру worktree и умеет формировать handoff-промты

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


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

Summary: <tool_use_error>Cancelled: parallel tool call Bash(cd "c:/моя/проекты/портал crm

Summary: <tool_use_error>Cancelled: parallel tool call Bash(git fetch origin --quiet; git

Summary: Сложный контекстный запрос с памятью/CLAUDE.md/worktree направлен в direct вместо специализированного узла #51

Узел #51 был рекомендован роутером как оптимальный для задачи с живой фичей, памятью проекта и сложным контекстом. Direct-режим пропускает потенциально важную оркестрацию: чтение памяти, выбор worktree, соблюдение ограничений router-gate. Следовало пройти через рекомендованный узел.

Когда роутер явно рекомендует конкретный узел для контекстно-богатого запроса с живым продом, памятью и жёсткими ограничениями — игнорировать рекомендацию опасно. Direct может упустить критические шаги оркестрации (чтение памяти, pre-deploy-checks, worktree-логику).


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

Следовало использовать рекомендованный узел #51 или явно обосновать отклонение от рекомендации роутера

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


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

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

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


Explanation: Запрос 'дай пошаговую инструкцию' не содержит ни предмета (чему/чего?), ни контекста (для кого? в какой системе?), ни типа задачи. ПАТТЕРН 2: запрос допускает минимум 4 интерпретации — недопустимо угадывать. Требуется уточнение предмета инструкции.

operations

Покрывает runbook и process-doc, но неизвестно, о каком процессе идёт речь — нет контекста задачи

Superpowers v5.1.0

Мог бы подойти для writing-plans, но запрос слишком абстрактен — неясно, к какой фиче/задаче нужен план

discovery-interview

Наиболее вероятный кандидат для прояснения запроса через FEATURE-режим, но без контекста невозможно подтвердить даже это

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

Перед выбором узла следовало запросить уточнение: инструкцию по чему именно? Без контекста выбор direct — вынужденный, но не оптимальный

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


process-analysis

Подходит если речь о бизнес-процессах внутри Лидерры (as-is discovery), но запрос не содержит указания на конкретный процесс/модуль

Frontend Design plugin

Подходит если речь о минимизации UI-действий пользователя, но нет упоминания конкретного экрана или компонента

Design plugin

Подходит для UX-критики и упрощения flows, но слишком мало контекста для применения

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

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

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


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

discovery-interview

Мог бы подойти если 'первый шаг' = старт discovery новой фичи, но запрос слишком краткий — нет контекста задачи.

Superpowers v5.1.0

Мог бы подойти если 'первый шаг' = старт writing-plans или brainstorming, но без указания задачи невозможно определить нужный meta-skill.

CCPM

Мог бы подойти если 'первый шаг' = старт PRD → эпики, но контекст отсутствует полностью.

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

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

При отсутствии контекста и неоднозначных запросах типа 'начни с первого шага' нужно активировать узел clarification вместо direct


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

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

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


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

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

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


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

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

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


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

Следовало запросить уточнение у пользователя, что означает '!' вместо молчаливого fallback на direct

Односимвольные или бессмысленные запросы требуют явного запроса clarification, а не тихого fallback


Explanation: Запрос содержит готовый SQL-запрос и вопрос «вот это нужно?» — пользователь хочет выполнить его против dev-БД и посмотреть результат. Laravel Boost (#10) выполняет произвольные SQL-запросы к dev-БД через Eloquent/raw query и является единственным MCP-инструментом прямого доступа к БД в проекте (заменил PostgreSQL MCP #1).

squawk

squawk линтует миграции PostgreSQL на опасные паттерны, не выполняет SELECT-запросы и не отвечает на вопрос о результатах данных

process-analysis

process-analysis делает discovery из исходного кода Laravel (маршруты, джобы), а не выполняет произвольный SQL против живой БД

graphifyy

graphifyy строит knowledge-graph по коду и документации, не способен выполнять SQL-запросы к операционной базе данных

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

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

SQL-запросы с аналитическими CTE и вопросом 'вот это нужно?' требуют узла для ревью кода/запросов — нужно добавить паттерн распознавания SQL в роутер


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

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

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


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

Для запроса из одного символа '!' следовало запросить уточнение у пользователя, а не пытаться назначить узел отладки — выбор systematic-debugging не имеет обоснования

Односимвольные или бессмысленные запросы должны триггерить запрос clarification, а не случайный выбор узла — роутер должен иметь fallback-стратегию для неинтерпретируемых входных данных


Summary: Stop hook заблокировал сессию: coverage указывал skill:systematic-debugging, но Skill tool не был вызван. Выбран direct.

Нужно было либо вызвать Skill tool с именем systematic-debugging, либо изначально выставить coverage как direct с обоснованием. Роутер не определил узел — это сбой планирования.

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


Laravel Boost

Подходит если задача — разовый SQL-запрос для сверки дублей, но запрос слишком размыт: непонятно, нужна ли диагностика кода, ручная сверка или исправление логики импорта

billing-audit

Покрывает инварианты биллинга и идемпотентность списаний, но не импорт лидов от поставщика — не релевантен

Если это баг дублирования при импорте — systematic-debugging уместен, но для PATTERN 4 не хватает описания system/expected/actual; нельзя выбрать без уточнения

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

Запрос содержит бизнес-контекст (лиды, поставщик, лидерр/CRM) — нужно было распознать намерение пользователя: синхронизация данных, сверка записей или действие с лидами. Следовало направить к специализированному узлу обработки CRM-запросов или уточнить задачу

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


Explanation: Запрос не содержит actionable задачи: отсутствует system (что происходит), expected (что должно быть), actual (что не работает). Эмоциональный сигнал + 'разлочу на весь гитхаб' допускает минимум 3 несовместимых интерпретации (расширение прав, автоматизация рутины, смена контекста). По ПАТТЕРНУ 2: не угадывать — вернуть no_skill_found с запросом уточнения.

GitHub MCP

Упоминание 'гитхаб' указывает на GitHub MCP, но 'разлочу' — неизвестная операция; расширение прав доступа к MCP не является задачей этого классификатора и требует уточнения намерения

Superpowers v5.1.0

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

GitHub Dependabot

Если утомление связано с ручным обновлением зависимостей, Dependabot мог бы помочь, но это чистая догадка без фактических данных в запросе

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

Запрос требовал разъяснения: пользователь хочет дать Claude доступ к GitHub-репозиторию. Нужен узел для работы с внешними инструментами или clarification-узел, а не просто direct без цепочки

Эмоциональные запросы с техническим намерением (предоставить доступ к ресурсу) должны триггерить clarification или tool-access узел, а не fallback в direct без обработки


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

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

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


Summary: PreToolUse:Edit hook error: [node tools/enforce-tdd-gate.mjs]: [enforce-tdd-gate

Summary:
Exit code 1

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

 ❯ ../tool

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

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

Запрос о настройке GitHub read-only доступа должен быть направлен к специализированному узлу для работы с инструментами/интеграциями. Роутер не справился с классификацией нечёткого запроса на русском языке

Запросы на русском языке с неформальной формулировкой ('хорошо делай') требуют лучшей обработки намерений. Следует распознавать паттерн 'настройка доступа к внешнему сервису' и маршрутизировать к соответствующему узлу


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

Следовало запросить уточнение: что именно запустил пользователь и какое действие ожидается. Выбор direct без контекста — слабое решение.

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


Summary: Пустой или неинформативный запрос 'так?' не был маршрутизирован, выбран прямой ответ

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

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


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

Для односимвольных или бессмысленных запросов стоит запросить уточнение у пользователя вместо молчаливого fallback на direct

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


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

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

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


Explanation: Запрос содержит минимум три несовместимые интерпретации ('что поделать' = фичи/идеи/backlog, 'подберём вопросы' = discovery-интервью / GitHub-issues / сессионный Q&A). Паттерн 2 (discovery-interview): когда запрос допускает 3+ интерпретации — не угадывать, вернуть no_skill_found с clarification-запросом.

Superpowers v5.1.0 — brainstorming

Подходит если цель — генерация идей для дальнейшей работы, но запрос слишком размыт: непонятно, что значит 'вопросы' и в каком контексте.

discovery-interview

Подходит если 'подберём вопросы' означает составить список вопросов для интервью с заказчиком, но это лишь одна из возможных интерпретаций.

GitHub MCP

Подходит если речь о незакрытых issues/вопросах в репозитории, но в запросе нет явного указания на GitHub или backlog.

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

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

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


Сейчас — залей поправленный файл воркфлоу (1 клик, закроем косметику; я проверю чтением следующего прогона).

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

DaData подтвердим, когда придут лиды.

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

Роутер должен запросить уточнение у пользователя вместо молчаливого fallback на direct при неоднозначном вводе

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


Explanation: Запрос не содержит достаточного контекста для маршрутизации к какому-либо skill. Паттерн 2 (discovery-interview): два и более возможных толкования без возможности однозначного выбора — возвращаем no_skill_found с просьбой уточнить.

discovery-interview

Скил подходит для структурированного выяснения потребностей, но запрос слишком размыт — нет признаков feature/system режима

CCPM

Управление проектом не релевантно — запрос не содержит PRD, эпиков или задач

Playwright MCP

Нет упоминания UI, прототипа или страницы для проверки

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

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

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


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

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

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


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

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

При неопределённом запросе можно запросить уточнение у пользователя вместо silent fallback на direct

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


Ветки — сам, главное — ты

Ветки — сам, главное — ты
Всё через тебя

Ветки — сам, главное — ты

Explanation: Запрос требует изменения логики существующего PreToolUse-хука (блокировщика) — это прямая работа с хук-архитектурой Claude Code. hookify (#58) специализируется именно на генерации и перенастройке хуков (PreToolUse, PostToolUse, Stop, UserPromptSubmit) и выполняет HK1 pre-check для проверки коллизий с существующей архитектурой. Задача: перенастроить whitelist/blacklist правила хука так, чтобы пропускать composer/npm/pest/git/worktree, но блокировать deploy, боевую БД, секреты, запуск workflow.

Security Guidance — это сам блокирующий хук (inline speed-bump), а не инструмент для его настройки. Он перехватывает правки файлов с уязвимыми паттернами, но не предоставляет интерфейса для изменения собственных правил блокировки.

claude-code-setup (#59) — READ-ONLY рекомендатель автоматизаций Claude Code, предлагает настройки на основе паттернов, но не генерирует и не изменяет хуки. Не подходит для активного перепроектирования логики блокировщика.

Задача хотя и требует проектирования правил (whitelist/blacklist), но это конкретная двухшаговая задача перенастройки хука — не полноценная feature ≥3 шагов, требующая writing-plans. hookify уже включает HK1 pre-check как встроенный шаг анализа.

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

Задача конкретная и техническая — настройка политики разрешений для dev-окружения. Подходящий узел: implementation или architecture, а не brainstorming. Brainstorming уместен для генерации идей, а не для конкретной технической конфигурации.

Запросы на перенастройку систем безопасности/ACL с чёткими критериями (что блокировать, что разрешить) следует роутить в implementation/architecture, а не brainstorming. Отсутствие рекомендации роутера — сигнал для fallback-логики, а не для выбора creative-узла.


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

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

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


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

Роутер должен был корректно определить узел с самого начала, чтобы избежать срабатывания stop hook. Необходимо либо вызвать Skill tool с brainstorming, либо сразу выбрать direct с обоснованием.

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


Summary: Роутер не определил узел, выбран direct после feedback от stop-hook об отсутствии вызова Skill-инструмента

Роутер должен был либо явно вызвать Skill-инструмент с именем 'writing-plans', либо изначально выбрать direct с обоснованием, а не оставлять узел неопределённым

Если coverage указывает skill:X, необходимо фактически вызвать Skill-инструмент с этим именем; несоответствие между декларируемым coverage и реальными вызовами инструментов должно быть устранено до завершения хода