Bro Give Me Spec

Твоя задача — создать спецификацию результата: зафиксировать, что и зачем должно измениться и как подтвердить готовность, не определяя способ реализации. НЕ ПИШИ код и НЕ СОСТАВЛЯЙ шаги реализации.

ОБЩИЕ ПРАВИЛА

ОБЯЗАТЕЛЬНО соблюдай правила диалога!
ОБЯЗАТЕЛЬНО соблюдай и НЕ нарушай порядок работы!
Спецификация ДОЛЖНА быть однозначной, без вариаций и открытых вопросов. Продуктовые неоднозначности НУЖНО решить с человеком.
При создании спецификации ОБЯЗАТЕЛЬНО соблюдай шаблон.
Критерии приемки ДОЛЖНЫ покрывать желаемый результат и содержать способ подтверждения.
Автоматизированные тесты и проверки ДОЛЖНЫ подтверждать изменяемое поведение, когда это разумно для проекта. Спецификация не задаёт порядок написания тестов и реализации и не требует TDD.
После записи
```
spec.md
```
ОБЯЗАТЕЛЬНО проведи ревью спецификации, если человек явно не попросил обойтись без ревью.

ОГРАНИЧЕНИЯ / STOP

ЗАПРЕЩЕНО добавлять в спецификацию шаги, этапы, задачи исполнителя, пути к файлам, выбранную архитектуру, код, diff, патчи или псевдокод.
ЗАПРЕЩЕНО добавлять разделы сверх структуры шаблона. Раздел
```
Принятые решения
```
допустим только при наличии зафиксированных договорённостей.
ЗАПРЕЩЕНО придумывать факты или критерии. Неоднозначность результата, рамок или приемки ДОЛЖНА быть решена до готовности спецификации; при такой неоднозначности на этапе ревью вердикт
```
BLOCKED
```
и вопрос человеку.
ЗАПРЕЩЕНО записывать
```
spec.md
```
до подтверждения пути человеком. Если файл уже существует — ЗАПРЕЩЕНО обновлять его без явного одобрения на обновление.
ЗАПРЕЩЕНО пропускать ревью, кроме явной просьбы человека в текущем запуске.
ЗАПРЕЩЕНО передавать субагенту-ревьюеру ссылки на внутренние файлы скилла вместо полного текста промпта и контекста в
```
Task
```
.

ПОРЯДОК РАБОТЫ

ПРОЧИТАЙ шаблон спецификации.
СОБЕРИ из кода и контекста сведения, необходимые для однозначного описания текущего состояния, желаемого результата, рамок и проверок.
ЗАПРОСИ недостающую информацию у человека. ОБЯЗАТЕЛЬНО соблюдай правила диалога. Закрытые развилки при необходимости готовь для раздела
```
Принятые решения
```
.
ПРОВЕРЬ, что каждый изменяемый сценарий из желаемого результата покрыт критерием приемки, а для каждого критерия указан подходящий способ подтверждения.
ПРОВЕРЬ наличие memory bank и выбери путь артефакта по правилам размещения. ПОДТВЕРДИ путь у человека (и одобрение на обновление, если файл уже есть).
СОЗДАЙ или ОБНОВИ
```
spec.md
```
по шаблону и согласованному пути. Не жди отдельного апрува содержания перед записью.
Если человек явно не просил пропустить ревью — ВЫПОЛНИ цикл по правилам ревью: выбери тиры по subagent-model-tiers, запусти общего ревьюера с полным текстом spec-reviewer-prompt и при необходимости узкого critical-ревьюера с spec-critical-reviewer-prompt, обработай итоговый
```
PASS
```
/
```
NEEDS_WORK
```
/
```
BLOCKED
```
.
После завершения ревью (или после явного пропуска) СООБЩИ итог в чате. Отдельный апрув содержания не запрашивай: актуальный файл уже на диске.
Предложи
```
/bro-do-it
```
только при
```
PASS
```
ревью или при явном пропуске ревью по просьбе человека.

Артефакт spec.md

spec.md

ДОЛЖЕН содержать обязательные разделы:

```
Контекст и задача
```

Зачем делается правка

Желаемый итоговый результат

```
Критерии приемки
```
```
Рамки задачи
```

Раздел

Принятые решения

МОЖЕТ присутствовать только если есть зафиксированные договорённости: ответы человека на развилки и существенные уточнения смысла после ревью. Иначе раздел НЕ создавай.

Раздел

Критерии приемки

ДОЛЖЕН:

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

Раздел

Рамки задачи

ДОЛЖЕН быть разделён только на подразделы:

```
Входит
```
```
Не входит
```

Субагенты

Для ревью спецификации используй:

общий ревьюер — spec-reviewer-prompt на тире
```
middle
```
или
```
senior
```
;
узкий critical-ревьюер — spec-critical-reviewer-prompt на тире
```
critical
```
, только если затронута безопасность.

Тиры и семейства моделей выбери до запуска по spec-review и subagent-model-tiers. В

Task

передай полный текст промпта с подставленным путём к

spec.md

и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.

Quality Control

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

артефакт находится в

memory-bank/changes/<feature-id>/spec.md

;

путь был подтверждён человеком до первой записи;
в артефакте есть все пять обязательных разделов и нет лишних, кроме допустимого
```
Принятые решения
```
;
нет шагов, этапов и способа реализации;
каждый изменяемый сценарий покрыт критерием приемки;
каждый критерий содержит проверяемое доказательство;
ревью выполнено по правилам (или явно пропущено человеком);
при
```
NEEDS_WORK
```
файл обновлён, при
```
BLOCKED
```
задан вопрос человеку;
```
/bro-do-it
```
предложен только после
```
PASS
```
или явного пропуска ревью.

bro-give-me-spec

NPX Install

Tags

SKILL.md Content

Bro Give Me Spec

ОБЩИЕ ПРАВИЛА

ОГРАНИЧЕНИЯ / STOP

ПОРЯДОК РАБОТЫ

Артефакт spec.md

Субагенты

Quality Control