git:20260918.91115dc to git:20260918.fd7a4d0

---

name: dd-discovery

description: Трек Discovery в DD-SDD. Читает контекст проекта и актуальные спецификации из docs/specs/, декомпозирует решение по MECE, излагает его по пирамиде Минто и сохраняет design doc в формате RFC в docs/rfc/.

trigger_phrases:

- "напиши RFC"

- "сделай RFC"

- "опиши фичу"

- "поставь задачу"

- "сделай spec"

- "спецификация"

- "техническое задание"

- "ТЗ"

- "design doc"

- "архитектурный документ"

- "dd discovery"

related_skills:

- dd-sdd

- dd-delivery

---

# dd-discovery

Трек **Discovery**: разобраться в проблеме, опереться на текущее состояние системы, разложить решение на непересекающиеся и полные части и поставить задачу в виде RFC-документа в `docs/rfc/`.

Декомпозиция — основная ответственность этого скилла. Структура RFC строится по MECE (разбиение) и пирамиде Минто (изложение) — см. [Шаг 3](#шаг-3-декомпозировать-решение-mece--пирамида-минто).

## Когда использовать

- Нужно формально описать новую фичу, изменение или архитектурное решение

- Требуется документ, который команда может ревьюить и комментировать

- Нужно зафиксировать требования, объём работ и критерии готовности перед началом реализации

## Workflow

### Шаг 1. Прочитать контекст проекта

Прежде чем задавать вопросы и писать RFC — собрать актуальную картину системы:

- **`docs/specs/`** — прочитать спецификации (включая вложенные Markdown-файлы), относящиеся к предметной области задачи: как всё устроено и работает сейчас, какие решения уже приняты, какая используется терминология.

- **`docs/rfc/`** — посмотреть активные RFC: нет ли пересечений, зависимостей или конфликтов с тем, что уже в работе.

- **`docs/rfc/archive/`** — при необходимости поднять историю: почему в этой области принято текущее решение.

- **Код и конфигурация проекта** — в объёме, достаточном, чтобы RFC описывал реальную систему, а не предполагаемую.

Этот шаг определяет качество RFC: задача ставится от текущего состояния системы, в её терминах, со ссылками на существующие спеки.

Если нашлось противоречие между `docs/specs/` и фактическим кодом — зафиксировать его и показать пользователю: это отдельная находка discovery.

### Шаг 2. Собрать вводные

Запросить у пользователя недостающую информацию. Если пользователь уже дал развёрнутое описание или ответ виден из контекста проекта — не переспрашивать, а подтвердить своё понимание.

**Обязательные блоки:**

1. **Тема/название** — что описывает RFC?

2. **Контекст** — почему это появилось? Какая ситуация сейчас? Что не устраивает?

3. **Цель** — какой конкретный результат нужен? Какие проблемы решаем?

4. **Составляющие** — из каких частей/компонентов/этапов состоит предлагаемое решение?

5. **Критерии готовности** — как понять, что задача сделана? Что можно проверить/протестировать?

6. **Заинтересованные стороны** — кого касается это изменение? Кто будет ревьюить?

**Опциональные уточнения:**

- Сроки / приоритет

- Зависимости / блокеры

- Альтернативы, которые рассматривались

- Риски

- Изменения в других системах

### Шаг 3. Декомпозировать решение: MECE + пирамида Минто

Ответственность за декомпозицию лежит на discovery. Delivery её не исправит: кодинг-агент реализует то, что написано, в той структуре, в которой написано. Плохое разбиение → пропущенные куски работы, пересекающиеся задачи и критерии приёмки, которые невозможно проверить.

Два инструмента: **MECE** — как разбивать, **пирамида Минто** — как излагать.

#### MECE — правило разбиения

MECE (Mutually Exclusive, Collectively Exhaustive) — «взаимно исключающие, совместно исчерпывающие». Метод декомпозиции из практики McKinsey. Любой список в RFC — компоненты решения, этапы дорожной карты, критерии приёмки — должен удовлетворять двум условиям:

- **ME, взаимно исключающие** — пункты не пересекаются: одна зона ответственности описана ровно в одном пункте. Пересечение означает, что одно и то же изменение придётся делать из двух мест, и непонятно, какой пункт считать закрытым.

- **CE, совместно исчерпывающие** — пункты вместе покрывают задачу целиком: выполнили все — цель из раздела «Назначение и цели» достигнута, ничего не провалилось «между пунктами».

Как разбивать:

1. **Одно основание на уровень.** Типовые основания: по слоям системы (данные → API → UI), по шагам пользовательского сценария, по этапам жизненного цикла сущности, по типам сущностей, по состояниям. Выбрать одно, ближайшее к задаче. Смешение оснований в одном списке (часть пунктов — про слои, часть — про сценарии) почти всегда ломает ME.

2. **3–7 пунктов на уровень.** Больше — основание выбрано неудачно или пора выделить подуровень. Меньше двух — разбиения нет.

3. **Проверить ME:** для каждой пары пунктов — есть ли работа, которую можно отнести к обоим? Если да — границу надо провести явно или пункты объединить.

4. **Проверить CE:** пройти по целям RFC и по сценариям пользователя — каждое ли попадает хотя бы в один пункт? Что не попало — либо новый пункт, либо явно вынесено за рамки (в «Составляющие» как ограничение или в «Открытые вопросы»).

Известный пробел CE, который сейчас не закрываем, — это не дыра в декомпозиции, а строка в «Открытых вопросах». Молчаливый пробел — дыра.

**Связь с объёмом.** Если MECE-разбиение верхнего уровня даёт больше 5–7 крупных блоков или RFC не укладывается в ~3000 слов — блок верхнего уровня и есть готовый кандидат на отдельный RFC. Декомпозиция и компактность — одно требование с разных сторон.

#### Пирамида Минто — правило изложения

Пирамида Минто (Barbara Minto, McKinsey): сначала ответ, потом обоснование, потом факты. Документ читается сверху вниз и может быть прерван на любом уровне — читатель уже получил главное. Для RFC это критично: ревьюер должен понять решение из первого экрана, а кодинг-агент — не искать суть в середине текста.

Три правила пирамиды:

1. **Мысль верхнего уровня — резюме мыслей уровнем ниже.** Не анонс («ниже описаны компоненты»), а содержание («делаем X через Y, потому что Z»).

2. **Мысли одной группы — одного типа и одного уровня абстракции.** Это и есть MECE на уровне текста.

3. **Внутри группы — объяснимый порядок:** по времени, по структуре системы, по важности. Порядок должен быть один и тот же во всех разделах: если компоненты перечислены в порядке A, B, C — критерии приёмки и дорожная карта идут так же.

**Вводные пишем по SCQA:**

- **S (Situation)** — что есть сейчас; утверждение, с которым читатель заведомо согласен;

- **C (Complication)** — что изменилось или что мешает;

- **Q (Question)** — вопрос, который из этого следует;

- **A (Answer)** — ответ на него, он же рекомендация RFC.

Ответ — первая содержательная фраза документа, а не вывод в конце. Раздел «Итого и рекомендации» его повторяет, а не раскрывает впервые.

#### Как это ложится на шаблон RFC

Каждый раздел шаблона занимает своё место в пирамиде — и проверяется по своему условию:

- **`## Вводные`** — вершина, ответ A из SCQA. Проверяем: решение названо в первых 1–3 предложениях.

- **`## Назначение и цели`** — обоснование вершины. Проверяем: отвечает «зачем» и «почему сейчас», не пересказывает решение.

- **`## Составляющие и особенности`** — второй уровень, группы-аргументы. Проверяем: MECE-список по одному основанию, 3–7 пунктов.

- **`## Критерии приемки`** — проверяемая проекция второго уровня. Проверяем: каждый компонент закрыт хотя бы одним критерием, критериев без компонента нет.

- **`## Дорожная карта`** — порядок внутри групп. Проверяем: те же блоки в порядке зависимостей, новых сущностей не вводит.

- **`## Итого и рекомендации`** — повтор вершины. Проверяем: согласовано с «Вводными», без новых решений.

- **`### Открытые вопросы`** — осознанные пробелы CE. Проверяем: то, что не удалось закрыть, названо явно.

Разделы «Составляющие», «Критерии приемки» и «Дорожная карта» — три проекции одной и той же декомпозиции. Расхождение между ними (компонент есть, критерия нет; в карте появился шаг, которого нет в составляющих) — дефект декомпозиции, а не оформления.

#### Проверка перед тем, как писать RFC

- [ ] Решение формулируется одной фразой — это вершина пирамиды

- [ ] Компоненты разбиты по одному основанию, 3–7 пунктов

- [ ] Пункты не пересекаются (ME)

- [ ] Пункты покрывают все цели RFC; непокрытое вынесено в «Открытые вопросы» (CE)

- [ ] Каждому компоненту соответствует критерий приёмки, каждому критерию — компонент

- [ ] Порядок пунктов одинаков в составляющих, критериях и дорожной карте

- [ ] Блоков верхнего уровня не больше 5–7 — иначе декомпозировать на несколько RFC

### Шаг 4. Сгенерировать RFC

Составить документ по шаблону: [assets/rfc-template.md](./assets/rfc-template.md), уложив декомпозицию из шага 3 в его разделы.

#### Защищённый раздел «Предпосылки»

RFC может содержать раздел `## Предпосылки`. Если этот раздел есть, он служит авторской отправной точкой и источником контекста для всего RFC.

Содержимое раздела «Предпосылки» могут создавать и изменять только авторы-люди. ИИ-агент обязан:

- читать раздел и учитывать его при подготовке и редактировании остального RFC;

- сохранять его дословно: не изменять, не удалять, не сокращать, не дополнять и не переставлять его содержимое;

- не исправлять внутри раздела ошибки, противоречия или устаревшие сведения;

- выносить вопросы и замечания к предпосылкам в другие разделы RFC или адресовать их авторам.

Если автор передал текст предпосылок отдельно и явно попросил включить его в RFC, агент может вставить этот текст в раздел без редакторских изменений. Самостоятельно формулировать или дополнять «Предпосылки» агент не должен.

Однако этот раздел может двигаться вниз — так, чтобы сверху были те разделы, которые важнее для понимания RFC. В этом случае агент может перемещать раздел, но не изменять его содержимое.

#### Объём — ориентир ~3000 слов

Спеку пишем в одной сессии, реализуем в другой: кодинг-агент в чистой сессии получает только этот документ. Поэтому:

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

- опираемся на `docs/specs/` ссылкой, а не пересказом: то, что уже задокументировано, не дублируем;

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

- если в ~3000 слов не укладываемся — предложить пользователю разбить фичу на несколько RFC.

Заполнить frontmatter:

```yaml

---

title: "<название фичи>"

created: YYYY-MM-DD

---

```

### Шаг 5. Сохранить в docs/rfc/

Сохранить файл в `docs/rfc/<slug>.md` (создать папку, если её нет).

`<slug>` — короткое имя фичи kebab-case, например: `docs/rfc/user-onboarding.md`.

Этот же slug используется на треке delivery и в архиве.

### Шаг 6. Показать результат и предложить действия

Вывести готовый RFC в чат и предложить:

- Внести правки

- Начать реализацию → скилл **dd-delivery** (рекомендуется в чистой сессии)