---
name: dd-sdd
description: Discovery–Delivery Spec-Driven Development — AI SDLC через спецификации. Два скилла: dd-discovery (читает контекст проекта и docs/specs/, декомпозирует решение по MECE и пирамиде Минто, ставит задачу в RFC в docs/rfc/), dd-delivery (реализует по RFC с тестами, дописывает в RFC тест-инструкции, обновляет docs/specs/, уносит RFC в архив).
trigger_phrases:
  - "dd-sdd"
  - "sdd"
  - "spec driven"
  - "spec-driven"
  - "discovery"
  - "delivery"
  - "спека"
  - "спецификация"
  - "rfc"
  - "напиши RFC"
  - "design doc"
  - "техническое задание"
  - "ТЗ"
  - "опиши фичу"
related_skills:
  - dd-discovery
  - dd-delivery
---

# DD-SDD — Discovery–Delivery Spec-Driven Development

AI SDLC: работа с фичами и изменениями через спецификации, в двух треках dual-track agile.

```
dd-discovery            →            dd-delivery
(контекст проекта + docs/specs/    (реализация по RFC, тесты, тест-инструкции
 → задача в RFC в docs/rfc/)        в RFC, обновление docs/specs/, архив RFC)
```

1. **Discovery** — читаем контекст проекта и актуальные спеки, формулируем проблему и цели, раскладываем решение по MECE и излагаем по пирамиде Минто, задаём критерии приёмки → RFC в `docs/rfc/`
2. **Delivery** — реализуем по RFC, покрываем тестами, дописываем в RFC раздел «Тест инструкции», приводим `docs/specs/` в соответствие с фактом, RFC уходит в `docs/rfc/archive/`

Обратная связь из delivery возвращается в discovery: отклонения от RFC и находки становятся входом для следующей итерации.

## Скиллы

| Задача | Скилл | Инструкции |
|--------|-------|------------|
| Поставить задачу: контекст проекта → RFC | `dd-discovery` | [./skills/dd-discovery/SKILL.md](./skills/dd-discovery/SKILL.md) |
| Реализовать по RFC: код, тесты, тест-инструкции, спеки, архив | `dd-delivery` | [./skills/dd-delivery/SKILL.md](./skills/dd-delivery/SKILL.md) |

## Принцип компактности: RFC ≈ 1000 слов

RFC стараемся укладывать в ~1000 слов. Это ориентир, а не жёсткий лимит.

Базовый паттерн работы — **две сессии**: в одной пишем сжатую спецификацию (discovery), в чистой сессии скармливаем её кодинг-агенту (delivery). Компактный RFC — это весь контекст, который получает исполнитель: без шума и истории переписки.

- Пишем плотно: решения и критерии — вместо рассуждений и предыстории.
- То, что уже описано в `docs/specs/`, даём ссылкой, а не пересказом.
- Второстепенное — в «Открытые вопросы» или опускаем.
- Не укладываемся в ~1000 слов — сигнал декомпозировать фичу на несколько RFC.

## Принцип структуры: MECE + пирамида Минто

RFC строится как результат декомпозиции, а не как рассказ. За это отвечает **dd-discovery**.

- **MECE** (Mutually Exclusive, Collectively Exhaustive) — как разбивать: части решения не пересекаются и вместе покрывают задачу целиком. Одно основание разбиения на уровень, 3–7 пунктов.
- **Пирамида Минто** — как излагать: сначала ответ (рекомендация), затем обоснование, затем детали. Вводные пишутся по SCQA.

Составляющие, критерии приёмки и дорожная карта — три проекции одной декомпозиции: расхождение между ними означает, что декомпозиция не сделана.

Подробные правила и чек-лист: [./skills/dd-discovery/SKILL.md](./skills/dd-discovery/SKILL.md), шаг 3.

## Конвенции

- Все пути — относительно корня проекта, в котором идёт работа.
- Активные RFC: `docs/rfc/<slug>.md`
- Архив RFC: `docs/rfc/archive/<slug>.md`
- Актуальные спеки: `docs/specs/<slug>.md`
- `<slug>` — короткое имя фичи kebab-case, одинаковое на всех этапах цикла.
- Статус жизненного цикла хранится во frontmatter RFC: `draft → review → approved → implementing → done`

## Маршрутизация

- «напиши RFC», «опиши фичу», «сделай спеку», «ТЗ», «поставь задачу» → **dd-discovery**
- «начинаем делать», «реализуем по RFC», «возьми в работу» → **dd-delivery**
- «завершаем», «фича готова», «перенеси в архив», «закрой спеку» → **dd-delivery** (шаги 8–9)

Если непонятно, на каком этапе фича — посмотреть статус во frontmatter файла в `docs/rfc/`.