dd-discovery git:20260918.78b0f46A

Immutable. This exact content never changes and is served at /api/v1/blob/3dfb5dbb58a85403.

---
name: dd-discovery
description: Трек Discovery в DD-SDD. Читает контекст проекта и актуальные спецификации из docs/specs/, формулирует задачу и сохраняет 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/`.

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

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

## 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. Сгенерировать RFC

Составить документ по шаблону: [assets/rfc-template.md](./assets/rfc-template.md)

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

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

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

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

`<slug>` — короткое имя фичи kebab-case, например: `docs/rfc/user-onboarding.md`.
Этот же slug используется на треке delivery и в архиве.

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

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

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