decompose

/decompose — исследование и декомпозиция задачи

Исследование User Story или крупной задачи, анализ кода, декомпозиция на подзадачи с созданием в YouTrack. Подключения к системам из .claude/memory/project-index.md.

Использование

/decompose US-264
/decompose PLF-850

Артефакты

docs/llm/tasks/{TASK_ID}/
├── research.md      — исследование, анализ кода, зависимости, решения

Flow

FETCH → RESEARCH → ⏸ HITL → DECOMPOSE → ⏸ HITL → CREATE → ⏸ HITL

---

1. FETCH — прочитать задачу

Получить задачу из YouTrack:

pcurl @{yt_profile} 'https://{yt_host}/api/issues/{TASK_ID}?fields=idReadable,summary,description,created,updated,reporter(login,name),assignee(login,name),tags(name),comments(author(login,name),text,created),customFields(name,value(name))' -s

Получить связанные задачи:

pcurl @{yt_profile} 'https://{yt_host}/api/issues/{TASK_ID}?fields=idReadable,summary,links(direction,linkType(name),issues(idReadable,summary,resolved))' -s

Найти существующие subtasks:

pcurl @{yt_profile} 'https://{yt_host}/api/issues?query=subtask+of:+{TASK_ID}&fields=idReadable,summary,customFields(name,value(name))&$top=30' -s

Создать директорию: mkdir -p docs/llm/tasks/{TASK_ID}/

2. RESEARCH — глубокое исследование (plan mode)

Войти в plan mode. Не писать код — только анализ.

2a. Анализ кода (параллельно)

Запустить агентов (subagent_type=Explore) для параллельного исследования:

• Существующий код: какие компоненты уже реализованы, какие отсутствуют
• Модель данных: таблицы, FK, constraints, связи. Нужна ли миграция?
• API: существующие RPC-методы, что можно переиспользовать
• Зависимости: межсервисные вызовы, внешние системы
• Тесты: существующие тесты, покрытие
• Техдолг: нужен ли рефакторинг перед реализацией US?

2b. Анализ требований

Из описания задачи извлечь:

• Acceptance criteria
• Сценарии использования
• Edge cases
• Зависимости между сценариями

2c. Открытые вопросы

Сформулировать вопросы, которые блокируют реализацию:

• Бизнес-логика (как должно работать?)
• Данные (что удалять, что сохранять?)
• Интеграции (внешние системы)
• Порядок реализации

Артефакт: Сохранить docs/llm/tasks/{TASK_ID}/research.md:

# {TASK_ID} — Research

## Задача
- **Summary:** {summary}
- **Тип:** {User Story / Epic / Task}
- **Parent:** {parent_id} — {summary}
- **Связано:** {linked issues}

## Существующий код

### Что уже есть
- {компонент} — {описание, файл:строка}

### Что отсутствует
| Компонент | Статус | Описание |
|---|---|---|
| {компонент} | отсутствует | {что нужно} |

## Модель данных
- Таблицы: {список с FK}
- Миграции: {нужны / не нужны, описание}

## Acceptance Criteria → Подзадачи
| AC | Подзадача | Приоритет |
|---|---|---|
| {AC из US} | {как реализуем} | must/should/could |

## Зависимости между задачами
- {TASK_A} блокирует {TASK_B}
- Общие компоненты: {список}
- Порядок реализации: {1 → 2 → 3}

## Техдолг / Рефакторинг
- {нужен ли рефакторинг перед US, выделять ли в отдельную задачу}

## Решения по открытым вопросам
{решения, принятые с пользователем}

## Риски
- {риск 1}
- Regression: {что может сломаться}

⏸ HITL: Обсуждение research

Показать пользователю research.md. Обсудить:

• Открытые вопросы
• Решения по архитектуре
• Приоритеты (must/should/could)
• Зависимости и порядок реализации

Итеративно обновлять research.md по мере получения ответов. Не переходить к декомпозиции, пока все блокирующие вопросы не закрыты.

3. DECOMPOSE — декомпозиция на подзадачи

На основе research сформировать подзадачи.

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

• Каждая задача — атомарная, может быть реализована и задеплоена независимо
• Каждая задача решается через /solve
• Указать проект (из project-index.md)
• Указать сервис если несколько
• Указать SP (Story Points)
• Указать приоритет: must / should / could
• Указать зависимости (что блокирует)
• Миграция БД — отдельная задача, если стадия Dev+ (/pgmigrator)
• Рефакторинг/техдолг — отдельная задача (если нужен)

Формат подзадачи:

### {N}. {service}: {краткое название}
**SP:** {N} | **Приоритет:** {must/should/could} | **Блокирует:** {список или "—"}

{Описание задачи с деталями реализации}

**Acceptance criteria:**
- [ ] {AC 1}
- [ ] {AC 2}

**Как тестировать:**
- {сценарий теста}

**Миграции:** {нет / описание}

⏸ HITL: Утверждение декомпозиции

Показать пользователю полный план подзадач. Пользователь:

• Корректирует описания
• Меняет SP и приоритеты
• Добавляет/убирает задачи
• Утверждает

4. CREATE — создание в YouTrack

После утверждения — создать задачи в YouTrack:

pcurl @{yt_profile} 'https://{yt_host}/api/issues?fields=idReadable,summary' \
  -X POST -H 'Content-Type: application/json' \
  -d '{
    "project": {"id": "{project_id}"},
    "summary": "{summary}",
    "description": "{description}"
  }' -s

Привязать как subtask к родительской US:

pcurl @{yt_profile} 'https://{yt_host}/api/commands' \
  -X POST -H 'Content-Type: application/json' \
  -d '{"query":"subtask of {PARENT_ID}","issues":[{"idReadable":"{CREATED_ID}"}]}' -s

Кастомные поля (SP, тип работы, доска, спринт) зависят от проекта — брать из project-index.md.

⏸ HITL: Подтверждение создания

Показать таблицу созданных задач:

#	ID	Сервис	SP	Приоритет	Задача	Блокирует
1	{ID}	{service}	{SP}	must	{summary}	—

Итого: {N} задач, {SP} SP.

---

Правила

• Никогда не создавать задачи без утверждения пользователя
• Все задачи привязываются к родительской US как subtasks
• Каждая подзадача потом решается через /solve
• Research в plan mode — не писать код
• Открытые вопросы обсуждаются итеративно — не переходить к декомпозиции с неразрешёнными вопросами
• Миграции и рефакторинг — отдельные задачи
• Кастомные поля YouTrack (SP, доска, спринт) из project-index.md