dd-discovery · git:20260918.6e0b441 · 2026-09-18 · sha256 c39c253ca9843318
dd-discovery git:20260918.6e0b441A
Immutable. This exact content never changes and is served at /api/v1/blob/c39c253ca9843318.
--- 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 не укладывается в ~1000 слов — блок верхнего уровня и есть готовый кандидат на отдельный 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. В этом случае агент может перемещать раздел, но не изменять его содержимое. #### Объём — ориентир ~1000 слов Спеку пишем в одной сессии, реализуем в другой: кодинг-агент в чистой сессии получает только этот документ. Поэтому: - пишем плотно — решения и критерии вместо рассуждений и предыстории; - опираемся на `docs/specs/` ссылкой, а не пересказом: то, что уже задокументировано, не дублируем; - второстепенное — в «Открытые вопросы» или опускаем; - если в ~1000 слов не укладываемся — предложить пользователю разбить фичу на несколько RFC. Заполнить frontmatter: ```yaml --- title: "<название фичи>" status: draft # draft | review | approved | implementing | done created: YYYY-MM-DD --- ``` ### Шаг 5. Сохранить в docs/rfc/ Сохранить файл в `docs/rfc/<slug>.md` (создать папку, если её нет). `<slug>` — короткое имя фичи kebab-case, например: `docs/rfc/user-onboarding.md`. Этот же slug используется на треке delivery и в архиве. ### Шаг 6. Показать результат и предложить действия Вывести готовый RFC в чат и предложить: - Внести правки - Отправить на ревью (перевести статус в `review`) - Начать реализацию → скилл **dd-delivery** (рекомендуется в чистой сессии)