Типичный сценарий без SDD: вы пишете Claude Code «Добавь авторизацию через OAuth», получаете 300 строк кода, начинаете уточнять… Контекст растёт, в истории чата уже 20 сообщений, и непонятно, что в итоге решили. Через неделю — или даже через два часа — логику принятых решений уже не восстановить.

SDD (Spec-Driven Development, спец-ориентированная разработка) разрывает этот паттерн. Здесь спека — главный артефакт: Claude Code читает структурированный markdown-файл до того, как написать хоть строчку кода. Не история чата, а файл становится источником правды.

Важная деталь: перед генерацией спеки Claude Code исследует кодовую базу. Поэтому спека отражает реальное состояние проекта, а не абстрактные пожелания.

Цикл SDD строго линейный — каждая фаза порождает артефакт, который кормит следующую:

flowchart TD
    C["constitution.md — принципы"]
    A["SPEC — spec.md"]
    B["PLAN — plan.md"]
    D["TASKS — tasks.md"]
    E["IMPLEMENT"]
    C -->|"задаёт стандарты"| A
    A -->|"clarify → plan"| B
    B -->|"tasks"| D
    D -->|"implement"| E
    E -.->|"analyze"| A
    style C fill:#f3e8ff,stroke:#8b5cf6
    style A fill:#dbeafe,stroke:#3b82f6
    style B fill:#dcfce7,stroke:#16a34a
    style D fill:#fef3c7,stroke:#d97706
    style E fill:#fee2e2,stroke:#dc2626

spec.md отвечает на два вопроса: что мы строим и зачем. Здесь — user stories, бизнес-правила, ограничения, критерии готовности. Никаких технологических решений: ни «используем PostgreSQL», ни «хэшируем через bcrypt».

Пример корректных пунктов в spec.md:

- Незарегистрированный пользователь не может просматривать чужой профиль.
- При трёх неверных попытках входа аккаунт блокируется на 15 минут.
- Пользователь видит понятное сообщение при каждой ошибке входа.

plan.md — это техническое «как». Архитектура, стек, data-model, API-контракты, стратегия реализации. Сюда переезжают все технические решения, которых нельзя было касаться в спеке.

tasks.md — список задач с явными зависимостями. Задачи, которые можно выполнять параллельно, помечаются маркером [P]. Каждая задача ссылается на конкретные файлы — агент знает, куда идти.

Агент пишет код, тесты и документацию строго по tasks.md. Никакой импровизации — только то, что описано в предыдущих артефактах.

Перед стартом цикла создаётся constitution.md — принципы проекта: стандарты качества кода, подход к тестированию, UX-правила, требования к производительности. Хранится в .specify/memory/ и применяется ко всем фазам. Думайте о нём как о «конституции»: все последующие решения ей подчиняются.

Все файлы конкретной фичи лежат рядом:

specs/
  password-reset/
    spec.md
    plan.md
    tasks.md
    research.md    # опционально: исследование кодовой базы
.specify/
  memory/
    constitution.md

Такая структура делает фичу самодостаточной: ревью, откат, обсуждение — всё в одном месте.

Это самый важный практический вопрос в SDD. Правило простое:

• spec.md — поведение системы с точки зрения пользователя или бизнеса
• plan.md — технические решения, которые обеспечивают это поведение

Посмотрим на конкретном примере — фича «сброс пароля»:

Полезный маркер: если фраза предполагает конкретную технологию или структуру данных — она в plan.md. Если описывает, что пользователь получает или видит, — в spec.md.

Плохая спека — длинная, расплывчатая, с вкраплёнными техническими деталями. Хорошая:

1. Короткая и точная. Умещается на одном экране и не оставляет важных вопросов открытыми.

2. Без неоднозначностей. Их снимают через /speckit.clarify до создания плана — не после.

3. Только поведение, не реализация. Никаких упоминаний о БД, фреймворках, алгоритмах.

4. Конкретные критерии готовности. Не «авторизация должна быть надёжной», а «при трёх ошибках аккаунт блокируется на 15 минут».

Распространённое заблуждение: «спека — это ТЗ, которое пишут один раз». В SDD спека живая. Если поведение системы меняется — меняется и спека.

SDD не полностью автоматический процесс — и это хорошо. Между каждой фазой — обязательное ревью человека. Вы читаете артефакт до того, как агент переходит к следующему шагу.

Это главный механизм контроля качества: ошибку в спеке исправить дёшево — это редактирование markdown-файла. Та же ошибка на фазе Implement означает переписывание кода, тестов и, возможно, архитектуры.

Перед вами черновик spec.md для фичи «сброс пароля». Определите, какие пункты остаются в spec.md, а какие нужно перенести в plan.md.