Ты знаешь три приёма: независимое — в параллель, зависимое — по очереди, конфликтующее по файлам — в отдельные worktree. Пора собрать их в один план оркестрации для реального задания.
Три шага планирования
- Разбей задание на куски. Каждый кусок — то, что можно отдать одному субагенту.
- Нарисуй стрелки зависимостей. Между какими кусками есть «сначала → потом»? Где стрелки нет — кандидаты на параллель.
- Проверь на гонки. Не пишут ли параллельные куски в один файл и не делят ли состояние? Если да — разнеси их по worktree или переведи в последовательность.
Пример: большой рефакторинг магазина
Задание — переименовать модуль cart в basket по всему проекту, добавить тесты и обновить документацию. Разложим:
- A — найти все упоминания
cartв коде (поиск, объёмный, ни от кого не зависит); - B — переименовать и поправить импорты (нужен список из A);
- C — написать тесты для нового
basket(нужен код из B); - D — обновить документацию (зависит от B, но трогает другие файлы, чем C).
Стрелки: A → B → (C и D). Значит, A и B — строго по очереди. А вот C и D после B независимы между собой — разные файлы, общего состояния нет, — их пускаем параллельно, каждому свою worktree, чтобы не пересеклись.
Совет
План почти всегда гибрид: кусок последовательной цепочки, из которого «распускается» веер параллельных задач. Узкое место — самая длинная цепочка зависимостей; всё остальное стоит делать вокруг неё параллельно.
Порепетируй
Практика в терминале
Теперь зафиксируй план как дирижёр: запиши в `plan.md` двумя строками, что идёт по очереди, а что параллельно. Первую строку создаёт `echo` с `>`, вторую дописывает `echo` с `>>`, а `cat plan.md` показывает план целиком перед запуском бригады.