---
name: decompose
description: Decompose work into stages with physical artifacts and acceptance checklists. Gap detector. Use when opening a WP ≥3h (open-loop/problem-framing) or on explicit request to break into stages. Executes R29 Decomposer role.
version: 1.0.0
layer: L3
status: active
browser_safe: true
triggers:
  slash: [/decompose]
  phrases: []
routing:
  executor: sonnet
  deterministic: false
---

# /decompose — Декомпозитор (R29)

> **Роль:** R29 Декомпозитор. **Носитель:** этот скилл.
> **Цель:** разложить деятельность на ≤4 этапа с материальными I/O и чеклистами. Обнаружить разрывы.

## Когда вызывается

- **WP Gate:** РП ≥3h И класс ∈ {open-loop, problem-framing} → выполняется автоматически после Шага 4 Ритуала (Шаг 4.5 protocol-open.md)
- **IntegrationGate:** новый инструмент/агент/система → после Service Clause и Role
- **Strategy Session:** декомпозиция крупной инициативы (>1 неделя)
- **Явный запрос:** `/decompose`, «разложи на этапы»

## Алгоритм (5 шагов)

### Шаг 1. Карта контекста (3-5 строк)

- **Кто держит роли:** инициатор / исполнитель / проверяющий (по именам или R-ID)
- **Верхний критерий успеха:** одна фраза, проверяемая
- **Ключевые ограничения:** время / деньги / этика / зависимости

### Шаг 2. Дерево этапов (≤4 узла)

Одна строка на этап: название + назначение. Если получается >4 — укрупнить.

### Шаг 3. Развёртка этапов

Для каждого этапа:

```
**Этап N: <название>**
- Вход: <материальный артефакт>
- Метод: <как делаем, ссылка на SOP/PROCESSES.md если есть>
- Выход: <материальный артефакт, отличный от входа>
- Чеклист приёмки (3-5 пунктов):
  - [ ] критерий 1
  - [ ] критерий 2
  - [ ] критерий 3
- Роли:
  - <Имя/R-ID> в роли <название роли>
```

### Шаг 4. Детектор разрывов

Для каждого этапа проверить:
- Вход и выход — материальные и **разные**? («понимание», «решение в голове» — запрещены)
- Метод определён или требует уточнения?
- Чеклист имеет ≥3 пункта?
- Носитель роли назначен?

Каждый разрыв → блок:
```
**Не хватает:** <что>
**Риск:** <чем грозит>
**Решения:**
1. <бережливое — минимальные затраты>
2. <надёжное — снижает риск>
3. <быстрое — экономит время> (опционально)
```

### Шаг 5. Опциональная детализация (только по запросу)

В первой выдаче не пишется. Расширяется при просьбе:
- Риски и контрмеры
- Метрики (единицы измерения, шкала)
- Бюджет (часы, деньги)
- Первые 7 дней (микро-план)
- Сигналы к пересборке

## Правила

1. **Физичность I/O.** Вход/выход — артефакт, документ, файл, фото, видео, аудио, деньги, подпись, метка в трекере, коммит, PR. Запрещены «понимание», «согласование в голове».
2. **Планы ≠ Факты.** Намерение (WorkPlan) и результат (Work) — разные артефакты, в разных файлах.
3. **Ролевая формулировка.** Не «ты сделаешь», а «<Имя> в роли <название роли>». Роль не из roles.md → пометить «(новая роль, требует регистрации в roles.md)».
4. **≤4 этапа в первой выдаче.** Глубже — по запросу.
5. **Чеклист обязателен.** Этап без чеклиста — это намерение, не этап.
6. **Объём >10h или независимый lifecycle** → рекомендовать: (а) фазы внутри одного РП, или (б) отдельные РП. Регистрацию через `/wp-new` делает пользователь, не Декомпозитор.
7. **Output — в response, не в файл.** Главный агент решает, куда вставить: WP-context, диалог, другой скилл.

## Различения (важно)

- **vs R5 Архитектор:** Архитектор оценивает решения (ЭМОГССБ через `/archgate`). Декомпозитор разлагает деятельность.
- **vs R1 Стратег:** Стратег планирует на масштабе недели/месяца. Декомпозитор работает над конкретным РП.
- **vs R28 Диагност:** Диагност определяет ступень мастерства. Декомпозитор разлагает работу, не диагностирует человека.
- **vs IntegrationGate:** IntegrationGate — правило (когда декомпозировать). Декомпозитор — исполнитель (как).