Полный Spec Kit избыточен: три команды Cursor дают ту же дисциплину

GitHub Spec Kit — это набор инструментов для spec-driven разработки с AI-агентами: шаги constitution, specify, plan, tasks, implement, отдельный CLI и каталог .specify/. Звучит солидно, но на практике полный конвейер часто создаёт больше шума, чем пользы. Отдельные plan, tasks и пакетная пересборка множат файлы, повышают риск перезаписать согласованное и раздувают контекст модели без реального выигрыша — особенно если задачи идут по одной, а не целым потоком.

Идея статьи на Хабре простая: не отказываться от методологии, а сжать её до рабочего минимума и встроить прямо в Cursor. Формула — черновик (опционально) → спецификация → согласие человека → реализация. Агент не импровизирует продукт: он опирается на источники (код, тикеты, вики) и согласованную спецификацию, либо явно фиксирует [НЕ ИЗВЕСТНО] / TODO. reasoning_temperature: low на финальной реализации запрещает домыслы по умолчанию.

Что вместо полного конвейера

Три составляющих вместо пяти шагов:

• Rules — .cursor/rules/*.mdc: конституция проекта, запреты, конвейер. Всегда в контексте.
• Skills — три команды: /project-init (однократно: конституция, видение, указатель), /project-specify (черновик → спецификация, обновление фокуса), /project-implement (только после согласия человека: код или публикуемые артефакты).
• Артефакты в репозитории — constitution.md, specs/, feature.json (указатель активной спецификации).

Отдельный tasks.md не нужен. План живёт в видении (крупные пакеты), в контрольном списке внутри каждой спецификации (файлы, разделы, критерии готовности) и в feature.json (что сейчас в фокусе).

Два слоя, которые нельзя смешивать

Первый — смысл: конституция, спецификации, черновики, rules/skills. Второй — результат: код, тесты, публикуемые документы. Пока нет статуса согласия (agreed / согласовано), результат не пишется. Статус выставляет человек — агент сам себе согласие не присваивает. Это, пожалуй, главное правило всего подхода.

Когда упрощённого контура достаточно

Если задачи идут по одной, важно согласование и защита от выдуманных фактов, а отдельные plan / tasks / analyze увеличивают шум без выигрыша — упрощённого контура хватит. Полный Spec Kit целесообразен, когда нужен готовый CLI, стандартный многошаговый конвейер, жёсткие шаблоны артефактов или команда уже работает в экосистеме specify. Подходы совместимы: конституцию и спецификации можно переиспользовать при переходе на полный Spec Kit.

Что меня здесь цепляет

Главный вывод — дисциплина конвейера важнее структуры каталогов. Три skills и правило «не выдумывать факты, не писать результат до согласования» дают 80% ценности Spec Kit без тяжёлой инфраструктуры. Но есть ограничение: подход рассчитан на последовательную работу по одной спецификации. Если у вас параллельный поток задач или большая команда — упрощённый контур может не хватить, и тогда полный Spec Kit с CLI оправдан.

Источник: Все статьи подряд / Искусственный интеллект / Хабр