feat(feature-spec): add SDD-style Q&A skill for feature planning (#172 )

* 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>

2026-07-31 19:58:12 +03:00

5.2 KiB

Raw Blame History

name	description
feature-spec	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", "спецификация фичи".

name

description

feature-spec

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"

5.2 KiB Raw Blame History Unescape Escape