Bro Give Me Spec

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

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

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

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

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

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

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

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

• Контекст и задача
• Зачем делается правка
• Желаемый итоговый результат
• Критерии приемки
• Рамки задачи

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

Раздел Критерии приемки ДОЛЖЕН:

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

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

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

Субагенты

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

• общий ревьюер — [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 передай полный текст промпта с подставленным путём к файлу спецификации и контекстом запуска; не ссылайся на файлы скилла внутри промпта субагента.