Subagent Driven Development

Выполнение планов через подагентов delegate_task (двухэтапное ревью).

Метаданные навыка


Источник	Опционально — установка с помощью `vibeos skills install official/software-development/subagent-driven-development`
Путь	`optional-skills/software-development/subagent-driven-development`
Версия	`1.1.0`
Автор	VibeOS (адаптировано из obra/superpowers)
Лицензия	MIT
Платформы	linux, macos, windows
Теги	`delegation`, `subagent`, `implementation`, `workflow`, `parallel`
Связанные навыки	`plan`, `requesting-code-review`, `test-driven-development`

Справочник: полный SKILL.md

к сведению

Ниже приведено полное определение навыка, которое VibeOS загружает при активации этого навыка. Это те инструкции, которые видит агент, когда навык активен.

Subagent-Driven Development

Обзор

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

Основной принцип: Свежий подагент на задачу + двухэтапное ревью (спецификация, затем качество) = высокое качество, быстрая итерация.

Когда использовать

Используйте этот навык, когда:

У вас есть план реализации (из навыка plan или требований пользователя)
Задачи в основном независимы
Важны качество и соответствие спецификации
Вы хотите автоматизированное ревью между задачами

В отличие от ручного выполнения:

Свежий контекст для каждой задачи (нет путаницы от накопленного состояния)
Автоматизированный процесс ревью выявляет проблемы на ранних этапах
Последовательные проверки качества по всем задачам
Подагенты могут задавать вопросы перед началом работы

Процесс

1. Чтение и разбор плана

Прочитайте файл плана. Извлеките ВСЕ задачи с полным текстом и контекстом заранее. Создайте список задач:

# Чтение плана
read_file("docs/plans/feature-plan.md")

# Создание списка задач со всеми задачами
todo([
    {"id": "task-1", "content": "Создать модель User с полем email", "status": "pending"},
    {"id": "task-2", "content": "Добавить утилиту хеширования паролей", "status": "pending"},
    {"id": "task-3", "content": "Создать конечную точку входа", "status": "pending"},
])

Ключевой момент: Прочитайте план ОДИН РАЗ. Извлеките всё. Не заставляйте подагентов читать файл плана — предоставляйте полный текст задачи непосредственно в контексте.

2. Рабочий процесс для каждой задачи

Для КАЖДОЙ задачи в плане:

Шаг 1: Назначение подагента-исполнителя

Используйте delegate_task с полным контекстом:

delegate_task(
    goal="Реализовать задачу 1: Создать модель User с полями email и password_hash",
    context="""
    ЗАДАЧА ИЗ ПЛАНА:
    - Создать: src/models/user.py
    - Добавить класс User с полями email (str) и password_hash (str)
    - Использовать bcrypt для хеширования паролей
    - Включить __repr__ для отладки

    СЛЕДУЙТЕ TDD:
    1. Напишите падающий тест в tests/models/test_user.py
    2. Запустите: pytest tests/models/test_user.py -v (убедитесь в FAIL)
    3. Напишите минимальную реализацию
    4. Запустите: pytest tests/models/test_user.py -v (убедитесь в PASS)
    5. Запустите: pytest tests/ -q (убедитесь в отсутствии регрессий)
    6. Зафиксируйте: git add -A && git commit -m "feat: add User model with password hashing"

    КОНТЕКСТ ПРОЕКТА:
    - Python 3.11, Flask приложение в src/app.py
    - Существующие модели в src/models/
    - Тесты используют pytest, запуск из корня проекта
    - bcrypt уже в requirements.txt
    """,
    toolsets=['terminal', 'file']
)

Шаг 2: Назначение ревьюера соответствия спецификации

После завершения работы исполнителя проверьте соответствие исходной спецификации:

delegate_task(
    goal="Проверить, соответствует ли реализация спецификации из плана",
    context="""
    ИСХОДНАЯ СПЕЦИФИКАЦИЯ ЗАДАЧИ:
    - Создать src/models/user.py с классом User
    - Поля: email (str), password_hash (str)
    - Использовать bcrypt для хеширования паролей
    - Включить __repr__

    ПРОВЕРИТЬ:
    - [ ] Все требования из спецификации реализованы?
    - [ ] Пути к файлам соответствуют спецификации?
    - [ ] Сигнатуры функций соответствуют спецификации?
    - [ ] Поведение соответствует ожидаемому?
    - [ ] Ничего лишнего не добавлено (нет расширения объема)?

    ВЫВОД: PASS или список конкретных несоответствий спецификации для исправления.
    """,
    toolsets=['file']
)

