make-plan

Files (2)

• SKILL.md
• template.md · references/

SKILL.md (first lines)

# Make Plan (План реализации)

Создать `implementation-plan.md` — документ, который трансформирует принятое решение в конкретный упорядоченный перечень работ, готовый к нарезанию задач.
Решение формулируется следующим набором документов:
- `functional-spec.md`
- `ui-spec.md`
- `research.md`

Документ отвечает на пять вопросов:

1. **Что именно делаем?** — конкретные файлы, функции, классы, API-контракты, которые нужно создать или изменить
2. **В каком порядке?** — последовательность с учётом зависимостей
3. **Что можно делать параллельно?** — независимые потоки работ
4. **Что устанавливаем?** — финальный список библиотек с точными версиями и конфигурационными параметрами
5. **Насколько критично?** — оценка усилий или приоритет для каждого блока работ (опционально)

## Роли

- **AI-агент** — генерирует план на основе проектных документов
- **Человек** — уточняет, дополняет и утверждает план до начала реализации

## Критерий готовности

План считается готовым, когда:
- Все работы из выбранного решения покрыты
- Зависимости между работами учтены и не образуют циклов
- Нет противоречий с `functional-spec.md` и `feature-spec.md`
- Человек подтвердил план

## Процесс

### Шаг 1 — Собрать входные документы

Прочитать в следующем порядке:
- `research.md` — выбранные ключевые технические решения, точки интеграции и риски (если это однозначно не вытекает из проектной документации)
- `feature-spec.md` — пользовательские требования
- `functional-spec.md` — модули, контракты, потоки данных
- `ui-spec.md` — экраны и состояния, если есть фронтендная часть
- База знаний (`.docs/knowledge/README.md`) и ADR (`.docs/knowledge/adr/`) при наличии

В случае отсутствия `research.md` или `ui-spec.md` считать, что изменений в этой части не предполагается.

### Шаг 2 — Декомпозировать на конкретные работы

Разбить реализацию на атомарные единицы работы. Каждая единица:
- Называет конкретный артефакт: файл, класс, функцию, метод, таблицу БД, конфиг-ключ, API-эндпоинт
- Описывает действие: создать, изменить, удалить, подключить, настроить
- Ограничена по объёму: выполнима за одну рабочую сессию (условно ≤ 6 часов)

Группировать единицы в блоки по фичам, а в случае невозможности - по смысловой принадлежности (например: «Создание заказа», «Импорт данных», «Настройка окружения», «Слой данных», «Бизнес-логика», «UI»).
Тесты являются составляющей частью смыслового блока.

### Шаг 3 — Выстроить последовательность с зависимостями

Для каждого блока/единицы работы указать:
- Что должно быть готово до начала (зависимости)
- Что становится разблокированным после завершения

Использовать нумерацию или граф зависимостей (Mermaid `flowchart TD`), если зависимостей много.

Проверить: нет ли циклических зависимостей.

### Шаг 4 — Выделить параллельные потоки

Найти блоки работ, у которых нет взаимных зависимостей — их можно выполнять параллельно. Явно обозначить такие потоки в плане. Если параллелизм невозможен или не имеет смысла — написать об этом одним предложением.

### Шаг 5 — Зафиксировать библиотеки и конфигурацию

Перенести из `research.md` (или спецификаций `functional-spec.md` и `ui-spec.md`) финальный список зависимостей. Добавить:
- Точные версии (semver или commit hash)
- Способ установки (команда: `npm install`, `pip install`, `dotnet add package` и т.д.)
- Ключевые конфигурационные параметры, которые нужно задать

Не пересматривать выбор из `research.md` — если есть сомнения, задать вопрос пользователю.

### Шаг 6 — Оценить усилия или критичность (опционально)

Если пользователь запрашивает или если план содержит больше 10 единиц работы — добавить для каждого блока одну из меток:
- **Критично** — без этого ничего не работает
- **Важно** — нужно для полноты фичи
- **Желательно** — улучшение, которое можно отложить
- Оценку в условных единицах (S / M / L / XL) или часах — только если пользователь просил

### Шаг 7 — Представить на утверждение

До записи файла вывести для пользователя:
- Количество блоков и единиц работы
- Критический путь (самая длинная последовательная цепочка)
- Есть ли параллельные потоки и сколько
- Открытые вопросы, требующие ответа до начала реализации

Спросить: «Всё верно? Или нужно скорректировать декомпозицию / порядок / оценки перед записью файла?»

Записывать файл только после подтверждения пользователя.

### Шаг 8 — Записать файл

Записать `implementation-plan.md` в корень проекта (или по пути, указанному пользователем). Использовать шаблон из `references/template.md`.

После записи вывести путь к файлу и одно предложение: сколько блоков работы и каков критический путь.

## Язык

Общаться с пользователем на русском. Документ писать на русском. Технические термины, идентификаторы, имена файлов, команды и код внутри блоков кода — в оригинальном виде (английский).

## Правила оформления

- Каждая единица работы — отдельный пункт с чекбоксом `- [ ]`
- Зависимости указывать явно: «Зависит от: [номер пункта]» или через граф Mermaid
- Параллельные потоки обозначать отдельными подразделами внутри одного шага
- Таблица библиотек содержит колонки: Библиотека, Версия, Команда установки, Назначение
- Объём документа — не более 400 строк; при превышении разбить на фазы и вынести детали в отдельные файлы

## Ограничения

- Не коммитить изменения
- Не выводить commit message
- Не начинать реализацию — результат только план
- Не пересматривать решение из `research.md` — только планировать его реализацию

From YamiHilik/SDLCRoom, Apache-2.0.

More from YamiHilik/SDLCRoom