git:20260918.6e0b441 to git:20260918.acb1abf

---

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

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

- Пишем плотно: решения и критерии — вместо рассуждений и предыстории.

- То, что уже описано в `docs/specs/`, даём ссылкой, а не пересказом.

- Второстепенное — в «Открытые вопросы» или опускаем.

## Принцип структуры: 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/`.