/write-plan — Детальный план реализации

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

Вход

Аргумент $ARGUMENTS — одно из:

• Путь к design.md: openspec/changes/my-feature/design.md
• Название фичи: my-feature (ищет openspec/changes/my-feature/design.md)
• Ничего — ищет единственный активный change в openspec/changes/

Выход

openspec/changes/<feature>/tasks.md — исполняемый чеклист задач.

Процесс

Шаг 1 — Загрузка контекста

rlm_route_context(query="project architecture patterns 1C metadata")

Прочитай:

• openspec/changes/<feature>/design.md — согласованный дизайн
• openspec/project.md — если есть, соглашения проекта
• Связанные XML/BSL файлы из design.md через Grep/Glob

Шаг 2 — Декомпозиция на задачи

Правила декомпозиции:

• Каждая задача = 2-5 минут работы субагента
• Одна задача — одна атомарная операция (создать объект / написать модуль / добавить форму)
• Зависимости явные: «Задача 3 требует завершения Задачи 1»
• Порядок: сначала метаданные → потом BSL → потом формы → потом интеграции → валидация

Типовые категории задач для 1С:

Шаг 3 — Написание tasks.md

Сохрани в openspec/changes/<feature>/tasks.md.

Формат заголовка

# <Название фичи> — План реализации

> **Для субагента:** используй `/subagent-dev openspec/changes/<feature>/tasks.md`
> для выполнения задач по одной с ревью между ними.

**Цель:** <одно предложение — что строим>

**Дизайн:** `openspec/changes/<feature>/design.md`

**Порядок выполнения:** последовательно, если не указано иное

---

Формат каждой задачи

## Задача N: <Глагол + существительное>

**Статус:** `[ ]`

**Зависимости:** Задача X (или «нет»)

**Что делаем:**
<1-3 предложения — суть задачи>

**Файлы:**
- Создать: `src/Catalogs/МойСправочник/`
- Изменить: `src/CommonModules/МойМодуль/Module.bsl`
- Скилл: `/meta-compile` или `/form-compile` и т.д.

**Шаги:**
1. <конкретное действие — не «написать код», а «добавить реквизит Статус типа Перечисление.СтатусыЗаказа»>
2. <следующий шаг>
3. ...

**Проверка:**
- [ ] <критерий 1 — конкретный и проверяемый>
- [ ] <критерий 2>
- [ ] Синтаксис BSL проверен через `1c-syntax-checker`

**Коммит:** `feat: <краткое описание>`

Шаг 4 — Финальная задача: валидация

Последняя задача в плане всегда:

## Задача N: Финальная валидация

**Статус:** `[ ]`

**Зависимости:** все предыдущие задачи

**Шаги:**
1. Запустить `/cf-validate` или `/epf-validate` (по типу объекта)
2. Если нужно обновление БД: `/db-update`
4. Проверить критерии приёмки из design.md

**Проверка:**
- [ ] Конфигурация валидна
- [ ] Все критерии из design.md выполнены

Шаг 5 — Предложение режима выполнения

После сохранения tasks.md предложи два варианта:

План сохранён: openspec/changes/<feature>/tasks.md
Задач: N

Как выполнять?

1. /subagent-dev openspec/changes/<feature>/tasks.md
   — Субагенты на каждую задачу + ревью между задачами
   — Лучше для сложных доработок (3+ задачи, несколько модулей)

2. /openspec-apply <feature>
   — Последовательное выполнение в текущей сессии
   — Лучше для простых задач (1-3 задачи, один объект)

Не запускать автоматически — пользователь выбирает сам.

Правила качества плана

• Точные пути — не src/modules/, а src/CommonModules/УправлениеЗаказами/Module.bsl
• Точные скиллы — указывай какой скилл использовать для каждой задачи
• Проверяемые критерии — не «код работает», а «форма открывается, список заполняется»
• YAGNI — не планировать то, чего нет в design.md
• Без лишних коммитов — один коммит на задачу, не на каждый файл
• BSL всегда через checker — каждая задача с BSL кодом включает проверку синтаксиса

Анти-паттерны

• ❌ Задача «Реализовать весь модуль» — слишком большая, разбить
• ❌ Проверка «проверить что всё работает» — непроверяемо, конкретизировать
• ❌ Задачи без указания файлов
• ❌ Пропустить задачу финальной валидации
• ❌ Начать выполнение не дождавшись выбора пользователя