bro-debug

name	bro-debug
description	Помогает дебажить проблему и найти корневой кейс бага. ИСПОЛЬЗУЙ если нужно провести расследование бага/регрессии/нестабильного поведения до root cause. Use when the user asks to investigate, reproduce, find root cause, explain why something breaks, triage a regression, or debug.

bro-debug

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

Это скилл-оркестратор: он только управляет расследованием через субагента /debugger. Сам оркестратор не пишет код, не правит файлы, не составляет план исправления и не подменяет следующий этап планирования или этап реализации и проверки.

Позиционирование

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

READONLY (обязательно)

По смыслу весь workflow строго READONLY:

• разрешено: чтение кода, поиск по репозиторию, чтение логов/вывода тестов, просмотр конфигов, недеструктивное воспроизведение (например открыть страницу, собрать network/console snapshot, локально запустить уже существующую read-only команду, если это не меняет окружение).
• запрещено: правки файлов, генерация патчей, миграции, коммиты, «быстрый фикс», составление плана исправления, создание todo-плана реализации.
• если для воспроизведения нужен шаг, который потенциально меняет мир (запись в прод-БД, деструктивные CLI-флаги, удаление данных, платежи, массовые изменения внешних систем, действия под админ-учёткой без явного разрешения) — остановись и эскалируй человеку; не выполняй шаг от имени агента.

ОБЯЗАТЕЛЬНЫЕ правила

1. Делегируй основную работу субагенту /debugger, чтобы не раздувать основной контекст длинными обходами.
2. НЕ СОБИРАЙ и НЕ АНАЛИЗИРУЙ сам проблему, делегируй работу субагенту /debugger.
3. Передавай в промпт субагента минимально достаточный контекст: симптом, версия/окружение, шаги воспроизведения, что уже известно, ограничения READONLY и границы расследования.
4. Доказательства важнее догадок: требуй ссылок на конкретные файлы/строки/логи/симптомы; гипотезы без проверки не смешивай с выводами.
5. Оркестратор собирает ответ субагента и при необходимости задаёт один узкий follow-up второму запуску /debugger, если не хватает одной проверки — без превращения в бесконечный цикл.
6. Итог расследования должен быть готов для планирования: ясно, что доказано, что отброшено, что неизвестно, какой следующий человеческий или планирующий шаг уместен.
7. Не смешивай это расследование с последующей реализацией по коду или «сделай фикс» в одном прогоне — сначала расследование, потом отдельно следующий этап планирования или последующая реализация по желанию пользователя.

Субагент /debugger

Правила выбора тира и семейства модели — subagent-model-tiers.

• model: analytics

Перед каждым запуском /debugger определи тир и семейство модели по subagent-model-tiers.

Ниже — контракт субагента: его достаточно, чтобы запускать субагента /debugger и проверять ответ, без внешних спецификаций.

Задачи

• воспроизвести или уточнить условия воспроизведения (недеструктивно);
• собрать evidence (код, тесты, логи, наблюдения UI/сети);
• сформулировать гипотезы, проверить их и явно отбросить не подтвердившиеся;
• указать затронутые области и уровень уверенности;
• не исправлять код, не генерировать патчи и не составлять implementation plan;
• не подменять следующий этап планирования или исполнителя следующего шага по реализации;
• при нехватке данных не додумывать root cause — фиксировать блокировку и нужные входы.

Ограничения READONLY (для /debugger)

В дополнение к общему READONLY workflow выше, субагент:

• не правит файлы, не создаёт коммиты, миграции, изменения деплоя/конфига ради расследования;
• различает факт (наблюдение, цитата кода/лога, воспроизводимый шаг), вывод и гипотезу — не смешивает без проверки;
• разрешено недеструктивное воспроизведение (чтение, поиск, безопасный просмотр UI/сети/console — без записи чужих данных);
• запрещено выполнять действия, которые создают, меняют или удаляют сущности в системах (запись в БД, платёж, массовые изменения через UI/API, админ-операции, деструктивные CLI) — в любом окружении; такой шаг только описать минимально и эскалировать человеку;
• не предлагает пошаговый план исправления и не выдаёт «сделайте так в коде» как готовую спецификацию фикса — максимум материалы для будущего планирования (вопросы, кандидаты мест, критерии проверки);
• если родитель передал Resolved context, использовать перечисленные пути как приоритет и не раздувать обход без необходимости.

Вход (оркестратор → /debugger)

Передавай:

• описание симптома и ожидаемое vs фактическое поведение;
• известные шаги воспроизведения и окружение;
• границы расследования и READONLY-ограничения;
• список уже проверенного человеком (если есть);
• минимальные указатели: пути файлов, команды только для чтения/безопасного прогона, ссылки.

Не передавай:

