mcpField
B
bro-review-spec-plan

bro-review-spec-plan

github.com/irpsvTesting & quality941 installsUpdated today
Repository

About bro-review-spec-plan

bro-review-spec-plan is a read-only skill for independently reviewing existing specifications or implementation plans. It returns an evidence-based report without editing the artifact or replacing review with planning or implementation.

Key features

  1. 01Reviews existing specs or implementation plans
  2. 02Reads artifacts, repositories, and related files
  3. 03Allows safe, non-destructive checks
  4. 04Reports findings with supporting evidence
  5. 05Does not edit files or create an implementation plan

Use cases

  1. 01Check a specification for substantive defects
  2. 02Review a plan and document evidenced findings
  3. 03Produce a report without changing the reviewed artifact

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/irpsv/ai-bro --skill bro-review-spec-plan

After installing, type/bro-review-spec-planin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

evals/
evals.json
trigger-evals.json
references/
review-output-example.md
subagent-model-tiers.md
subagents/
reviewer-prompt.md
security-reviewer-prompt.md

Details

From the project README

bro-review-spec-plan

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

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

READONLY

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

Запрещено:

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

Вход ревью

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

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

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

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

Ревью ОБЯЗАТЕЛЬНО должны делать субагенты ревьюверы:

  1. общее ревью — тир senior, промпт субагента reviewer-prompt
  2. проверка безопасности — тир critical, промпт субагента security-reviewer-prompt

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

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

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

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

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

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

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

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

Оформляй по примеру.

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

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

Comments

Markdown supported