---
name: write-plan
description: >
  Этот скилл MUST быть вызван когда есть design.md и нужно разбить доработку на атомарные задачи (2-5 мин) с точными путями файлов и критериями проверки в tasks.md.
  SHOULD также вызывать как промежуточный шаг между brainstorm и subagent-dev.
  Do NOT использовать для обсуждения идеи — используй brainstorm; для выполнения задач — используй subagent-dev.
argument-hint: <путь к design.md или feature-name>
allowed-tools:
  - Read
  - Write
  - Glob
  - Grep
  - Bash
  - mcp__rlm-toolkit__rlm_route_context
---

# /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С:**

| Категория | Примеры задач |
|-----------|---------------|
| Метаданные | Создать справочник, добавить реквизит, создать регистр |
| Модули | Написать ОбщийМодуль, ObjectModule, ManagerModule |
| Формы | Создать форму, добавить элементы, написать модуль формы |
| Роли | Создать роль, настроить права |
| Подсистемы | Добавить объекты в подсистему |
| Интеграции | Подписки на события, регистрация в БСП |
| Валидация | Проверить синтаксис, обновить БД |

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

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

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

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

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

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

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

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

---
```

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

```markdown
## Задача 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 — Финальная задача: валидация

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

```markdown
## Задача 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 кодом включает проверку синтаксиса

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

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