Знакомит с набором ai-bro — карта скиллов и типовой флоу. Use when the user is new to ai-bro, asks «как пользоваться», «с чего начать», «онбординг», «/bro-on-board».

2026-07-206

bro-remember-it

irpsv/ai-bro

Пополняет существующий memory bank — постоянный слой знаний проекта. Use when the user wants to update project knowledge, specs, features, playbooks, or asks «запомни», «добавь в memory bank», «/bro-remember-it». Не инициализирует банк с нуля.

2026-07-146

bro-debug

irpsv/ai-bro

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

2026-07-146

bro-give-me-plan

irpsv/ai-bro

Помогает составить план реализации

2026-07-146

bro-init-memory-bank

irpsv/ai-bro

Инициализирует memory bank проекта с нуля — структура и первичное заполнение. Use when the user asks «инициализируй memory bank», «создай memory bank», «заведи банк знаний», «/bro-init-memory-bank». Не пополняет существующий банк.

2026-07-136

name	bro-review-code
description	Проводит независимое READONLY-ревью изменений кода: соответствие задаче, корректность, безопасность, производительность и тесты.
disable-model-invocation	true

bro-review-code

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

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

READONLY

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

Запрещено:

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

Вход ревью

Сначала определи:

Объект ревью — явно указанный diff, диапазон коммитов, ветка, PR или набор файлов.
Базу сравнения — явно указанную базу либо merge-base текущей и основной веток.
Контекст задачи — пользовательский результат, рамки, критерии приемки, ограничения и план, если они переданы.

Если объект не указан:

при наличии незакоммиченных изменений проверяй их вместе с относящимися к ним коммитами текущей задачи, если граница задачи понятна;
иначе проверяй текущую ветку относительно merge-base с основной веткой;
если значимых изменений нет или граница неоднозначна, остановись и запроси объект ревью.

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

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

Выбор режима

Правила выбора тира и семейства модели описаны в subagent-model-tiers. Для всех reviewer-субагентов используй тир code-reviewer.

Комплексное ревью

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

Профильное ревью

Запускай применимые профильные проверки параллельно, если изменение:

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

Доступные проверки:

requirements-review-prompt — соответствие задаче и рамкам;
correctness-review-prompt — корректность и регрессии;
security-review-prompt — безопасность;
performance-review-prompt — производительность;
tests-review-prompt — качество и полнота тестов.

Для широкого изменения запускай все пять проверок. Для локального, но высокорискового изменения запускай только относящиеся к риску профильные проверки вместе с проверкой корректности. Не запускай профиль, если его предмет заведомо отсутствует в изменениях.

Если текущий harness не поддерживает запуск вложенных субагентов, не останавливай ревью и не сокращай его область: самостоятельно последовательно примени все выбранные профильные промпты в текущем контексте, а затем собери единый отчёт по тем же правилам.

Во все промпты подставляй один и тот же полный контекст:

Объект ревью: <diff, диапазон, ветка, PR или файлы>
База сравнения: <base>
Задача и критерии: <переданный контекст либо «не переданы»>
Ограничения проекта: <релевантные правила>
Известные проверки: <что уже запускалось и с каким результатом>

Не передавай субагентам ссылки на файлы этого скилла: текст выбранного промпта и контекст должны полностью находиться в Task.

Объединение результатов

После профильного ревью самостоятельно собери единый отчёт:

Удали дубли, оставив наиболее точное доказательство и минимальное исправление.
Объедини замечания с одной корневой причиной.
Не повышай серьёзность только потому, что проблему нашли несколько субагентов.
Отбрось замечания без достижимого сценария, конкретного места и проверяемого доказательства.
При противоречии проверь код самостоятельно либо явно снизь confidence.
Отсортируй findings по серьёзности, затем по влиянию.

Серьёзность:

critical — достижимая потеря или массовая утечка данных, полный обход критической защиты, удалённое выполнение кода либо системная недоступность;
high — нарушение ключевого пользовательского сценария, обход авторизации, существенная регрессия данных или производительности;
medium — реальный дефект или пробел проверки с ограниченным влиянием и доказуемым сценарием;
стилистика, необязательные улучшения и гипотетические оптимизации не являются findings.

Итоговый формат

Сначала выдай findings. Для каждого укажи:

severity: critical / high / medium;
criterion: requirements / correctness / security / performance / tests;
where: файл и строка, символ либо точный участок логики;
problem: конкретный дефект;
impact: наблюдаемое последствие и затронутый сценарий;
evidence: доказательство из кода, контракта, diff или теста;
suggestion: минимальное осмысленное исправление;
confidence: high / medium / low с причиной, если уверенность не высокая.

Если findings нет, напиши: Существенных проблем не найдено.

После findings добавь:

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

что просмотрено;
какие проверки или команды использованы;
какие риски остались непроверенными и почему;
нужна ли дополнительная проверка человеком.

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

Quality Control

Перед завершением проверь:

объект и база ревью указаны однозначно;
выбран самостоятельный комплексный режим либо обоснованный набор профильных субагентов;
каждый finding относится к изменённому коду и подтверждён достижимым сценарием;
дубли объединены, серьёзность нормализована;
код и файлы не изменялись;
итог содержит только объединённые findings и краткое резюме.