⚠ TL;DR: лежит здесь ☺
К агентской разработке через спецификации (Spec-Driven Development, SDD), как к работающему способу получить хоть какой-то контроль над gen-AI кодом у себя в проектах, я пришёл чуть раньше, чем на свет появились OpenSpec, Spec-Kit и, тем более, угарный Get-Shit-Done. Таких фреймворков намного больше, перечислил только те, которые прям плотно тестировал, по мере их выхода в свет (из них всех мне больше всего зашел OpenSpec, если что).
Но понимаете, «для Атоса это слишком много, а для графа де Ла Фер — слишком мало». Большинство проектов, над которыми я работаю, во-первых, весьма среднего объема (десятки KLoC максимум), а во-вторых, в них почти всегда research преобладает над development. Попробовать реализовать одну и ту же штуку 3-5 разными подходами, а потом из них собрать один — мой нормальный повседневный воркфлоу. И любое навязывание «ни шагу без спецификации» при «нет, ты не можешь обновлять спеку по коду» этот процесс невероятно замедляет.
Поэтому, последний год, я пользовался примитивным, но достаточно эффективным подходом: одна спека на весь проект + одна команда, позволяющая найти несоответствия между ней и кодом, и устранить их правкой, либо кода, либо спеки. Когда я знал, чего хотел, то просто описывал это в спеке и вызывал команду, в результате которой, агент писал нужный код. Когда не знал, после многочисленных, но в итоге успешных, издевательств над кодом с кучей ручных правок, я снова вызывал команду, и агент корректировал спеку по изменениям в коде.
И это прям здорово работало. До тех пор, пока спека не разрасталась до неприличных объемов, осилить которые, уже не мог, ни агент, ни я сам. Стало понятно, что в таких проектах спеку нужно разбивать на смысловые части, и адаптировать воркфлоу с их учетом.
Так и родился VibeSpec — набор скиллов, позволяющих вести разработку по SDD в условиях постоянного ресерча и спонтанных правок кода без учета спецификаций.
Спецификации делятся 5 на категорий:
1️⃣ meta + index: спека про спеки, индекс для навигации по существующим документам;
2️⃣ architecture: слои, жизненный цикл, модель безопасности и т.п;
3️⃣ domains: фичи, бизнес-логика, инварианты;
4️⃣ contracts: интерфейсы между слоями архитектуры;
5️⃣ decisions: по сути, все ADR'ы, принятые в ходе работы над проектом.
Для работы с ними есть 5 agent-agnostic скиллов:
1️⃣ vibespec-init: первичное построение всех категорий спек по кодовой базе;
2️⃣ vibespec-create: создание новой спеки любой категории;
3️⃣ vibespec-update: обновление уже существующей спеки;
4️⃣ vibespec-check: проверка спек и кода относительно друг-друга и приведение в соответствие;
5️⃣ vibespec-consult: оценка по описанию изменений, какие спеки оно затронет, что сломает и т.п.
Таким образом, после первоначального init, весь воркфлоу сводится к:
consult → create/update → check или(безудержный [вайб-]кодинг) → check.И главное, никаких навязанных шагов по spec-first, которые нельзя было бы сделать позднее, после финальных изменений в очередной фиче.
Вот так это выглядит в пет-проекте, над которым сейчас работаю:
specs
├── architecture
│ ├── data-flow.md
│ ├── layers.md
│ └── security-model.md
├── contracts
│ ├── backend-core.md
│ ├── core-sdk.md
│ ├── desktop-frontend.md
│ └── event-catalog.md
├── decisions
│ ├── _template.md
│ ├── 001-single-module.md
│ ├── 002-sdk-isolation.md
│ └── 003-cgo-free-sqlite.md
├── domains
│ ├── frontend
│ │ ├── events.md
│ │ ├── README.md
│ │ ├── rendering.md
│ │ └── stores.md
│ ├── llm-providers.md
│ ├── memory
│ │ ├── blackboard.md
│ │ ├── compaction.md
│ │ └── README.md
│ ├── orchestration
│ │ ├── executor.md
│ │ ├── planner.md
│ │ ├── README.md
│ │ └── router.md
│ ├── session-lifecycle.md
│ ├── tool-system
│ │ ├── builtins.md
│ │ ├── mcp-gateway.md
│ │ └── README.md
│ └── workspace.md
├── INDEX.md
└── META.md
Всё 🙌
#ИИ_инструменты