Requirements

---
name: requirements
description: В начале фичи, когда требования размытые - уточняющие вопросы, потом ТЗ и user stories с критериями приемки до кода. При ясных требованиях и на тривиальной правке избыточен.
---

# Сбор требований в спецификацию

Превращает размытые бизнес-требования в письменную спеку до кода. Порядок жесткий: сначала понять и уточнить, только потом писать.

## Шаг 1: Собрать вход

- Если требования уже лежат в проекте (например `docs/requirements/business-requirements.md` или тикет) - прочитай их.
- Если содержательных требований нет - попроси пользователя описать, что нужно и зачем. Не начинай писать спеку с пустого места.

## Шаг 2: Уточнить ПЕРЕД тем как писать

- Составь список вопросов, неясностей и неявных требований.
- Выяви допущения и назови их явно.
- Отметь противоречия в требованиях и edge cases.
- **Задай вопросы и дождись ответов.** Не додумывай бизнес-логику - спрашивай.

## Шаг 3: Зафиксировать требования

Если требования пришли из ответов пользователя (а не лежали готовыми в файле) - сохрани их в `docs/requirements/business-requirements.md`: исходное описание, уточнения, ключевые ограничения. Спека без зафиксированного источника висит в воздухе; не переходи к ТЗ, пока источник не записан.

## Шаг 4: Написать спецификацию

Масштабируй формальность под задачу: маленькая фича - короткая спека; полноценный greenfield - развернутая. Не раздувай разделы, которые проект не требует.

`docs/requirements/technical-spec.md` - по мере применимости:

- Цель, аудитория, границы (что входит / что НЕ входит).
- Глоссарий терминов - если есть неоднозначные.
- Функциональные требования: ID (FR-001), описание, приоритет (MoSCoW: Must / Should / Could / Won't), бизнес-правила, входы/выходы.
- Нефункциональные требования (производительность, безопасность, масштабируемость) - только если реально значимы. Не выдумывай цифры SLA/RPS без причины: бери из требований либо помечай как допущение.
- Роли и права, интеграции, ограничения и допущения - если применимо.

`docs/requirements/user-stories.md`:

- Для каждой функциональной группы: **US-001**: Как [роль], хочу [действие], чтобы [ценность].
- Критерии приемки чек-боксами - это главный проверяемый артефакт, не пропускай.
- Приоритет и грубая оценка сложности (S/M/L/XL).

## Шаг 5: Саммари

Короткий итог: сколько FR и US, распределение по приоритетам, открытые риски и противоречия, которые всплыли. Остановись - не переходи к архитектуре или коду без отдельного запроса.

## Важно

- Не выходи за рамки сбора требований: здесь не проектируется архитектура и не пишется код.
- Граница с SDD-конвейером (`rules/sdd-pipeline.md`): этот скилл дает бизнес-ТЗ из размытого входа, доменная спека там - инженерные инварианты домена. ТЗ кормит спеку фичи, а не наоборот; инварианты домена здесь не пишутся.
- Каждое допущение помечай как допущение.
- Существующие файлы не перезатирай молча - обновляй по месту.

См. также `rules/karpathy-guidelines.md` (Think Before Coding: не додумывай, спрашивай) - там общий принцип, здесь процедура его применения к сбору требований.