# Bro Review Spec Plan

> Проводит независимое ревью спецификации результата или плана реализации без их исправления. Используй, когда пользователь просит проверить spec или план, карточку CreatePlan, критерии приемки или рамки задачи. Не используй, когда пользователь просит составить спецификацию или план, реализовать задачу, исправить артефакт или провести ревью изменений кода.

- Skill: `irpsv/bro-review-spec-plan` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add irpsv/bro-review-spec-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/irpsv/bro-review-spec-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: irpsv (https://skillmd.com/u/irpsv)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/irpsv/bro-review-spec-plan

---


# bro-review-spec-plan

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

Оркестратор сам артефакт не ревьюит: что считать finding, задают промпты субагентов.

## READONLY

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

Запрещено:

- изменять или создавать файлы, в том числе spec, plan и файлы harness;
- вызывать `CreatePlan` или аналог обновления плана;
- править текст артефакта «заодно» с отчётом;
- предлагать архитектуру, diff, патчи, псевдокод или шаги реализации как замену findings;
- сообщать стилистические предпочтения и недоказанные предположения как findings.

## Вход ревью

Сначала определи **объект ревью**:

1. Явно указанный путь к файлу.
2. Прикреплённый или открытый файл спецификации или плана.
3. Полный текст артефакта в текущем сообщении человека.
4. Если есть ровно один очевидный свежий кандидат — возьми его и назови путь в отчёте. Если кандидатов несколько или ни одного — не угадывай.

Если объект так и не установлен — остановись и задай один вопрос, что ревьюить. Не начинай ревью по догадке.

## Кого запускать

Ревью **ОБЯЗАТЕЛЬНО** должны делать субагенты ревьюверы:
1. общее ревью — тир `senior`, промпт субагента [reviewer-prompt](./subagents/reviewer-prompt.md)
2. проверка безопасности — тир `critical`, промпт субагента [security-reviewer-prompt](./subagents/security-reviewer-prompt.md)

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

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

Начни с раздела `## Результаты ревью`. Дальше:

- **Статус:** `PASS` | `NEEDS_WORK` | `BLOCKED`
- **Объект:** путь или «текст из сообщения»

Затем findings. Для каждого:

1. Заголовок `#### [ID] Краткое название`.
2. `**Тип:**` значение из отчёта ревьюера.
3. `**Где:**` раздел, шаг, критерий или утверждение.
4. `**Проблема:**` конкретный дефект.
5. `**Доказательство:**` фрагмент артефакта и/или факт из репозитория или проверки ссылки.
6. `**Требуется:**` какое изменение текста или какой ответ человека нужен. Это не патч и не поручение править файл в этом запуске.

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

Если есть блокеры — отдельный раздел `### Блокеры` со списком вопросов или недоступных фактов. Не начинай допрос: для `BLOCKED` достаточно показать блокеры в отчёте.

Оформляй по [примеру](./references/review-output-example.md).

После результатов:

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

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