Spec Kit, BMAD и GSD: разработка по спецификации

Spec Kit лежит в организации GitHub и распространяется под лицензией MIT. Проект придумали Ден Делимарский (Den Delimarsky) и Джон Лэм (John Lam), первый коммит появился 21 августа 2025 года. С января 2026 года ведущий мейнтейнер Манфред Рим (Manfred Riem), версия 1.0 вышла ровно через год после первого коммита, текущая 1.2.3 от 22 октября. В сентябре автор поста в X насчитал у репозитория 136 тысяч звёзд, 24 октября GitHub показывал 142,7 тысячи.

Рядом с Spec Kit обычно называют ещё два фреймворка, BMAD Method и GSD. Все три обещают, что агент перестанет угадывать, что вы имели в виду, потому что сначала появляется спецификация, а код потом. Здесь описано, как поставить Spec Kit и пройти первый проект, чем от него отличаются BMAD и GSD и почему Мэтт Покок советует обходиться без таких фреймворков.

Что такое разработка по спецификации

Обычный вайбкодинг начинается с промпта вроде «сделай мне приложение для задач», и агент сам решает всё, о чём вы промолчали. Spec-driven development (SDD) переворачивает порядок. Сначала вы описываете, что строите и зачем, потом выбираете стек, потом получаете план и список задач, и только после этого агент пишет код. Документация Spec Kit формулирует цель так: спецификации становятся исполняемыми и сами порождают реализацию.

В Spec Kit этот путь разбит на шаги с собственными командами. Конституция задаёт принципы проекта один раз. Specify описывает фичу, plan выбирает технологии, tasks режет план на задачи, implement их выполняет, а converge сверяет код со спецификацией. Между ними можно вставить три проверки: clarify, checklist и analyze.

Как устроен Spec Kit

Spec Kit состоит из консольной утилиты specify на Python и набора скилов, которые она кладёт в проект. В Claude Code это .claude/skills/speckit-<команда>/SKILL.md, и вызываются они как /speckit-specify. В Codex скилы попадают в .agents/skills/, а вызов идёт через доллар: $speckit-specify. В справочнике и старых гайдах встречается запись через точку, /speckit.specify, это тот же шаг.

Все результаты лежат в файлах. Конституция живёт в .specify/memory/constitution.md, у каждой фичи своя папка вида specs/001-photo-albums/ с файлами spec.md, plan.md, research.md, data-model.md, tasks.md и папкой contracts/. Активную фичу Spec Kit помнит в .specify/feature.json, а не по git-ветке, так что git для работы не обязателен.

Кроме SDD в комплекте есть расширения для починки багов (specify extension add bug) и для оценки идей (specify extension add assess). Их можно запускать без спецификации.

Установка

Нужны Python 3.11 или новее, менеджер пакетов uv и сам агент. Для нового проекта под Claude Code:

uv tool install specify-cli
specify init my-project --integration claude
cd my-project

Для Codex флаг будет --integration codex. В существующем репозитории документация советует сначала закоммитить работу, а потом выполнить specify init --here --force --integration claude: флаг --force может перезаписать файлы на управляемых путях, но код приложения не трогает.

Если у вас уже стоит старый specify, проверьте версию командой specify version. CLI версии 0.1.6 не знает флага --integration, а старый флаг --ai с текущими релизами не работает. Обновлять нужно тем же инструментом, которым ставили: uv tool install --force specify-cli.

По умолчанию каждый скил Spec Kit в Claude Code может вызываться моделью сам, поэтому его описание всегда сидит в контексте и занимает место в списке скилов. Если скилов в проекте много, документация предлагает опцию --integration-options="--no-model-invocation": тогда шаги запускаются только вашей командой. Как Claude Code выбирает скилы по описаниям, мы разбирали в статье о скилах.

Первый проект по шагам

Возьмём пример из документации: приложение для фотоальбомов. Каждую команду запускают в чате агента по одной и читают результат перед следующей.

/speckit-constitution Create principles focused on code quality, testing, and maintainability.
/speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album.
/speckit-clarify
/speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite.
/speckit-tasks
/speckit-analyze
/speckit-implement
/speckit-converge

Первое: конституция. Вы перечисляете принципы, агент заполняет шаблон, а дальше шаблон плана содержит раздел Constitution Check. Это ворота, которые план обязан пройти до исследования и ещё раз после проектирования. Нарушение принципа нужно обосновать письменно.

Второе: спецификация. В /speckit-specify описывают поведение и цели, стек сюда не пишут. Агент создаёт spec.md и ставит пометки [NEEDS CLARIFICATION] там, где не может решить сам, но не больше трёх на документ. Третье: /speckit-clarify задаёт до пяти точечных вопросов и вписывает ваши ответы обратно в спецификацию. Запускать его можно несколько раз, каждый раз по новой теме.

Четвёртое: план. Только здесь вы называете технологии. Агент сначала закрывает неизвестные в research.md, потом пишет модель данных, контракты и quickstart.md. Пятое: /speckit-tasks строит tasks.md, где задачи идут фазами: подготовка, фундамент, по фазе на каждую пользовательскую историю и финальная полировка. Задачи, которые можно делать параллельно, помечены.

