---
name: prd-to-vertical-slice-tasks
description: Разбить план, спецификацию или PRD на независимые задачи для реализации с помощью вертикальных срезов. Использовать, когда пользователь хочет превратить план, PRD, описание функции или техническую спецификацию в набор исполнимых задач.
metadata:
  author: Stanislav [MADTeacher] Chernyshev
  url: https://github.com/MADTeacher
  version: "1.0"
---

# Задачи из спецификации

Разбей план, спецификацию или PRD на независимые задачи для реализации, используя подход вертикальных срезов.

Вертикальный срез — это тонкий, но законченный путь через все необходимые уровни системы: данные, бизнес-логику, API, интерфейс, тесты, интеграции и наблюдаемое поведение.

Не разбивай работу горизонтально по слоям вроде:
- отдельно схема данных;
- отдельно API;
- отдельно UI;
- отдельно тесты.

Каждая задача должна давать самостоятельный, проверяемый и по возможности демонстрируемый результат.

## Процесс

### 1. Собери контекст

Используй все, что уже есть в текущем контекстном окне:

- план;
- PRD;
- спецификацию;
- описание функции;
- описание бага;
- пользовательские истории;
- уже принятые решения;
- ограничения;
- технический контекст;
- обсужденные зависимости;
- открытые вопросы.

Не начинай с повторного интервью, если в текущем контексте уже достаточно информации для первичной декомпозиции.

Если пользователь передал внешний документ, текст задачи или ссылку на доступный источник, используй его как исходный материал.

### 2. Изучи кодовую базу, если это полезно

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

Особенно проверь:

- какие модули уже существуют;
- какие точки расширения можно использовать;
- какие похожие сценарии уже реализованы;
- какие тестовые подходы уже применяются;
- где проходят границы компонентов;
- какие зависимости могут повлиять на порядок задач.

Не спрашивай пользователя о том, что можно надежно выяснить из доступных материалов.

### 3. Сформируй вертикальные срезы

Разбей работу на задачи-трассеры.

Каждая задача должна быть узкой, но завершенной. Она должна проходить через все необходимые уровни реализации и давать наблюдаемое поведение.

Задачи могут быть двух типов:

- **AFK** — задача может быть реализована автономно без участия пользователя;
- **HITL** — для задачи требуется участие человека: продуктовая развилка, архитектурное решение, дизайн-ревью, подтверждение контракта, согласование поведения или другой ручной выбор.

По возможности предпочитай **AFK**-задачи. Отмечай задачу как **HITL** только тогда, когда без человеческого решения действительно нельзя безопасно двигаться дальше.

<vertical-slice-rules>
- Каждый срез реализует узкий, но законченный end-to-end сценарий.
- Каждый срез проходит через все необходимые интеграционные слои.
- Завершенный срез можно проверить, продемонстрировать или принять независимо.
- Лучше много маленьких срезов, чем несколько крупных задач.
- Не создавай задачи, которые меняют только один технический слой без пользовательски или системно наблюдаемого результата.
- Если один срез зависит от решения в другом, явно укажи зависимость.
- Если срез слишком большой, раздели его на несколько последовательных срезов.
</vertical-slice-rules>

### 4. Покажи черновую декомпозицию пользователю

Сначала представь предлагаемую разбивку в виде нумерованного списка.

Для каждого среза покажи:

- **Название**: короткое и описательное;
- **Тип**: HITL или AFK;
- **Заблокировано**: какие задачи должны быть выполнены раньше, если такие есть;
- **Покрываемые пользовательские истории**: если они есть в исходном материале;
- **Проверяемый результат**: что можно будет увидеть, проверить или принять после выполнения задачи.

После списка задай пользователю вопросы:

- Подходит ли уровень детализации: задачи не слишком крупные и не слишком мелкие?
- Правильно ли определены зависимости?
- Нужно ли какие-то задачи объединить?
- Нужно ли какие-то задачи разделить?
- Правильно ли отмечены задачи HITL и AFK?
- Не пропущены ли важные пользовательские сценарии, крайние случаи или технические ограничения?

Итерируй декомпозицию, пока пользователь не подтвердит, что структура задач подходит.

### 5. Сформируй финальный набор задач

После утверждения декомпозиции сформируй задачи в порядке зависимостей: сначала блокирующие задачи, затем зависящие от них.

Используя шаблон ниже запиши в markdown-файлы каждую задачу и сохрани в директории docs/tasks в корневой директории проекта.

Если у задач еще нет внешних идентификаторов, ссылайся на них по номерам из текущей декомпозиции.

<task-template>

## Родительская задача

Укажи исходный план, PRD, спецификацию, функцию или баг, из которого получена задача.

Если явная родительская задача отсутствует, то этот раздел можно опустить.

## Что нужно реализовать

Кратко опиши вертикальный срез.

Описывай end-to-end поведение, а не послойную реализацию.

Плохо:

> Добавить таблицу, затем endpoint, затем экран.

Хорошо:

> Пользователь может создать черновик сущности, увидеть его в списке и открыть карточку с сохраненными данными.

## Пользовательский или системный результат

Опиши, какой наблюдаемый результат появится после выполнения задачи.

Результат должен быть проверяемым независимо от других задач, насколько это возможно.

## Критерии приемки

- [ ] Критерий 1
- [ ] Критерий 2
- [ ] Критерий 3

Критерии должны описывать наблюдаемое поведение системы, а не внутренние детали реализации.

## Зависимости

Укажи, какие задачи должны быть выполнены раньше.

Если зависимостей нет, напиши:

- Нет — можно начинать сразу.

## Тип задачи

AFK или HITL.

Если задача HITL, явно укажи, какое человеческое решение или подтверждение требуется.

## Заметки по реализации

Добавь только те технические заметки, которые помогают выполнить задачу.

Не включай конкретные пути к файлам и фрагменты кода, если они могут быстро устареть.

## Заметки по тестированию

Опиши, что нужно проверить.

Включи:
- какие сценарии покрыть тестами;
- какие внешние поведения проверить;
- какие регрессии предотвратить;
- какие похожие тестовые подходы уже есть в проекте, если это известно.

</task-template>