Spec-Driven Development (SDD) — подход, при котором спецификация становится не побочным документом после разработки, а главным артефактом, из которого ИИ-агент выводит план, задачи и код. Для аналитика это меняет акцент работы: вместо разового промпта «сделай фичу» вы готовите структурированное описание требований, которое агент читает, уточняет и по которому отчитывается. Спецификация здесь ведёт агента, а не наоборот. Ниже разобраны два инструмента с разными акцентами — GitHub Spec Kit и OpenSpec — и роль аналитика в этом цикле.
1. Суть темы
Spec-Driven Development — практика, в которой источником истины для ИИ-агента служит спецификация: описание требований, сценариев и критериев приёмки. Агент не «угадывает» по короткому промпту, а работает по заранее зафиксированному документу и порождает из него план, список задач и реализацию.
Ключевые отличия от разового промпта:
- Спецификация первична. Сначала фиксируются требования и сценарии, затем появляется код.
- Цикл, а не один шаг. Работа идёт по повторяемой последовательности фаз, а не одним запросом.
- Артефакты проверяемы. План, задачи и отчёт о сходимости можно ревьюить до и после написания кода.
- Роль аналитика сохраняется. Требования и критерии приёмки остаются зоной ответственности человека (см. 02.04.02 Критерии приёмки (Acceptance Criteria)).
SDD — это надстройка над обычной работой с требованиями, а не замена форматов документов. Спецификация в SDD часто ближе к лёгкому Markdown-описанию, чем к тяжёлому 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), но логика та же: сначала договориться о «что», потом делать «как».
2. GitHub Spec Kit
GitHub Spec Kit — инструмент, реализующий SDD через CLI specify и набор навыков в чате агента.
Установка и инициализация:
- Требуются Python 3.11+ и
uv. - Установка:
uv tool install specify-cli. - Инициализация проекта:
specify init my-project --integration copilot. - Интеграции включают Copilot, Cursor и другие;
generic— запасной вариант.
Важно: рабочие шаги выполняются навыками в чате агента, а не командами терминала. Терминал используется только для установки и инициализации.
Цикл работы:
| Шаг | Навык | Когда применяется |
|---|---|---|
| Конституция проекта | /speckit-constitution | Один раз на проект |
| Спецификация | /speckit-specify | На каждую фичу |
| План | /speckit-plan | На каждую фичу |
| Задачи | /speckit-tasks | На каждую фичу |
| Реализация | /speckit-implement | На каждую фичу |
| Сходимость | /speckit-converge | На каждую фичу |
Логика цикла: constitution задаётся один раз, затем для каждой фичи повторяется specify → plan → tasks → implement → converge. Пары implement → converge повторяют, пока отчёт не станет Converged.
Расширения (по желанию, отдельные точки входа):
specify extension add bug— циклassess → fix → test, артефакты в.specify/bugs/.specify extension add assess— циклintake → research → define → shape → decide, артефакты в.specify/assessments/.
SDD входит в ядро инструмента. Исправление дефектов и оценка идей — отдельные точки входа, а не обязательные фазы основного цикла.
3. OpenSpec
OpenSpec (проект Fission-AI) — альтернативная реализация SDD. Пакет @fission-ai/openspec, лицензия MIT, требуется Node.js 20.19+.
Установка и работа в проекте:
- Установка:
npm install -g @fission-ai/openspec@latestилиbrew install openspec. - Инициализация в проекте:
openspec init. - Обновление подсказок агента:
openspec update.
Команды выполняются в чате агента. Канонические имена:
| Команда | Назначение |
|---|---|
/opsx:explore | Исследование |
/opsx:propose | Предложение изменения |
/opsx:apply | Применение |
/opsx:archive | Архивирование |
Команда propose создаёт каталог openspec/changes/<name>/ с файлами proposal.md, specs/, design.md, tasks.md.
Спецификация — обычный Markdown с конструкциями Requirement и Scenario (WHEN/THEN). Это близко к логике критериев приёмки и делает требования читаемыми как для человека, так и для агента.
Расширенный профиль добавляет команды /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard. Он включается через openspec config profile и openspec update.
Нюансы:
- В Cursor команда может называться
/opsx-propose; нужную форму печатаетopenspec init. - Stores (beta) — отдельный репозиторий планов для нескольких репозиториев кода.
4. Роль аналитика
В SDD аналитик не пишет код, но определяет то, по чему агент будет работать. Его зона ответственности:
- Требования. Формулировать, что должна делать фича, в виде, пригодном для чтения агентом.
- Критерии приёмки. Задавать проверяемые условия готовности (см. 02.04.02 Критерии приёмки (Acceptance Criteria)).
- Ревью артефактов до кода. Проверять спецификацию, план и задачи до фазы реализации, а не после.
- Проверка сходимости. Следить, чтобы цикл
implement → convergeзавершился отчётом Converged.
Спецификация в SDD — это не разовый промпт, а управляющий документ. Чем точнее аналитик опишет требования и сценарии, тем меньше итераций потребуется агенту. Полезно сочетать это с приёмами 11.03 Промпт-инжиниринг для аналитика и учитывать, как агент встраивается в инструменты команды (11.05 Интеграция LLM с инструментами аналитика).
5. Сравнение инструментов
| Критерий | GitHub Spec Kit | OpenSpec |
|---|---|---|
| CLI | specify | openspec |
| Требования | Python 3.11+, uv | Node.js 20.19+ |
| Инициализация | specify init my-project --integration copilot | openspec init |
| Базовый цикл | specify → plan → tasks → implement → converge | explore → propose → apply → archive |
| Формат спеки | Навыки в чате агента | Markdown: Requirement и Scenario (WHEN/THEN) |
| Расширения | bug, assess | Расширенный профиль команд |
Оба инструмента реализуют одну идею: спецификация ведёт агента, а человек отвечает за требования и приёмку. Выбор между ними — вопрос стека и привычек команды, а не принципиально разной методологии. Сравнение команд и сценарий для аналитика — в 11.11 OpenSpec и Spec Kit — обзор и как ставить задачу агенту.