Шестое: /speckit-analyze читает спецификацию, план и задачи и сообщает о противоречиях, например о задаче без требования. Файлы он не правит, исправлять нужно на том шаге, которому принадлежит ошибка. Седьмое: /speckit-implement выполняет задачи по порядку. Для большой фичи документация советует идти частями, чтобы не перегрузить контекст агента: сначала подготовку и фундамент, потом одну историю за раз. Восьмое: /speckit-converge сверяет код с артефактами. Код он не трогает, а найденные пробелы дописывает в tasks.md новыми задачами. Цикл implement и converge повторяют, пока не придёт ответ «Converged».

Для маленькой фичи хватает короткого пути: specify, plan, tasks, implement, converge.

BMAD: команда агентов с именами

BMad Method от компании BMad Code собрал 54,5 тысячи звёзд. Его главное отличие в ролях. Шесть агентов носят имена: аналитик Мэри, продакт-менеджер Джон, продакт-оунер София, архитектор Уинстон, разработчик Амелия и UX-дизайнер Салли. Агента загружают его скилом, например bmad-agent-architect, и дальше выбирают работу из меню короткими кодами. Скил bmad-party-mode собирает всех в одном разговоре, чтобы они спорили о решении в своих ролях.

Процесс BMAD подстраивается под размер задачи. Центральный скил bmad-build рассчитан примерно на 500 строк изменений в нескольких файлах за сеанс. Он изучает код и документы, называет пробелы в задаче, необратимые действия и масштаб изменений. Если всё чисто, он пишет короткий план и сразу берётся за код, иначе сначала готовит полный план и ждёт вашего утверждения. Потом реализует, отдаёт результат независимым ревьюерам и коммитит локально. Всё, что не относится к задаче, уходит в deferred-work.md. Задачи крупнее проходят через бриф, PRD, архитектуру и нарезку на истории.

Стабильная ветка 6.12 ставится командой npx bmad-method install. Ветка 7 пока в альфе: README обещал релиз около 16 октября, но 24 октября последним релизом всё ещё была 6.12.4. Для Claude Code седьмая версия ставится плагином:

/plugin marketplace add bmad-code-org/bmad-plugins

Из маркетплейса ставят bmad-method и bmad-core-tools, затем просят скил bmad выполнить bmad setup.

GSD: свежий контекст на каждую фазу

GSD (Get Shit Done) начинал автор под ником TÂCHES в репозитории gsd-build/get-shit-done. 31 мая 2026 года этот репозиторий с 64 тысячами звёзд архивировали, разработка продолжается как GSD Core в организации open-gsd: 10,8 тысячи звёзд, версия 1.18.0 от 19 октября. Гайды с командой npx get-shit-done-cc относятся к старому репозиторию.

GSD борется с context rot, деградацией качества по мере заполнения контекстного окна. Работа идёт фазами по циклу из пяти шагов: /gsd-discuss-phase фиксирует решения, /gsd-plan-phase режет работу на проверяемые планы, /gsd-execute-phase выполняет их волнами, /gsd-verify-work проверяет сделанное вместе с вами, /gsd-ship открывает пул-реквест. Тяжёлую работу делают субагенты, каждый со свежим контекстом в 200 тысяч токенов, а память между ними хранится в папке .planning/ в файлах вроде STATE.md и CONTEXT.md. Про этот приём подробнее в статье о субагентах.

npx @opengsd/gsd-core@latest --claude --local

После установки и перезапуска Claude Code новый проект начинают с /gsd-new-project, существующий с /gsd-onboard. Учебник GSD предлагает запускать агента с --dangerously-skip-permissions, но сам оговаривает, что только для одноразовой папки.

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

Возражение Мэтта Покока

Мэтт Покок в README своих скилов называет все три подхода по именам:

Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process.

По его словам, такие фреймворки забирают у разработчика контроль, а ошибки в самом процессе становится трудно исправить. 22 октября он написал, что центром вселенной должен быть код, а не спецификация, и в тот же день предложил заново договориться, что вообще называть SDD, потому что термин размылся. При этом спецификации Покок не отвергает: в его наборе есть /to-spec и /to-tickets. Спор идёт о том, кто управляет процессом: вы, собирая его из маленьких скилов, или фреймворк со своими шагами и папками.

Авторы фреймворков отчасти согласны. В документации GSD есть раздел о компромиссах: цикл фаз добавляет трение и задержки, а для переименования переменной он избыточен, поэтому есть /gsd-quick и /gsd-fast. BMAD прямо пишет, что для очевидной правки с низким риском он не нужен.

Что забрать, даже если не ставить

Несколько приёмов переносятся в свой CLAUDE.md почти без изменений. Разделяйте «что» и «как»: в описании задачи нет стека, стек появляется в плане. Ограничивайте открытые вопросы: Spec Kit разрешает не больше трёх пометок в спецификации и пяти вопросов за раунд. Держите отдельный проход сверки, который сравнивает код с требованиями и только дописывает задачи. Складывайте посторонние находки в файл вместо того, чтобы чинить их по ходу. Например, так:

## Перед кодом
Опиши, что должно работать и что не должно измениться, без технологий. Технологии выбирай в плане отдельным шагом.

## После кода
Сверь результат с требованиями. Пробелы допиши задачами в tasks.md, код при сверке не меняй.

## Посторонние проблемы
Всё, что не относится к задаче, запиши в deferred-work.md и не исправляй.

Как писать такие правила, чтобы агент их соблюдал, мы разбирали в статье «Что писать в AGENTS.md».

Когда процесс окупается