---
name: spdd
description: Structured Prompt-Driven Development по Мартину Фаулеру — методология разработки новой системы через управляемые промпты как артефакты уровня кода. Используй ВСЕГДА, когда пользователь хочет создать с нуля новую систему/приложение/сервис/продукт/MVP/модуль/фичу — даже при размытом запросе ("давай сделаем X", "хочу создать Y", "придумаем сервис для Z", "нужна система для", "спроектируем", "начнём новый проект", "построим", "разработаем"). Скилл проводит через 6 шагов: декомпозиция требований → анализ → контекст → структурированный промпт REASONS → генерация кода → юнит-тесты. Промпт — источник правды: версионируется, ревьюируется, синхронизируется с кодом; при расхождении правится первым. НЕ использовать для hotfix'ов, исследовательских спайков, неясных доменов и тривиальных правок.
---

# SPDD — Structured Prompt-Driven Development

Промпт = управляемый артефакт уровня кода: версионируемый, ревьюируемый, синхронизированный с реализацией. **При расхождении промпта и кода — сначала чиним промпт, потом код.**

## Когда применять

- ✅ Новая система/сервис/MVP с нуля
- ✅ Новый модуль или крупная фича с заметной структурой
- ✅ Стандартизированная доставка, командная разработка, высоконормативные системы
- ❌ Hotfix продакшена, спайк-разведка, неясный домен, тривиальная правка — пропускай

## Канвас REASONS (7 измерений промпта)

- **R**equirements — проблема и измеримые критерии успеха
- **E**ntities — доменные модели, атрибуты, инварианты
- **A**pproach — стратегия решения, выбранные паттерны
- **S**tructure — место в системе, компоненты, слои
- **O**perations — конкретные реализационные шаги до сигнатур методов
- **N**orms — инженерные нормы, code style, обработка ошибок
- **S**afeguards — нерушимые границы и запреты

## Процесс — 6 шагов

1. **Story** — декомпозируй требование на 3–7 INVEST-историй (Independent, Negotiable, Valuable, Estimable, Small, Testable). Артефакт: `docs/spdd/<story-id>/story.md`
2. **Analysis** — извлеки концепты, отсканируй существующий код (Grep/Glob), оцени риски, предложи 1–2 направления дизайна. Артефакт: `analysis.md`
3. **Context** — сжатый документ: доменный словарь, границы scope, связи с существующими модулями. Артефакт: `context.md`
4. **REASONS Canvas** — собери промпт по всем 7 измерениям. **Ревью с пользователем ПЕРЕД генерацией кода** — это quality gate. Артефакт: `reasons-canvas.md`
5. **Generate** — сначала функциональные/acceptance тесты по Requirements, потом код по Operations шаг за шагом. Логическая ошибка → правь канвас → перегенерируй. Рефакторинг отошёл от канваса → синхронизируй канвас с кодом. Не молча.
6. **Unit Tests** — покрытие из финального канваса, без дублирования функциональных тестов. Edge cases из Entities и Safeguards.

## Ключевые принципы

- **Abstraction First** — проектируй до генерации, не наоборот
- **Alignment** — фиксируй «делаем / не делаем» явно ДО реализации
- **Iterative Review** — дисциплина цикла обратной связи, не one-shot
- **Промпт — источник правды**: расхождение → правь промпт первым

## Workflow при активации

1. Проясни scope: что строим, для кого, бизнес-цель (1–2 уточнения, не более)
2. Предложи декомпозицию на INVEST-истории, дождись подтверждения
3. Для каждой истории — проведи последовательно через шаги 2–6
4. Сохраняй артефакты в `docs/spdd/<story-id>/` (story.md, analysis.md, context.md, reasons-canvas.md)
5. Ревью на границах шагов — не двигайся дальше без подтверждения пользователя
6. На шаге Generate — TDD-стиль: тесты сначала, потом код

## Признаки несоответствия (стоп-сигналы)

- Реализация противоречит Safeguards
- Логика не покрыта в Operations
- Появилась entity, не описанная в Entities
- Тесты зелёные, но Requirements не выполнены

При срабатывании — стоп, сигнализируй пользователю, правь канвас.

Шаблоны, примеры, детали каждого шага — [REFERENCE.md](REFERENCE.md).