Spec Driven Development

В выходные в дополнение к своему скиллу Mindmap сделал достаточно мощный SDD (Spec Driven Development) фреймворк по типу SpecKit и OpenSpec.

И вот после написания, активно погоняв его на работе и не только - вижу, что фреймворк получился очень годным и его не стыдно показать!

Зачем SDD?

Сначала отвечу на вопрос «зачем же он вообще?»

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

Конечно же я смотрел на эти два мощных фреймворка и старался взять из них самое лучшее, упростить где сложно и сделать лаконичнее там где нужно было.

И вот что получилось.

Как его ставить

Поскольку это просто пакет скиллов из моего репозитория https://gitrepo.ru/neonxp/skills то ставить его так же, как и mindmap , а именно одним из двух способов:

1. Скриптом curl -fsSL https://gitrepo.ru/neonxp/skills/raw/branch/master/install.sh | sh -s -- sdd
2. Через агента таким промптом:

   Склонируй https://gitrepo.ru/neonxp/skills во временную директорию и установи мне набор sdd (и другие: mindcode, task опционально), следуя README.md этого репозитория: `./install.sh sdd`, а если моему агенту нужен симлинк (список — `./install.sh --list`) — добавь `--agents "Имя"`. В конце отчитайся: что и куда установлено.
   

Всё! :)

Описание

Процесс разбит на 6 этапов:
1. /spec-1-specify создаёт спецификацию новой фичи. Например, /spec-1-specify нужна новая фича которая должна делать ABC, DEF и XYZ . При этом агент сам проведёт исследование кодовой базы, распросит пользователя о моментах которые ему непонятны или требуют уточнения и подготовит спецификацию по специальному шаблону в директории specs/номер-суффикс/spec.md. Это, по сути, самый важный этап!
2. /spec-2-plan создаёт план решения задачи по спеке. После, даёт пользователю на ревью.
3. /spec-3-tasks уже в свою очередь нарезает полученный план на конкретные задачи для агента. Здесь и уточняются уже самые технические детали реализации.
4. /spec-4-implement стадия на которой агент приступает непосредственно реализации спеки с учётом всех предыдущих шагов автономно имея на руках полный контекст и принятые решения.
5. /spec-5-verify после имплементации следует заставить агента ещё раз перепроверить свою работу и что все требования были учтены и корректно реализованы.
6. /spec-6-archive после полного завершения работы - спека архивируется, то есть переходит в директорию specs/archive затем, чтобы в последующих спеках агент мог в том числе, если ему нужно, обращаться к старым спекам и понимать причины тех или иных технических решений. Ну а в случае «greenfield» проекта - эта директория буквально сама по себе источник истины ко всему проекту :)

Как можно заметить - все шаги пронумерованы и запутаться (как я постоянно путался в SpecKit!) уже не получится. Это такая моя маленькая новация. Кроме того, агент ещё и явно проговаривает в конце шага, какой шаг вызвать следующим и для чего.

Эти скиллы хорошо дружат со скиллом Mindmap в том, что если у проекта есть сгенерированая Mindmap по скиллу mindmap-init - то при исследовании для создания спеки он в первую очередь посмотрит её, чтобы сэкономить ресурсы на повторный разбор проекта.

Так же, в каждый шаг заложено, что если у проекта есть в корне файл rules.md, который может содержать любые правила принятые в конкретном проекте / команде, то эти правила могут целиком или частично переопределять поведение spec-* скиллов. Например, можно указать что какие-то шаги не делать, а какие-то шаги, наоборот, требуют дополнительных действий.

Ну и из приятностей, в директории specs/ генерируется файл dashboard.html в котором удобно смотреть как текущий этап, так и принятые решения (на скриншоте в начале статьи).