Planning

planning — Декомпозиция и планирование

Описание

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

Когда активировать

• Пользователь просит план, стратегию или этапы
• Задача крупная, абстрактная, неоднозначная или рискованная
• Задача затрагивает разные слои проекта, требует множества согласованных между собой изменений
• Требуются уточняющие вопросы

Философия

> Изучение прежде всего — сначала понимание, потом планирование.

Принципы планирования

1. Изучение прежде всего — сначала понимание проекта, потом планирование.
2. Навыки и инструменты важны — всегда адаптируйся, ты ими не управляешь.
3. Определи критерии успеха — каждая подзадача должна валидироваться.
4. Установи зависимости — убедись в правильном порядке задач.
5. Будь конкретным — чётко формулируй шаги.
6. Используй контекст — в нём могут быть полезные сведения.
7. Думай о результате — фокусируйся на целях пользователя.
8. Не скрывай информацию — любая мелочь может повлиять на успех.

Обязательный цикл

Шаг 1: Анализ входных данных

1. Проанализируй исходный запрос и текущий контекст.
2. Если необходимо: сформулируй несколько уточняющих вопросов, уточни ключевые нюансы, конечную цель и критерии оценки результата.
3. Изучи текущий проект: файловую структуру, архитектуру, паттерны, бизнес-логику, зависимости, связность и др.
4. При возможности изучи документацию к проекту: это могут быть комментарии в коде, дополнительные файлы и/или документация к фреймворкам и библиотекам.
5. Определи список доступных навыков и инструментов.
6. Выдели те участки проекта, которые соотносятся с требованиями пользователя.

Шаг 2: Планирование

1. Исходя из анализа, разбей исходную постановку на задачи в соответствии со структурой проекта.

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

1. Для каждого шага определи хотя бы один подходящий навык из доступных.

Необязательно, если подходящего навыка нет.

1. Пересмотри план, проверь наличие необходимых данных, участков кода, навыков, инструментов; сделай заключение о выполнимости текущего плана, в противном случае скорректируй.
2. Покажи план пользователю как есть и передай ему слово:

• План работ должен иметь следующий формат:

```

1. [ ] ****

• Навыки: ...
• Файлы:
• ...

1. [ ] ****

• Навыки: ...
• Файлы:
• ...

1. [ ] ****

• Навыки: ...
• Файлы:
• ...

... ```

• При отрицательном ответе вернись на этап анализа входных данных и задай уточняющие вопросы.
• При положительном ответе запиши план в файл .koda/plans/.md в корне проекта.

Имя плана зависит от исходной задачи. Например:

• если нужно исправить ошибку формирования заказа, файл плана следует назвать fix-order-creation.md;
• если нужно внедрить новый вид уведомлений, тогда new-notification.md.

Если план подвергался нескольким итерациям переработок, то в имя файла следует добавлять суффикс -vN, где N — номер итерации.

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

По мере выполнения запланированных действий, поддерживай файл в актуальном состоянии. Отмечай каждый выполненный шаг заменой [ ] на [x].

Шаг 3: Реализация плана

1. После подтверждения плана пользователем начинай работу с первого пункта до последнего, используя выбранные навыки и инструменты.
2. Не переходи к следующему шагу плана, пока текущий шаг не завершён.
3. Шаг считается завершённым если внесены и проверены все запланированные изменения.
4. По мере выполнения шаги плана отмечаются выполненными.
5. Если на каком-либо шаге оказывается, что план требует корректировки, возвращайся на этап анализа входных данных; корректировать уже выполненные шаги нельзя.

Ограничения

• План должен быть наглядным и понятным.
• Если задача простая (до 2 шагов), план не нужен: переходи к выполнению.
• Не вноси изменения в проект и не запускай команды, пока план не подтверждён.
• Названия или состав навыков может измениться в любой момент, адаптируй план к изменениям.
• Не создавай пересекающиеся подзадачи.
• Не смешивай домены в подзадаче: фронтенд, бэкенд, инфраструктура, бизнес-логика должны изменяться в отдельных подзадачах.
• Не создавай подзадачи без изучения проекта.
• Не создавай подзадачи, которые не будут выполнены, но увеличивают план.
• Если проект содержит код, нужно следовать принципам KISS, YAGNI, DRY, SRP, но прежде всего простота и прозрачность имеют решающее значение.
• Не надо добиваться идеального результата любой ценой, это может привести к нарушению планов и ожиданий.

Типичные примеры

Веб-приложение:

• Backend API → Backend QA → Frontend UI → Frontend QA → Интеграция

Микросервисы:

• Разработка сервиса → Тестирование → Развёртывание (Docker, Podman, k8s)

Анализ данных:

• Обработка → Проверка → Визуализация → Документирование

Исправление бага:

• Поиск причин → Исправление → Тестирование → Проверка

Рефакторинг:

• Анализ → Изменения → Тестирование → Проверка

Чек-лист

• [ ] Я провёл полный анализ задачи и контекста проекта
• [ ] Я сформулировал уточняющие вопросы, если нужно
• [ ] План разбит на логические подзадачи
• [ ] Каждая подзадача имеет чёткие критерии успеха
• [ ] План сохранён в .koda/plans/.md
• [ ] Я показал план пользователю и получил подтверждение
• [ ] Каждый шаг выполняется последовательно, без пропусков
• [ ] После выполнения — повторная проверка всех шагов

Scope

• Применять ко ВСЕМ задачам, которые требуют декомпозиции
• Для простых задач (до 2 шагов) план не нужен — переходи к выполнению
• План сохраняется в .koda/plans/.md в корне проекта
• Не переходи к следующему шагу, пока текущий не завершён

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Major-Woolfi
• Source: Major-Woolfi/Skillsfor_AI-Agents
• License: MIT

Install and usage instructions live in the source repository linked above.