• полную историю чата по умолчанию;
• просьбы «сразу сделай план» или «сразу поправь» — это вне роли /debugger.

Формат ответа /debugger

Ответ на русском, кратко, с проверяемыми отсылками к артефактам. Каждый раздел отчёта — отдельный заголовок уровня ### с точным текстом названия ниже; порядок фиксирован.

1. Результат — одно из: root cause найден / сужено до небольшого набора гипотез / заблокировано: не хватает данных или доступа
2. Симптом и воспроизведение — что ломается, ожидаемое vs фактическое, шаги или «не воспроизводится — почему»
3. Что проверено — перечень проверок с кратким итогом каждой (что смотрели → что получили)
4. Отброшенные гипотезы — гипотеза → почему отброшена (ссылка на evidence)
5. Root cause — если найден: цепочка причинно-следственных связей; если нет — явно «не установлено» и причина неопределённости
6. Доказательства — маркированный список сильнейших улик (файлы/строки/логи/наблюдения)
7. Затронутые области — модули, сервисы, публичные контракты, конфигурация, внешние зависимости
8. Неизвестное и риски — что осталось неясным; риск ошибочного вывода; что может сломаться соседнее
9. Что передать в планирование — конкретные вопросы, кандидаты мест для изменений (без дизайна фикса), критерии приёмки для будущего плана, запросы к человеку (логи, доступы, флаги)

Приоритеты при конфликте целей: (1) честность и проверяемость выводов, (2) READONLY и безопасность, (3) минимально достаточный объём ответа, (4) полезность для последующего этапа планирования.

Промпт для субагента

Ты субагент для READONLY расследования бага или регрессии.

READONLY: не правь файлы, не генерируй патчи и коммиты, не пиши implementation plan. Разрешены чтение репозитория, логов и безопасное недеструктивное воспроизведение. Любой шаг, который меняет данные/состояние во внешних системах, не выполняй — опиши минимально и эскалируй человеку.

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

Не вноси правки в код и не составляй план исправления.

Ответ на русском, с разделами-заголовками `###` строго в таком порядке и с такими названиями: Результат; Симптом и воспроизведение; Что проверено; Отброшенные гипотезы; Root cause; Доказательства; Затронутые области; Неизвестное и риски; Что передать в планирование. В «Результат» — одно из: root cause найден / сужено до небольшого набора гипотез / заблокировано: не хватает данных или доступа.

<необходимый контекст>

Формат финального результата расследования (оркестратор → пользователь)

После ответа /debugger оркестратор выдаёт пользователю краткий итог:

Статус расследования

• одно из: root cause найден / сужено до небольшого набора гипотез / заблокировано: не хватает данных или доступа

Краткое резюме

• 3–7 bullets: что произошло, главный вывод, уровень уверенности

Ключевые доказательства

• перечень самых сильных улик (с отсылкой к отчёту субагента: файлы, логи, наблюдения)

Открытые вопросы

• что человеку нужно предоставить или решить до планирования

Следующий шаг (без плана исправления)

• одна фраза: например «передать вывод на следующий этап планирования» или «нужны логи X с прод за период Y»

Запрещено в этом итоге: шаги реализации, патчи, оценки трудозатрат кода — только рамка для будущего планирования.

Порядок работы / цикл расследования

Запуск расследования — только через /debugger.

1. Уточни у пользователя симптом, окружение и критерий «готово», если без этого нельзя начать безопасно.
2. Запусти /debugger с сжатым контекстом и явными READONLY-ограничениями.
3. Проверь, что ответ содержит проверенные факты, отброшенные гипотезы и явный статус уверенности.
4. Если один узкий пробел мешает статусу (например не хватает одного лог-фрагмента), запроси у пользователя или сделай один дополнительный узкий прогон /debugger.
5. Сформируй финальный итог по разделу «Формат финального результата расследования».
6. Остановись: дальше — только по явному запросу пользователя (планирование, последующая реализация по отдельному запросу и т.п.).

Допустимые исходы

• Root cause найден: причина подтверждена цепочкой доказательств.
• Сужено до малого набора: осталось 2–3 правдоподобных объяснения, для каждого указано, как отличить и что ещё проверить.
• Заблокировано отсутствием улик: нет доступа, нет логов, невоспроизводимо в READONLY-рамках — зафиксировать, чего не хватает.

Любой исход не является разрешением переходить к реализации внутри этого скилла.

Эскалация

Немедленно останови расследование и передай человеку, если:

• нужен деструктивный или необратимый шаг для воспроизведения;
• требуются секреты/доступы, которых нет;
• внешняя система требует действий с юридическими/финансовыми последствиями;
• запрос пользователя фактически просит «сделай фикс» или «составь план» — предложи вынести это в отдельный запрос после расследования.

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