Если найдены проблемы со спецификацией: Исправьте пробелы, затем повторно запустите ревью спецификации. Продолжайте только при соответствии спецификации.

Шаг 3: Назначение ревьюера качества кода

После прохождения проверки соответствия спецификации:

delegate_task(
    goal="Проверить качество кода для реализации задачи 1",
    context="""
    ФАЙЛЫ ДЛЯ ПРОВЕРКИ:
    - src/models/user.py
    - tests/models/test_user.py

    ПРОВЕРИТЬ:
    - [ ] Соответствует соглашениям и стилю проекта?
    - [ ] Правильная обработка ошибок?
    - [ ] Понятные имена переменных/функций?
    - [ ] Адекватное тестовое покрытие?
    - [ ] Нет очевидных ошибок или пропущенных граничных случаев?
    - [ ] Нет проблем с безопасностью?

    ФОРМАТ ВЫВОДА:
    - Критические проблемы: [должны быть исправлены перед продолжением]
    - Важные проблемы: [следует исправить]
    - Незначительные проблемы: [опционально]
    - Вердикт: APPROVED или REQUEST_CHANGES
    """,
    toolsets=['file']
)

Если найдены проблемы с качеством: Исправьте проблемы, повторно проверьте. Продолжайте только после одобрения.

Шаг 4: Отметка о завершении

todo([{"id": "task-1", "content": "Создать модель User с полем email", "status": "completed"}], merge=True)

3. Финальное ревью

После завершения ВСЕХ задач назначьте финального ревьюера интеграции:

delegate_task(
    goal="Проверить всю реализацию на согласованность и проблемы интеграции",
    context="""
    Все задачи из плана выполнены. Проверьте полную реализацию:
    - Все ли компоненты работают вместе?
    - Есть ли несоответствия между задачами?
    - Все ли тесты проходят?
    - Готово ли к слиянию?
    """,
    toolsets=['terminal', 'file']
)

4. Проверка и фиксация

# Запуск полного набора тестов
pytest tests/ -q

# Просмотр всех изменений
git diff --stat

# Финальная фиксация при необходимости
git add -A && git commit -m "feat: complete [feature name] implementation"

Гранулярность задач

Каждая задача = 2-5 минут целенаправленной работы.

Слишком большая:

«Реализовать систему аутентификации пользователей»

Правильный размер:

«Создать модель User с полями email и password»
«Добавить функцию хеширования паролей»
«Создать конечную точку входа»
«Добавить генерацию JWT токенов»
«Создать конечную точку регистрации»

Красные флаги — Никогда так не делайте

Начинать реализацию без плана
Пропускать ревью (соответствие спецификации ИЛИ качество кода)
Продолжать с неисправленными критическими/важными проблемами
Назначать несколько подагентов-исполнителей для задач, затрагивающих одни и те же файлы
Заставлять подагента читать файл плана (вместо этого предоставляйте полный текст в контексте)
Пропускать контекст настройки сцены (подагент должен понимать, куда вписывается задача)
Игнорировать вопросы подагента (отвечайте, прежде чем позволить им продолжить)
Принимать «достаточно близко» по соответствию спецификации
Пропускать циклы ревью (ревьюер нашел проблемы → исполнитель исправляет → повторное ревью)
Позволять исполнителю заменять фактическое ревью саморевью (нужны оба)
Начинать ревью качества кода до того, как соответствие спецификации пройдено (PASS) (неправильный порядок)
Переходить к следующей задаче, пока в любом из ревью есть открытые проблемы

Обработка проблем

Если подагент задает вопросы

Отвечайте четко и полностью
Предоставьте дополнительный контекст при необходимости
Не торопите их с реализацией

Если ревьюер находит проблемы

Подагент-исполнитель (или новый) их исправляет
Ревьюер проверяет снова
Повторяйте до одобрения
Не пропускайте повторное ревью

Если подагент не справляется с задачей

Назначьте нового подагента для исправления с конкретными инструкциями о том, что пошло не так
Не пытайтесь исправить вручную в сессии контроллера (загрязнение контекста)

Замечания по эффективности

Почему свежий подагент на задачу:

Предотвращает загрязнение контекста от накопленного состояния
Каждый подагент получает чистый, сфокусированный контекст
Нет путаницы от кода или рассуждений предыдущих задач

Почему двухэтапное ревью:

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

Компромисс по стоимости:

Больше вызовов подагентов (исполнитель + 2 ревьюера на задачу)
Но проблемы выявляются раньше (дешевле, чем отладка накопленных проблем впоследствии)

Интеграция с другими навыками

С plan

Этот навык ВЫПОЛНЯЕТ планы, созданные навыком plan:

