Дисциплина без громоздкости: как внедрить Spec-Driven подход в Cursor без полного развертывания Spec Kit

# Spec Kit без тяжёлого CLI: как адаптировать Spec-Driven подход под свой проект в Cursor

В мире разработки с использованием искусственного интеллекта агенты стремятся к автономности, но это часто приводит к двум проблемам: галлюцинациям (выдумыванию фактов) и потере общего видения проекта. Официальный инструмент Spec Kit от GitHub предлагает элегантное решение через строгий конвейер: конституция проекта, спецификация задачи, план, разбивка на задачи и финальная реализация. Однако полный набор инструментов и командной строки может быть избыточным для небольших команд или проектов, где важен лишь принцип дисциплины, а не сложная инфраструктура.

В этом материале мы рассмотрим, как реализовать суть Spec-Driven Development (SDD) непосредственно в редакторе Cursor, используя его встроенные возможности правил (Rules) и навыков (Skills). Мы создадим минимально жизнеспособный контур, который гарантирует, что агент не начнет писать код до тех пор, пока человек явно не согласует спецификацию задачи.

Философия минимализма: конституция и договорённость

Центральная идея подхода заключается в разделении слоев информации. У нас есть слой управления и смыслов (конституция, спецификации, правила) и слой результатов (код, тесты, публикация). Агент не должен импровизировать продукт; он должен опираться только на источники и согласованные спецификации.

Ключевое правило, которое мы внедряем: без явного согласия человека команда на реализацию (implement) запрещена. Если агент пытается придумать решение «на лету» или игнорирует часть требований, он должен помечать это как [НЕ ИЗВЕСТНО] или TODO, а не выдумывать детали. Для этого в настройках агента (контексте) часто рекомендуется установить низкую температуру (reasoning_temperature: low), чтобы ограничить пространство для случайных домыслов.

Вместо сложного конвейера мы используем простую формулу: > Черновик (по желанию) → Формальная спецификация → Согласование человеком → Реализация

Это не означает полный отказ от спецификаций. Напротив, именно так мы предотвращаем ситуацию, когда ИИ пишет код для несуществующего фича, основываясь лишь на разрозненных комментариях в коде. Спецификация становится юридическим документом проекта, а не просто заметкой.

Архитектура в Cursor: три ключевых компонента

В среде Cursor адаптация подхода строится вокруг трех основных элементов, заменяющих тяжелые скрипты Spec Kit. Мы организуем их в каталоге .cursor или рядом с ним, сохраняя структуру проекта.

1. Правила (Rules): Файлы в папке .cursor/rules/, например project.mdc. Это неизменяемый контекст, который находится в памяти агента постоянно. Здесь мы описываем границы проекта, запреты (например, "не использовать библиотеки X без указания") и синтаксис соглашений. При изменении конституции правила следует синхронизировать с ней. 2. Навыки (Skills): Специализированные скрипты в папке .cursor/skills/. Мы создадим три основных навыка: * project-init: Инициализация проекта, создание конституции и видения. Вызывается один раз в начале. * project-specify: Создание черновика задачи, ее формализация в спецификацию и запрос согласия человека. * project-implement: Генерация кода или артефактов. Доступен только после получения статуса согласия. 3. Указатель активной работы: Файл (например, feature.json), содержащий метку active_spec. Он указывает агенту, на каком документе спецификаций он должен базироваться в текущий момент. Это заменяет необходимость постоянно ссылаться на файлы, предоставляя контекст "фокус-режим".

Структура папок может быть адаптирована, но важно разделять черновики (например, в requirements/), официальные спецификации (в specs/) и итоговый код (в src/).

Процесс работы: от инициализации к коду

Порядок действий в упрощенном контуре выглядит следующим образом:

1. Инициализация: Команда /project-init создается конституция (constitution.md) и файл указателя (feature.json), где определяется первая активная спецификация (обычно обзоровая specs/001-view). Здесь мы фиксируем цель и границы, но не запускаем реализацию. 2. Согласование: Для новой задачи используется /project-specify. Агент генерирует текст спецификации в формате Markdown. Человек редактирует его, закрывает неизвестные факторы (или явно помечает их, если они критичны для блокировки) и ставит статус «agreed» (согласовано). Только этот статус дает зеленый свет. 3. Реализация: После согласования активируется навык /project-implement. Агент генерирует код, используя контекст из спецификации и правил. Если данные отсутствуют, он не выдумывает, а возвращает [TODO] или #FIXME с ссылкой на спецификацию.

Важно: не стоит перезаписывать канон (конституцию) без необходимости. Если проект растет и появляются новые команды, новые правила следует добавлять в существующий канон, а не заменять его.

Когда применять упрощенный контур, а когда полный Spec Kit

Упрощенный контур подходит для: * Малых команд или инди-разработчиков, где важны скорость и минималистичность. * Проектов, где достаточно одного файла спецификации на фичу. * Ситуаций, когда задача идет по одной, и не требуется сложный многошаговый конвейер (без промежуточных планов и задач, которые только увеличивают шум). * Документации продукта, где implement собирает страницы из согласованных документов.

Полноценный Spec Kit целесообразен, если: * Требуется жесткая стандартизация артефактов. * Команда работает в сложной экосистеме с многошаговым конвейером (clarify → specify → plan → tasks → implement). * Необходимо стандартное CLI-интерфейс и автоматизация. * В проекте используются сложные интеграции, где требуется четкое разделение слоёв и управление состоянием.

Оба подхода совместимы: конституцию и спецификации можно легко переиспользовать при переходе на полный Spec Kit, а командную строку и остальные шаги конвейера настроить отдельно.

Заключение

Разворачивать весь функционал Spec Kit не обязательно, чтобы получить дисциплину «спецификация → согласие → реализация». Достаточно конституции проекта, трех навыков в Cursor, указателя активной спецификации и ключевого правила: не выдумывать факты и не писать результат без явного согласования человеком.

Так ведутся два контура: 1. Документация продукта — implement собирает страницы только из согласованных спецификаций. 2. Платформа — тот же каркас, но implement пишет и сопровождает код.

Порядок внедрения прост: инициализация проекта, однократное согласование конституции, затем создание спецификаций. Дисциплина конвейера важнее структуры каталогов.

Контрольные точки для настройки * Замените префикс project в пути к правилам на свой (например, my-app). * Канон спецификаций и видения храните в .cursor/project-spec/. * Фокус на текущей задаче указывайте в feature.json. * Настройка температуры для финальной реализации должна быть низкой (low) для согласованного результата. * Статус согласия (agreed) выставляет человек, а не агент.

Следуя этим принципам, вы получите дисциплину Spec-Driven Development, не перегружая проект лишними инструментами.