# Bro Give Me Spec

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

- Skill: `irpsv/bro-give-me-spec` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add irpsv/bro-give-me-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/irpsv/bro-give-me-spec/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-give-me-spec

---


# Bro Give Me Spec

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

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

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

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

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

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

1. **СОБЕРИ** из кода и контекста сведения, необходимые для однозначного описания текущего состояния, целевого результата, рамок и проверок.
2. **ЗАПРОСИ** недостающую информацию у человека. **ОБЯЗАТЕЛЬНО** соблюдай [правила диалога](./references/dialog-rules.md). Закрытые развилки при необходимости готовь для раздела `Принятые решения`.
3. **ПРОВЕРЬ**, что каждый изменяемый сценарий из целевого результата покрыт критерием приемки, а для каждого критерия указан подходящий способ подтверждения.
4. **ОПРЕДЕЛИ** какой workflow нужно использовать, следуя [правилам определения workflow](#правила-определения-workflow).
5. **ПОДКЛЮЧИ** файл с инструкциями выбранного workflow. **СОБЛЮДАЙ** все инструкции из выбранного workflow.
6. Если человек явно не просил пропустить ревью — **ВЫПОЛНИ** цикл по [правилам ревью](./references/spec-review.md), обработай итоговый `PASS` / `NEEDS_WORK` / `BLOCKED`.
7. После завершения ревью (или после явного пропуска) **СООБЩИ** итог в чате. Отдельный апрув содержания не запрашивай: актуальный файл уже на диске.
8. Предложи `/bro-do-it` **только** при `PASS` ревью или при явном пропуске ревью по просьбе человека.

## ПРАВИЛА ОПРЕДЕЛЕНИЯ WORKFLOW

Ниже описаны правила как определить какой workflow использовать.
**НЕ ЧИТАЙ** файл с инструкциями до выбора workflow.
**ВЫБЕРИ** workflow на основе критерия.

### create-plan

Используй если:
- в текущей сессии доступен тул `CreatePlan` (или аналог harness для создания плана)

При выборе этого workflow **НЕ СПРАШИВАЙ** путь размещения.

Файл с инструкциями: [create-plan](./references/workflows/create-plan.md)

### file-spec

Используй если:
- `CreatePlan` (или аналог) недоступен

Файл с инструкциями: [file-spec](./references/workflows/file-spec.md)

## Субагенты

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

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

Тиры и семейства моделей выбери до запуска по [spec-review](./references/spec-review.md) и [subagent-model-tiers](./references/subagent-model-tiers.md). В `Task` передай полный текст промпта с подставленным путём к файлу спецификации и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.