43b60d6101
* feat(feature-spec): add SDD-style Q&A skill for feature planning * docs(pr-172): add handoff, ADR-072, update project-map --------- Co-authored-by: opencode-agent <agent@opencode.local>
98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
---
|
||
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" |
|