git:20260918.91115dc to git:20260918.fd7a4d0

---

name: dd-sdd

description: Discovery–Delivery Spec-Driven Development — AI SDLC через спецификации. При запуске проверяет готовность проекта (AGENTS.md, docs/rfc/, docs/specs/, симлинки треков) и спрашивает, с какого трека начинать. Два скилла: 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 и находки становятся входом для следующей итерации.

## Шаг 0. Preflight: проверить готовность проекта

При запуске `dd-sdd` — до вопросов по фиче — проверить, что в проекте есть всё, на что опирается цикл:

```bash

for p in AGENTS.md CLAUDE.md docs/specs docs/rfc docs/rfc/archive \

.agents/skills/dd-discovery .agents/skills/dd-delivery; do

[ -e "$p" ] && echo "есть $p" || echo "НЕТ $p"

done

ls docs/rfc 2>/dev/null

```

Каталог скиллов — тот, в котором установлен `dd-sdd` (`.agents/skills/` или `.claude/skills/`).

Что проверяем и зачем оно нужно:

- `AGENTS.md` (или `CLAUDE.md`) — контекст проекта для агента: стек, команды, конвенции. Без него RFC пишется «в вакууме».

- `docs/specs/` — актуальные спеки: вход discovery и выход delivery.

- `docs/rfc/` — активные RFC: выход discovery и вход delivery.

- `docs/rfc/archive/` — история принятых решений.

- Симлинки `dd-discovery` и `dd-delivery` в каталоге скиллов — без них треки не поднимаются по триггер-фразам.

### Если чего-то нет

Молча не создавать. Показать одним сообщением, чего не хватает и почему это нужно, и предложить команды:

```bash

mkdir -p docs/rfc/archive docs/specs

ln -s dd-sdd/skills/dd-discovery .agents/skills/dd-discovery

ln -s dd-sdd/skills/dd-delivery .agents/skills/dd-delivery

```

`AGENTS.md` шаблоном не создаётся: предложить собрать его по проекту (стек, как запускать, как тестировать, конвенции) — это отдельная работа, которую пользователь подтверждает явно.

Ничего из этого не блокер:

- нет симлинков — треки читаются по относительным путям `./skills/dd-discovery/SKILL.md` и `./skills/dd-delivery/SKILL.md`;

- пустые `docs/specs/` и `docs/rfc/` — нормальное состояние нового проекта;

- нет `AGENTS.md` — контекст собираем из кода, но в RFC отмечаем, что проектного контекста не было.

Пользователь отказался что-то заводить — продолжаем, повторно не предлагаем.

### Если всё на месте

Показать, что лежит в `docs/rfc/` (slug + `status` из frontmatter), и спросить, с какого трека начинаем:

- **Discovery** — пишем RFC на новую фичу → `dd-discovery`

- **Delivery** — реализуем существующий RFC → `dd-delivery`

Активных RFC нет — delivery начинать не с чего, предлагать только discovery. Активных RFC несколько — сразу уточнить, какой берём в работу.

Пользователь уже назвал трек в первом сообщении («напиши RFC», «делаем по RFC») — не переспрашивать: сделать preflight и сразу передать в нужный скилл.

## Скиллы

### `dd-discovery` — поставить задачу

Контекст проекта и `docs/specs/` → RFC в `docs/rfc/`.

Инструкции: [./skills/dd-discovery/SKILL.md](./skills/dd-discovery/SKILL.md)

### `dd-delivery` — реализовать по RFC

Код, тесты, тест-инструкции, обновление спек, архив RFC.

Инструкции: [./skills/dd-delivery/SKILL.md](./skills/dd-delivery/SKILL.md)

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

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

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

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

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

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

- Не укладываемся в ~3000 слов — сигнал декомпозировать фичу на несколько 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, одинаковое на всех этапах цикла.

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

Сначала — preflight (шаг 0), затем трек:

- «напиши RFC», «опиши фичу», «сделай спеку», «ТЗ», «поставь задачу» → **dd-discovery**

- «начинаем делать», «реализуем по RFC», «возьми в работу» → **dd-delivery**

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

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