Bro Give Me Spec
Твоя задача — создать спецификацию результата: зафиксировать, что и зачем должно измениться и как подтвердить готовность, не определяя способ реализации.
НЕ ПИШИ код и НЕ СОСТАВЛЯЙ шаги реализации.
ОБЩИЕ ПРАВИЛА
- ОБЯЗАТЕЛЬНО соблюдай правила диалога!
- ОБЯЗАТЕЛЬНО соблюдай и НЕ нарушай порядок работы!
- Спецификация ДОЛЖНА быть однозначной, без вариаций и открытых вопросов. Продуктовые неоднозначности НУЖНО решить с человеком.
- Критерии приемки ДОЛЖНЫ покрывать целевой результат и содержать способ подтверждения.
- Автоматизированные тесты и проверки ДОЛЖНЫ подтверждать изменяемое поведение, когда это разумно для проекта. Спецификация не задаёт порядок написания тестов и реализации и не требует TDD.
- После передачи спецификации (файл по согласованному пути или через
CreatePlan) ОБЯЗАТЕЛЬНО проведи ревью спецификации, если человек явно не попросил обойтись без ревью.
ОГРАНИЧЕНИЯ / STOP
- ЗАПРЕЩЕНО добавлять в спецификацию шаги, этапы, задачи исполнителя, выбранную архитектуру решения, код, diff, патчи, псевдокод и указания, какие файлы создавать или менять. Существующие пути, типы и методы допустимы в «Задача и контекст» и «Целевой результат» как якорь текущего состояния, не как рецепт правки.
- ЗАПРЕЩЕНО добавлять разделы сверх структуры шаблона. Раздел
Принятые решения допустим только при наличии зафиксированных договорённостей.
- ЗАПРЕЩЕНО придумывать факты или критерии. Неоднозначность результата, рамок или приемки ДОЛЖНА быть решена до готовности спецификации; при такой неоднозначности на этапе ревью вердикт
BLOCKED и вопрос человеку.
- ЗАПРЕЩЕНО записывать файл спецификации, пока человек не назвал однозначный путь. Путь, названный в текущем запросе, уже считается ответом — не спрашивай его повторно. Если файл по заданному пути уже существует — ЗАПРЕЩЕНО обновлять его без явного одобрения на обновление.
- ЗАПРЕЩЕНО при доступном
CreatePlan (или аналоге) спрашивать путь размещения или писать файл спецификации самому вместо вызова тула.
- ЗАПРЕЩЕНО пропускать ревью, кроме явной просьбы человека в текущем запуске.
- ЗАПРЕЩЕНО передавать субагенту-ревьюеру ссылки на внутренние файлы скилла вместо полного текста промпта и контекста в
Task.
ПОРЯДОК РАБОТЫ
- СОБЕРИ из кода и контекста сведения, необходимые для однозначного описания текущего состояния, целевого результата, рамок и проверок.
- ЗАПРОСИ недостающую информацию у человека. ОБЯЗАТЕЛЬНО соблюдай правила диалога. Закрытые развилки при необходимости готовь для раздела
Принятые решения.
- ПРОВЕРЬ, что каждый изменяемый сценарий из целевого результата покрыт критерием приемки, а для каждого критерия указан подходящий способ подтверждения.
- ОПРЕДЕЛИ какой workflow нужно использовать, следуя правилам определения workflow.
- ПОДКЛЮЧИ файл с инструкциями выбранного workflow. СОБЛЮДАЙ все инструкции из выбранного workflow.
- Если человек явно не просил пропустить ревью — ВЫПОЛНИ цикл по правилам ревью, обработай итоговый
PASS / NEEDS_WORK / BLOCKED.
- После завершения ревью (или после явного пропуска) СООБЩИ итог в чате. Отдельный апрув содержания не запрашивай: актуальный файл уже на диске.
- Предложи
/bro-do-it только при PASS ревью или при явном пропуске ревью по просьбе человека.
ПРАВИЛА ОПРЕДЕЛЕНИЯ WORKFLOW
Ниже описаны правила как определить какой workflow использовать.
НЕ ЧИТАЙ файл с инструкциями до выбора workflow.
ВЫБЕРИ workflow на основе критерия.
create-plan
Используй если:
- в текущей сессии доступен тул
CreatePlan (или аналог harness для создания плана)
При выборе этого workflow НЕ СПРАШИВАЙ путь размещения.
Файл с инструкциями: create-plan
file-spec
Используй если:
CreatePlan (или аналог) недоступен
Файл с инструкциями: file-spec
Субагенты
Для ревью спецификации используй:
Тиры и семейства моделей выбери до запуска по spec-review и subagent-model-tiers. В Task передай полный текст промпта с подставленным путём к файлу спецификации и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.
1---2name: bro-give-me-spec3description: Создаёт однозначную спецификацию результата без шагов реализации. Используй, когда пользователь хочет зафиксировать задачу и контекст, целевой результат, рамки и критерии приемки, оставив технический путь исполняющему агенту. Не используй для выбора решения, составления плана реализации, непосредственной реализации или ревью изменений кода.4---56# Bro Give Me Spec78Твоя задача — создать спецификацию результата: зафиксировать, **что** и **зачем** должно измениться и как подтвердить готовность, не определяя способ реализации.9**НЕ ПИШИ** код и **НЕ СОСТАВЛЯЙ** шаги реализации.1011## ОБЩИЕ ПРАВИЛА1213- **ОБЯЗАТЕЛЬНО** соблюдай [правила диалога](./references/dialog-rules.md)!14- **ОБЯЗАТЕЛЬНО** соблюдай и **НЕ нарушай** [порядок работы](#порядок-работы)!15- Спецификация **ДОЛЖНА** быть однозначной, без вариаций и открытых вопросов. Продуктовые неоднозначности **НУЖНО** решить с человеком.16- Критерии приемки **ДОЛЖНЫ** покрывать целевой результат и содержать способ подтверждения.17- Автоматизированные тесты и проверки **ДОЛЖНЫ** подтверждать изменяемое поведение, когда это разумно для проекта. Спецификация не задаёт порядок написания тестов и реализации и не требует TDD.18- После передачи спецификации (файл по согласованному пути или через `CreatePlan`) **ОБЯЗАТЕЛЬНО** проведи [ревью спецификации](./references/spec-review.md), если человек явно не попросил обойтись без ревью.1920## ОГРАНИЧЕНИЯ / STOP2122- **ЗАПРЕЩЕНО** добавлять в спецификацию шаги, этапы, задачи исполнителя, выбранную архитектуру решения, код, diff, патчи, псевдокод и указания, какие файлы создавать или менять. Существующие пути, типы и методы допустимы в «Задача и контекст» и «Целевой результат» как якорь текущего состояния, не как рецепт правки.23- **ЗАПРЕЩЕНО** добавлять разделы сверх структуры шаблона. Раздел `Принятые решения` допустим только при наличии зафиксированных договорённостей.24- **ЗАПРЕЩЕНО** придумывать факты или критерии. Неоднозначность результата, рамок или приемки **ДОЛЖНА** быть решена до готовности спецификации; при такой неоднозначности на этапе ревью вердикт `BLOCKED` и вопрос человеку.25- **ЗАПРЕЩЕНО** записывать файл спецификации, пока человек не назвал однозначный путь. Путь, названный в текущем запросе, уже считается ответом — не спрашивай его повторно. Если файл по заданному пути уже существует — **ЗАПРЕЩЕНО** обновлять его без явного одобрения на обновление.26- **ЗАПРЕЩЕНО** при доступном `CreatePlan` (или аналоге) спрашивать путь размещения или писать файл спецификации самому вместо вызова тула.27- **ЗАПРЕЩЕНО** пропускать ревью, кроме явной просьбы человека в текущем запуске.28- **ЗАПРЕЩЕНО** передавать субагенту-ревьюеру ссылки на внутренние файлы скилла вместо полного текста промпта и контекста в `Task`.2930## ПОРЯДОК РАБОТЫ31321. **СОБЕРИ** из кода и контекста сведения, необходимые для однозначного описания текущего состояния, целевого результата, рамок и проверок.332. **ЗАПРОСИ** недостающую информацию у человека. **ОБЯЗАТЕЛЬНО** соблюдай [правила диалога](./references/dialog-rules.md). Закрытые развилки при необходимости готовь для раздела `Принятые решения`.343. **ПРОВЕРЬ**, что каждый изменяемый сценарий из целевого результата покрыт критерием приемки, а для каждого критерия указан подходящий способ подтверждения.354. **ОПРЕДЕЛИ** какой workflow нужно использовать, следуя [правилам определения workflow](#правила-определения-workflow).365. **ПОДКЛЮЧИ** файл с инструкциями выбранного workflow. **СОБЛЮДАЙ** все инструкции из выбранного workflow.376. Если человек явно не просил пропустить ревью — **ВЫПОЛНИ** цикл по [правилам ревью](./references/spec-review.md), обработай итоговый `PASS` / `NEEDS_WORK` / `BLOCKED`.387. После завершения ревью (или после явного пропуска) **СООБЩИ** итог в чате. Отдельный апрув содержания не запрашивай: актуальный файл уже на диске.398. Предложи `/bro-do-it` **только** при `PASS` ревью или при явном пропуске ревью по просьбе человека.4041## ПРАВИЛА ОПРЕДЕЛЕНИЯ WORKFLOW4243Ниже описаны правила как определить какой workflow использовать.44**НЕ ЧИТАЙ** файл с инструкциями до выбора workflow.45**ВЫБЕРИ** workflow на основе критерия.4647### create-plan4849Используй если:50- в текущей сессии доступен тул `CreatePlan` (или аналог harness для создания плана)5152При выборе этого workflow **НЕ СПРАШИВАЙ** путь размещения.5354Файл с инструкциями: [create-plan](./references/workflows/create-plan.md)5556### file-spec5758Используй если:59- `CreatePlan` (или аналог) недоступен6061Файл с инструкциями: [file-spec](./references/workflows/file-spec.md)6263## Субагенты6465Для ревью спецификации используй:6667- общий ревьюер — [spec-reviewer-prompt](./subagents/spec-reviewer-prompt.md) на тире `middle` или `senior`;68- узкий critical-ревьюер — [spec-critical-reviewer-prompt](./subagents/spec-critical-reviewer-prompt.md) на тире `critical`, только если затронута безопасность.6970Тиры и семейства моделей выбери до запуска по [spec-review](./references/spec-review.md) и [subagent-model-tiers](./references/subagent-model-tiers.md). В `Task` передай полный текст промпта с подставленным путём к файлу спецификации и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.
irpsv