---
name: feature-spec
description: Lightweight SDD-style Q&A skill for feature planning. Guides the agent through Spec-Driven Development questions before implementation. Produces a structured plan with 7 SDD sections (Контекст, Задача, Контракты, Инварианты, Граничные случаи, Вне scope, Критерии приемки). Also when user says "спека фичи", "feature spec", "план фичи", "обсудим фичу", "spec feature", "спецификация фичи".
---

# Feature Spec

Лёгкий SDD-скилл: Q&A с юзером по SDD-шаблону → план в чате → issue через `issue` скилл.

## Когда использовать

| Ситуация | Инструмент |
|----------|-----------|
| 1 файл, очевидное поведение | Прямой чат, без формальностей |
| 2+ компонента, бизнес-правила, diff >400 строк | `/feature-spec` |
| Новый проект с нуля | `/spec` (9 фаз) |

## ПРОТОКОЛ

### 1. Анализ

Юзер описывает фичу. Агент читает SDD-шаблон (ниже) и определяет, каких данных не хватает.

### 2. Q&A

Агент задаёт вопросы списком — НЕ гадает. Пример:

```
Не хватает информации по:
1. Контракты: какой формат запроса/ответа? Какие коды ошибок?
2. Инварианты: какие лимиты? Какой TTL? Какая модель/библиотека?
3. Граничные случаи: что если внешний сервис недоступен? Что если данных нет?
4. Вне scope: что точно НЕ делаем в этой итерации?
```

Юзер отвечает. Если ответ неполный — агент уточняет. Q&A продолжается пока все 7 секций не заполнены.

### 3. План

Когда все данные собраны, агент выводит структурированный план:

```
## Контекст
Зачем: [мотивация]
Контекст: [текущее состояние]

## Задача
[Что делаем — архитектурный подход, пошагово]

## Контракты
[API, форматы, коды ошибок]

## Инварианты
[Правила без исключений: лимиты, ограничения, выбор технологий]

## Граничные случаи
[Что при ошибках: невалидный вход, отказ сервиса, превышение лимита]

## Вне scope
[Что НЕ делаем]

## Критерии приемки
- [ ] Сценарий 1: "пользователь делает X → видит Y"
- [ ] Сценарий 2
```

### 4. Handoff

После готовности плана:
- Агент: "План готов. Скажи 'создай issue' чтобы создать issue, потом запусти /run-pipeline."
- Юзер: "создай issue" → загружается `issue` скилл → `create-issue` tool (7 секций) → issue создан
- Юзер: `/run-pipeline` → реализация

## Правила

- **Не гадай** — если данных не хватает, задай вопрос
- **Будь конкретным** — не "используй кеш", а "Redis с TTL 7 дней"
- **Спека описывает ЧТО, не КАК** — контракты и решения, не алгоритмы
- **Каждый пункт 1-3 предложения** — если больше, это две задачи
- **Если фича простая** (1 файл, очевидное поведение) — скажи юзеру что спека не нужна
- **Не создавай issues сам** — только планируй. Issues через `issue` скилл по команде юзера
- **Не запускай /run-pipeline** — юзер делает это сам
- **Не создавай файлы** — план живёт в чате, потом в issue
- **1 issue = 1 PR** — если фича большая, предложи разбить на подзадачи

## SDD-шаблон (7 секций)

Совпадает с `create-issue` validation (PR #169):

| # | Секция | Что содержит |
|---|--------|-------------|
| 1 | `## Контекст` | Зачем (мотивация) + текущее состояние |
| 2 | `## Задача` | Что делаем — пошагово, с путями к файлам |
| 3 | `## Контракты` | Ожидаемое поведение: API, форматы, коды ошибок |
| 4 | `## Инварианты` | Правила без исключений: лимиты, ограничения, технологии |
| 5 | `## Граничные случаи` | Что при ошибках: edge cases, отказы сервисов |
| 6 | `## Вне scope` | Что НЕ делаем в этой итерации |
| 7 | `## Критерии приемки` | Проверяемые сценарии: "X → видит Y" |