Требования пользователя → план → план реализации
План реализации → subagent-driven-development → рабочий код

С test-driven-development

Подагенты-исполнители должны следовать TDD:

Сначала написать падающий тест
Реализовать минимальный код
Убедиться, что тест проходит
Зафиксировать

Включайте инструкции TDD в контекст каждого исполнителя.

С requesting-code-review

Процесс двухэтапного ревью И ЕСТЬ ревью кода. Для финального ревью интеграции используйте аспекты ревью из навыка requesting-code-review.

С systematic-debugging

Если подагент сталкивается с ошибками во время реализации:

Следуйте процессу systematic-debugging
Найдите коренную причину перед исправлением
Напишите регрессионный тест
Возобновите реализацию

Пример рабочего процесса

[Чтение плана: docs/plans/auth-feature.md]
[Создание списка задач с 5 задачами]

--- Задача 1: Создать модель User ---
[Назначение подагента-исполнителя]
  Исполнитель: «Должен ли email быть уникальным?»
  Вы: «Да, email должен быть уникальным»
  Исполнитель: Реализовано, 3/3 тестов проходят, зафиксировано.

[Назначение ревьюера спецификации]
  Ревьюер спецификации: ✅ PASS — все требования выполнены

[Назначение ревьюера качества]
  Ревьюер качества: ✅ APPROVED — чистый код, хорошие тесты

[Отметка задачи 1 как завершенной]

--- Задача 2: Хеширование паролей ---
[Назначение подагента-исполнителя]
  Исполнитель: Без вопросов, реализовано, 5/5 тестов проходят.

[Назначение ревьюера спецификации]
  Ревьюер спецификации: ❌ Отсутствует: проверка надежности пароля (спецификация говорит «мин 8 символов»)

[Исполнитель исправляет]
  Исполнитель: Добавлена проверка, 7/7 тестов проходят.

[Повторное назначение ревьюера спецификации]
  Ревьюер спецификации: ✅ PASS

[Назначение ревьюера качества]
  Ревьюер качества: Важно: магическое число 8, вынести в константу
  Исполнитель: Вынесена константа MIN_PASSWORD_LENGTH
  Ревьюер качества: ✅ APPROVED

[Отметка задачи 2 как завершенной]

... (продолжить для всех задач)

[После всех задач: назначение финального ревьюера интеграции]
[Запуск полного набора тестов: все проходят]
[Готово!]

Запомните

Свежий подагент на задачу
Двухэтапное ревью каждый раз
Соответствие спецификации В ПЕРВУЮ ОЧЕРЕДЬ
Качество кода ВО ВТОРУЮ ОЧЕРЕДЬ
Никогда не пропускайте ревью
Выявляйте проблемы на ранних этапах

Качество — это не случайность. Это результат систематического процесса.

Дополнительное чтение (загружать при необходимости)

Когда оркестрация включает значительное использование контекста, длинные циклы ревью или сложные контрольные точки валидации, загрузите эти справочники для конкретной дисциплины:

references/context-budget-discipline.md — Четырехуровневая модель деградации контекста (PEAK / GOOD / DEGRADING / POOR), правила глубины чтения, масштабируемые в зависимости от размера окна контекста, и ранние признаки тихой деградации. Загружайте, когда запуск явно потребует значительного контекста (многофазные планы, много подагентов, большие артефакты).
references/gates-taxonomy.md — Четыре канонических типа шлюзов (Pre-flight, Revision, Escalation, Abort) с поведением, восстановлением и примерами. Загружайте при проектировании или проверке любого рабочего процесса, имеющего контрольные точки валидации — используйте словарь явно, чтобы каждый шлюз имел определенные правила входа, поведения при сбое и возобновления.

Метаданные навыка​

Справочник: полный SKILL.md​

Subagent-Driven Development

Обзор​

Когда использовать​

Процесс​

1. Чтение и разбор плана​

2. Рабочий процесс для каждой задачи​

Шаг 1: Назначение подагента-исполнителя​

Шаг 2: Назначение ревьюера соответствия спецификации​

Шаг 3: Назначение ревьюера качества кода​

Шаг 4: Отметка о завершении​

3. Финальное ревью​

4. Проверка и фиксация​

Гранулярность задач​

Красные флаги — Никогда так не делайте​

Обработка проблем​

Если подагент задает вопросы​

Если ревьюер находит проблемы​

Если подагент не справляется с задачей​

Замечания по эффективности​

Интеграция с другими навыками​

С plan​

С test-driven-development​

С requesting-code-review​

С systematic-debugging​

Пример рабочего процесса​

Запомните​

Дополнительное чтение (загружать при необходимости)​