Часть 2. Как с этим помогает openspec

Привет еще раз! В первой части разобрались, зачем вообще дробить задачу на контуры. Теперь про то, как это удобно собрать в одну систему.

С этим всем отлично справляется openspec. Достаточно простая система, которая работает со спецификациями (это и есть результаты на каждом контуре). Задачу можно даже довести до определенного контура и передать другому сотруднику, и ему не придется с нуля делать всё, а можно будет продолжить с того контура, на котором вы остановились.

Что делает openspec? Он как раз формирует спецификации на каждом этапе. У него есть отличные скилы, которые помогают вам в наполнении этих спецификаций. Например, explorer поможет вам проанализировать задачу до старта написания кода. Это нужно, когда у вас есть размытое описание и нужно что-то сделать. Далее он предлагает вам постановку задачи, и ее можно будет перекинуть в новый скил propose. На этом этапе он анализирует бизнес-требования пользователя и формирует техническое предложение в виде md-файла. Вы его ревьюите и переходите на следующий этап — apply. Он переводит агента в строгий рабочий режим «прочитал задачу ➔ написал код ➔ протестировал ➔ валидировал». Опять ревью, и уже можно завершать работу над задачей путем перевода задачи в архив.

Все эти процессы попутно записывают спецификации в вашу репу. Получается тот самый забытый, но в последнее время актуальный подход в разработке — SDD.

На самом деле для старта openspec достаточно в базовом виде. Дальше вы его будете докручивать на каждом этапе своими скилами и правилами.

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

А вы как переносите контекст между сессиями? Пользуетесь openspec или придумали что-то свое? Пишите в комментариях👇