От намерения к спецификации: intent.md и spec.md

В традиционном процессе идея проходит через запись в бэклоге, пользовательские истории, оценки и груминги, и на каждой передаче часть смысла теряется: до инженера доезжает пересказ пересказа. Первые два этапа цикла устроены иначе: автор идеи, кем бы он ни был, в разговоре с агентом получает файл намерения intent.md, а владелец продукта (product owner) утверждает его коммитом за часы, без недель сбора требований.

Инженер на этих этапах не нужен. Оператор поддержки, аналитик, менеджер описывают проблему своими словами, и структуру из этих слов делает агент.

Что такое intent.md: протоспецификация словами автора

intent.md фиксирует, зачем нужна работа и что должно измениться, ещё без ответа «как». Шаблон организации задаёт пять полей:

# Намерение: короткое имя изменения

## Проблема
Кто и обо что спотыкается, словами автора идеи.

## Желаемый результат
Что изменится для пользователей, когда всё получится.

## Затронутые пользователи и системы
Роли, сервисы и интеграции, которых коснётся изменение.

## Ограничения
Что нельзя трогать: данные, регуляторика, сроки.

## Открытые вопросы
Что автор не знает и оставляет проектированию.

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

Пять шагов от разговора до коммита

1. Автор рассказывает о проблеме агенту обычным текстом, как коллеге.
2. Агент задаёт уточняющие вопросы: границы, пользователи, ограничения, критерии успеха.
3. Агент собирает черновик по шаблону организации. Шаблон оформлен как скил: страница «Скилы» приводит «Шаблон постановки задачи» как типовой пример, и intent.md его прямое развитие.
4. Автор правит черновик, пока текст не начнёт говорить его словами.
5. Файл коммитится в репозиторий с автором и меткой времени.

Разговор занимает минуты, и на выходе структурированный документ вместо строчки в бэклоге «сделать статусы заявок».

Где живёт и кто утверждает

Файлы намерений лежат в папке intent/ продуктового репозитория, рядом с кодом, который они предлагают менять. Отдельный репозиторий под намерения нужен только организациям с множеством продуктовых репозиториев.

Решение по намерению принимает владелец продукта, и оно тоже оформлено средствами git: принятие это слияние, отказ это закрытие с комментарием. Спустя год видно, кто предложил идею, в каком виде она была принята и почему отклонены соседние.

Одна сессия до spec.md

Утверждённое намерение превращается в спецификацию spec.md за одну сессию: владелец продукта прикладывает intent.md и просит агента собрать требования и проектные решения для существующей кодовой базы.

Ключ этого этапа в скилах организации, подключённых к сессии: правила бренда, требования безопасности, регуляторные ограничения, стандарты интерфейса. Агент применяет их прямо при генерации, поэтому конфликт с политикой всплывает сразу, а не через недели на ревью у юристов. Спорные места агент помечает, и владелец продукта разбирает их с владельцами политик до подключения инженеров.

intent.md и spec.md коммитятся вместе, парой «что просили» и «что спроектировали». Полезно фиксировать рядом и версии скилов, по которым собиралась спецификация: тогда понятно, по каким правилам она проверялась.

Метрики этапа: часы вместо недель

• Опережающая. Время от первого разговора до закоммиченного intent.md и от намерения до spec.md. Считается по меткам времени коммитов; цель измеряется часами там, где сбор требований занимал недели.
• Запаздывающая. Доля намерений, доживших до проектирования (по истории слияний), и правки спецификации после начала сборки: коммиты в spec.md позже первого plan.md означают, что требования переделываются задним числом.

Что это меняет для аналитика и владельца продукта

Для аналитика это знакомая работа в новом масштабе: сценарии «черновик требований из заметок встречи» и «постановка задач по шаблону» со страницы Трек аналитика перестают быть личным приёмом и становятся процессом всей команды. Роль смещается от записи требований к их проверке на полноту и противоречия.

Для владельца продукта intent.md и spec.md образуют очередь решений: вместо участия в каждой передаче между людьми он читает два коротких документа и в двух точках говорит «да» или «нет», оставляя след в истории.

Совет

Начните с одного файла. Возьмите последнюю идею, которая лежит в бэклоге строчкой без подробностей, опишите её агенту и попросите оформить по шаблону выше. Разница между строчкой и получившимся документом и покажет цену этапа.

Что дальше

• Сборка и проверка: что происходит со спецификацией на этапах Build и Test.
• Скилы: как оформить шаблон намерения и политики организации.
• Трек аналитика: сценарии работы с требованиями внутри одной сессии.