Метод, где агент получает спецификацию вместо промпта. Разбираем установку Spec Kit, семь команд процесса, файлы, которые появляются в проекте, и настройку под свою команду.
Spec-Driven Development (SDD) — подход, при котором ИИ-агенту сначала пишут спецификацию задачи, затем технический план, затем список задач, и только потом дают писать код. Открытый набор для этого процесса — Spec Kit: репозиторий в организации GitHub под лицензией MIT, 130 тысяч звёзд, установка через CLI specify. Он добавляет в проект команды /speckit.* и работает больше чем с тридцатью агентами, включая Claude Code. Проверено по документации 20 августа 2026 года.
Что узнаешь из гайда
Часть 1 · Метод
Главное
Спецификация перестаёт быть черновиком. Из неё напрямую вырастает реализация, и правят именно её, а не код.
Обычная работа с агентом выглядит как разговор: человек описывает задачу словами, смотрит на результат, дописывает уточнение, снова смотрит. Замысел живёт в переписке, и через сотню сообщений уже никто не скажет, почему поле называется так, а не иначе. SDD переносит замысел в файлы: документ с требованиями, документ с техническим решением, список задач. Дальше агент работает по ним, а обсуждение возвращается к источнику — правится спецификация, а не готовый код.
Формулировка из README самого проекта звучит резче: десятилетиями код был королём, а спецификации — строительными лесами, которые выбрасывали при начале «настоящей работы». SDD переворачивает порядок: спецификации становятся исполняемыми и прямо порождают рабочую реализацию, вместо того чтобы только направлять её.
| Работа промптами | Spec-Driven Development |
|---|---|
| Замысел в переписке | Замысел в файлах, которые лежат в репозитории |
| Что и как перемешано в одном сообщении | Что и зачем — отдельно, стек и архитектура — отдельным шагом |
| Правки поверх готового кода | Правка спецификации и повторный прогон шагов |
| Проверка глазами в конце | Проверочные шлюзы между шагами: уточнение, чек-лист, анализ |
Чем это отличается от плана в Claude Code
Встроенный режим планирования держит план внутри одной сессии и умирает вместе с ней. SDD выносит план в файлы репозитория: их видит вся команда, они переживают перезапуск агента и попадают в ревью вместе с кодом. Ближайший родственник подхода на сайте — привычка собирать контекст осознанно, а не надеяться на длину окна.
Часть 2 · Установка
Главное
Ставится питоновская утилита specify, дальше одна команда разворачивает процесс внутри проекта.
Требования простые: Python 3.11 или новее и менеджер пакетов uv (документация рекомендует именно его, альтернатива — pipx). Git по докам опционален и нужен только при включённом git-расширении. Официальных каналов раздачи два, оба ведут мейнтейнеры проекта: исходники в репозитории и пакет specify-cli на PyPI.
# из репозитория, с привязкой к тегу релиза
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
# или из PyPI
uv tool install specify-cli
pipx install specify-cli
specify versionДальше проект. Команда specify init раскладывает шаблоны и команды под выбранного агента: в интерактивном терминале он спрашивается списком, в скриптах и агентных обвязках задаётся флагом.
# новый проект под Claude Code
specify init my-project --integration claude
cd my-project
# в текущую папку
specify init .
# для CI и агентных обвязок, чтобы не завис выбор стрелками
specify init my-project --non-interactive --integration claude
specify init --here --force --non-interactive --integration claudeЧем закончится установка у Claude Code
У Claude Code интеграция скиловая: команды приезжают скилами в папку .claude/skills проекта, а не отдельными файлами промптов. Это тот же формат, что у обычных готовых скилов из каталога, поэтому набор Spec Kit спокойно живёт рядом с остальными. У Codex CLI скилы уезжают в .agents/skills и зовутся через $speckit-имя, у Copilot — в .github/skills.
Обновляется утилита своими же командами. specify self check только смотрит, вышел ли новый релиз, и ничего при этом не меняет; specify self upgrade обновляет установку на месте. На дату сверки последний релиз — v0.16.5 от 19 августа 2026 года.
Часть 3 · Процесс
Главное
Семь команд ядра и три проверочные. Короткий маршрут — пять шагов, полный — девять.
Документация предлагает два маршрута. Короткий, для небольших задач: описать, спланировать, разбить, сделать, свериться. Полный, для боевых фич: добавляются конституция проекта в начале и три шлюза качества — уточнение, чек-лист и анализ. Ниже — что делает каждая команда.
| Команда | Что делает |
|---|---|
| /speckit.constitution | Записывает принципы проекта, по которым потом оценивается каждый следующий шаг. Запускается один раз в начале |
| /speckit.specify | Собирает спецификацию из описания на человеческом языке. Здесь только что и зачем, без стека |
| /speckit.clarify | Задаёт точечные вопросы по недосказанному и вшивает ответы в спецификацию. Бывший /quizme, запускать до планирования |
| /speckit.plan | Технический план: стек, архитектура, интерфейсы. Именно сюда относится вся конкретика реализации |
| /speckit.checklist | Генерирует чек-лист качества требований — в документации его называют «модульными тестами для текста» |
| /speckit.tasks | Превращает план в tasks.md — список задач в порядке зависимостей |
| /speckit.analyze | Сверяет спецификацию, план и задачи между собой и сообщает о расхождениях. Ничего не правит сам |
| /speckit.implement | Выполняет задачи в порядке зависимостей. Перед стартом смотрит на непроставленные галки в чек-листах и спрашивает |
| /speckit.converge | Сравнивает получившийся код со спецификацией и дописывает остаток в tasks.md. Повторять, пока не сойдётся |
| /speckit.taskstoissues | Переносит готовый список задач в issues GitHub, если работа ведётся командой |
/speckit.specify Сервис заметок: пользователь заводит заметки, вешает теги,
ищет по тексту. Регистрации на первом этапе нет.
/speckit.plan Next.js на App Router, Postgres, поиск через полнотекстовый индекс.
/speckit.tasks
/speckit.implement
/speckit.convergeСлэш — не универсальный формат
Записи вида /speckit.plan работают у большинства агентов, но не у всех. Codex CLI и Command Code в скиловом режиме зовут те же команды как $speckit-plan, Kimi Code — как /skill:speckit-plan, а GitHub Copilot CLI выбирает агента через /agents. Шаги при этом одинаковые, отличается только запись. Посмотреть, что именно поддерживает ваша версия, можно командой specify integration list. Как вообще устроены собственные слэш-команды агента — в разборе команд Claude Code.
Часть 4 · Что в репозитории
Главное
Спецификация, план, задачи и чек-лист — обычные markdown-файлы. Активную фичу задаёт файл состояния, а вовсе не текущая ветка git.
/speckit.plan./speckit.converge дописывает остаток работы./speckit.specify и /speckit.clarify. Собственные чек-листы остаются за ревьюером — галку ставит человек.Где живёт «текущая фича»
Активная фича записана в .specify/feature.json и переопределяется переменной окружения SPECIFY_FEATURE_DIRECTORY. Команды читают состояние оттуда, а не из текущей ветки git — то есть переключиться на другую фичу одним git checkout не получится, нужно поменять состояние. Нумерованные ветки вида 001-feature-name добавляет опциональное git-расширение, и это отдельная возможность, а не основа механики.
Практический вывод для тех, кто уже держит правила проекта в файле CLAUDE.md: конституция Spec Kit их не отменяет и не дублирует. Конституция отвечает за принципы продукта и инженерные стандарты, файл правил — за то, как агент ведёт себя в этом репозитории. Задачи, вышедшие из /speckit.tasks, удобно сразу отправлять в трекер: команда /speckit.taskstoissues делает из них issues, а дальше работает обычная связка агента с GitHub.
Часть 5 · Настройка
Главное
Расширения добавляют новое, пресеты меняют форму существующего, бандлы ставят готовый набор под роль.
Процесс из коробки — не догма. Если команде нужен свой формат спецификации, обязательная секция по безопасности в плане или чужая терминология, всё это меняется без форка. Три механизма решают три разные задачи.
| Задача | Механизм |
|---|---|
| Добавить команду или целый новый этап | Расширение, specify extension add |
| Поменять формат спецификаций, планов и задач | Пресет, specify preset add |
| Подключить внешний инструмент или сервис | Расширение |
| Выдать роли готовый набор одной командой | Бандл, specify bundle install |
Шаблоны разрешаются во время выполнения, сверху вниз: сначала локальные переопределения проекта в .specify/templates/overrides/, затем пресеты, затем расширения и в самом низу ядро Spec Kit. Первое совпадение выигрывает. Команды расширений и пресетов, наоборот, применяются в момент установки — файлы физически кладутся в папку агента, например в .claude/commands/.
Каталог сообщества — не проверенный магазин
Расширения, пресеты и бандлы в каталоге создают и поддерживают их авторы, а не мейнтейнеры Spec Kit. В README на этот счёт стоит прямое предупреждение: смотрите исходники перед установкой. Разумная гигиена та же, что и с любыми сторонними скилами и наборами команд.
Коротко
specify-cli через uv или pipx, нужен Python 3.11 и новее.specify init --integration claude кладёт команды скилами в .claude/skills; поддерживается больше тридцати агентов./speckit.clarify, /speckit.checklist, /speckit.analyze..specify/feature.json, не в ветке git.Вопросы
Spec-Driven Development — это способ работать с ИИ-агентом через спецификацию, а не через череду промптов. Сначала письменно фиксируется, что и зачем строим, потом отдельным шагом — на чём и как, потом задача разбивается на пункты, и только после этого агент пишет код. В README проекта Spec Kit идея сформулирована так: спецификация становится исполняемой и прямо порождает реализацию, а не просто направляет её.
Нужны Python 3.11 или новее и менеджер пакетов uv, альтернатива — pipx. Инструмент раздаётся двумя официальными каналами: из репозитория командой uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z с тегом релиза и из PyPI командой uv tool install specify-cli. Дальше specify init имя-проекта --integration claude, а проверить установку помогает specify version.
Ядро процесса — семь команд: /speckit.constitution задаёт принципы проекта, /speckit.specify описывает задачу, /speckit.plan выбирает стек, /speckit.tasks разбивает работу на пункты, /speckit.taskstoissues переносит их в задачи GitHub, /speckit.implement выполняет, /speckit.converge сверяет код со спецификацией и дописывает недоделанное. Дополнительно есть /speckit.clarify, /speckit.analyze и /speckit.checklist — это проверочные шлюзы.
Да. В таблице интеграций у Claude Code ключ claude, а сама интеграция скиловая: команды ставятся не файлами промптов, а скилами в папку .claude/skills проекта. Формат вызова у разных агентов отличается — где-то это /speckit.имя, у Codex CLI и Command Code $speckit-имя, у Kimi /skill:speckit-имя. Всего в документации перечислено больше тридцати поддерживаемых агентов.
Рабочие артефакты фичи: spec.md с требованиями, plan.md с техническим решением, tasks.md со списком задач в порядке зависимостей и чек-лист requirements.md. Активная фича хранится в файле .specify/feature.json, и команды берут её именно оттуда, а не из текущей git-ветки — переключение веткой само по себе фичу не меняет. Нумерованные ветки вида 001-feature-name добавляет отдельное git-расширение.
Да, для этого есть три механизма. Расширения добавляют новые команды и возможности через specify extension add, пресеты меняют формат уже существующих шаблонов через specify preset add, бандлы ставят готовый набор под роль одной командой. Шаблоны разрешаются во время выполнения по приоритету: локальные переопределения проекта, затем пресеты, затем расширения и в самом низу ядро Spec Kit.
Читать дальше
Платформа и сообщество, где я по шагам показываю, как поставить ИИ на рутину: контент, код, продажи, аналитика. Заходи и забирай рабочие связки, которыми пользуюсь сам.
Посмотреть, что внутриtelegram
Канал с полезными материалами про нейросети
Разборы, новые инструменты и приёмы по ИИ — то, чем пользуюсь сам, без воды. Подпишись, чтобы не потерять.