jellybit/.claude/skills/task-batch/SKILL.md

name, description

name

description

task-batch

Автономно проводит несколько задач jellybit из беклога разом — планирует порядок и зависимости, гонит каждую задачу отдельным сабагентом в своём git worktree через task-pipeline, интегрирует в master по одной ветке через rebase/ff (линейная история), в конце прогоняет все тесты и сверяет код с требованиями по каждой затронутой capability. Использовать, когда пользователь просит взять/сделать несколько задач из беклога сразу.

Батч задач (jellybit)

Оркестратор набора задач по Spec Driven Development. Планирует порядок, раскидывает задачи по изолированным worktree, каждую проводит через полный цикл task-pipeline, затем сводит в master линейной историей и делает финальную сверку. Тонкая обёртка над task-pipeline — не переизобретай её шаги, вызывай как есть.

Работай максимально автономно. Зови пользователя (через AskUserQuestion) только на реальных развилках — как в task-pipeline. Механику — планирование, worktree, rebase, интеграцию, чистку — делаем без спроса.

Перед стартом прочитай CLAUDE.md, README.md, BRIEF.md, docs/specs/architecture.md, если ещё не в контексте.

Ключевое отличие от одиночного пайплайна

task-pipeline коммитит прямо в master (память commit-directly-to-master). Здесь это невозможно для параллельных задач, поэтому батч — осознанное исключение: заводим временные ветки/worktree лишь как средство изоляции, а конечное состояние — та же линейная trunk-based история master через rebase + fast-forward. Ветки после вливания удаляем. Дух памяти (линейный master без мусорных мёрджей) сохраняется.

Модель исполнения

• Каждая задача = один автономный сабагент (general-purpose, чтобы иметь доступ к Skill и Agent для вложенных ревью-чекпоинтов), работающий только в своём worktree и прогоняющий task-pipeline целиком на этой задаче.
• Оркестратор (главный агент) не пишет код задач сам — он планирует, заводит worktree, запускает сабагентов, интегрирует ветки в master и делает финальную сверку.
• Стиль правок внутри — заточка под проект и конвенции, right-size, без золочения (память convention-design-approach).

Шаги

1. Выбрать набор задач

• Если набор задан (список slug'ов/файлов, «топ-3 высоких», «эти три») — используй.
• Иначе покажи кандидатов из docs/backlog/README.md (высокий приоритет, не [идея]) через AskUserQuestion (multiSelect) и дай выбрать.
• [идея]-задачи включаются, но помни: сабагент проведёт их сперва через opsx:explore (см. task-pipeline) — это тяжелее и может упереться в развилку.

Прочитай файл каждой выбранной задачи и связанные спеки/ADR/черновики.

2. Спланировать порядок, зависимости и конфликты (автономно)

Для каждой задачи определи по её файлу и capability-map (память):

• Затронутые capability (из 11: identity, ingest, download-tracking, recognition, metadata-match, review, file-layout, state-reconciliation, notifications, web-ui, live-status).
• Жёсткие зависимости: задача B строится на результате A → A строго раньше B.
• Миграции БД — пред-назначение номеров (не сериализация). Определи, какие задачи, вероятно, добавят миграцию (новая таблица/столбец/индекс/связь), и заранее раздай им номера: посмотри последний номер в internal/store/migrations/ и назначь 0012, 0013, … по одной на задачу. Номер уходит в charter сабагента (шаг 4). Так migration-задачи можно гнать параллельно — файлы миграций не столкнутся, а docs/specs/database.md (ER-схема) правят разные строки, textual-конфликт при rebase мелкий и решается на интеграции.
• Жёстко сериализуем (не гоняем одновременно) только настоящие пересечения:
  • Одна capability на несколько задач: две задачи, правящие одну capability (тем более один и тот же ### Requirement в её спеке), дают не текстовый, а семантический конфликт при archive — сериализуем по смыслу, а не только по файлам.
  • Пересечение по одним и тем же исходникам.
• Мягкие конфликты (обычно авто-мёрджатся при rebase, сериализовать не надо): docs/backlog/README.md (каждая задача убирает свою строку) и openspec/specs/<cap> разных capability (archive вливает дельты) — разные строки/файлы.

Собери план: волны параллельно-безопасных задач + сериализованный хвост конфликтоопасных, с учётом зависимостей. Покажи план короткой репликой и иди дальше. AskUserQuestion — только если порядок реально неоднозначен или задачи глубоко связаны продуктово.

3. Свежий master как база

Убедись, что рабочее дерево чистое и master свежий (git status, при наличии remote — git fetch и синк). Зафиксируй базовый коммит. Новые ветки бери от свежего master; ветки следующей волны — от master, уже включающего результат предыдущих волн.

4. Прогнать волны

Потолок параллелизма — 2–3 задачи одновременно. Каждая задача тянет полный task-pipeline + вложенные ревью + task test/go build, поэтому больше трёх разом душат домашнюю машину и провоцируют гонки. Волну шире трёх бей на под-пачки по ≤3 и гони их последовательно.

Для каждой задачи в под-пачке:

1. Заведи worktree + ветку от текущего вершинного master: git worktree add <path> -b task/<slug> master. Путь — рядом с репо или в ./tmp/ (память use-project-tmp-dir; НЕ в системном /tmp). Имя ветки — task/<slug>.
2. Запусти по одному сабагенту на задачу, все в одном сообщении (конкурентно, но не больше трёх), subagent_type: general-purpose. Charter сабагента:
   • Работай строго в своём worktree <path>; в другие каталоги и в master не лезь.
   • Прогони skill task-pipeline ровно на этой задаче (<slug>/файл), полный цикл SDD с промежуточными ревью-чекпоинтами.
   • Если задаче на шаге 2 назначен номер миграции — используй строго его (internal/store/migrations/<номер>_*), не бери «следующий свободный» сам.
   • Ревью-чекпоинты: оба идут через Skill review-pipeline (профиль design до кода, потом профиль по факту изменения). Если вложенный запуск сабагентов недоступен — проведи ревью инлайн по тем же charter'ам .claude/agents/jellybit-review-*.md, но обязательно сохрани гейт (task gate до опиниативных проходов) и триаж; в отчёте прямо укажи, что ревью шло инлайн — это меняет доверие к результату.
   • Коммит. task-pipeline коммитит в текущую ветку — а это твоя task/<slug> в worktree, так что специально ничего переопределять не нужно. Всё остальное (opsx:archive, чистка беклога docs/backlog/<slug>.md + строка индекса, синк спек/ADR) ложится коммитами туда же. Master не трогай, ветку не переключай, ничего не пушь, новых worktree не создавай.
   • task gate в своём worktree — добейся зелёного.
   • Верни отчёт: что сделано, какие развилки решались, изменённые файлы, добавлял ли миграцию и её номер, затронутые capability, статус тестов/линта, все неразрешённые вопросы.

Если сабагент упирается в развилку, которую task-pipeline выносит на пользователя, — он останавливает свою задачу и возвращает вопрос; оркестратор собирает такие вопросы и выносит их пользователю (AskUserQuestion), остальные задачи при этом продолжаются.

5. Интегрировать в master — rebase + fast-forward, по одной ветке

Сводим ветки в master строго последовательно (линейная история), в порядке зависимостей — по одной ветке за раз. Вливаем только зелёные ветки: провалившиеся/зависшие задачи в интеграцию не берём (см. политику ниже).

Для каждой готовой (зелёной) ветки task/<slug>:

• git rebase master task/<slug> — перенос ветки на текущую вершину master.
• Резолв конфликтов (их почти нет — конфликтоопасное сериализовано, номера миграций розданы заранее). Если rebase дал неавтоматический конфликт — не форсируй: прерви (git rebase --abort), оставь ветку/worktree как есть и вынеси развилку пользователю (это признак нераспознанного пересечения).
• git checkout master && git merge --ff-only task/<slug>.
• После каждой интеграции: task gate на master. Красное — откати эту интеграцию (git reset --hard на прошлую вершину master), ветку с worktree сохрани, вынеси пользователю. Master никогда не остаётся полузелёным.
• Только после зелёного: git worktree remove <path> и git branch -d task/<slug>.

Так каждая следующая ветка ребейзится на уже обновлённый master — история линейна, каждая задача = свой осмысленный коммит (или несколько по фазам apply).

Политика частичного провала. Если задача упала (сабагент вернул неразрешённую развилку, тесты в её worktree красные, rebase/merge конфликтует) — она не блокирует остальные: интегрируем все зелёные, упавшую оставляем в её worktree и ветке нетронутой (ничего не удаляем), и в финальном докладе (шаг 8) перечисляем провалившиеся с их отчётами и причиной. Пользователь потом решит: дожать вручную, переназначить, отложить.

6. Финальный гейт

На master после всех интеграций: task gate (+ task build). Зелёное — обязательно; пока красное, шаг 7 не начинается.

7. Финальная сверка — только то, чего не видел никто

Каждая задача уже прошла полный конвейер ревью в своём worktree. Повторять его на интегрированном диффе бессмысленно: те же проходы на тех же файлах дадут те же находки и удорожат триаж. Здесь проверяется только то, что появилось от слияния и потому не было видно ни одному прогону:

• Запусти по одному jellybit-review-specs на каждую затронутую capability, все в одном сообщении (параллельно). Задание сузь до стыков: не сверять capability целиком заново, а искать рассинхрон код↔спека, возникший от слияния нескольких задач — требование, которое одна задача выполнила, а соседняя незаметно отменила; два change, по-разному описавшие одно поведение.
• Если задачи пересекались по файлам, добавь один jellybit-review-architecture на интегрированный дифф с вопросом «не появился ли второй способ делать то, что уже делается» — именно он возникает, когда две задачи независимо решали похожее.

Замечания отрабатывай как в task-pipeline: инлайн чини сам, развилка — на пользователя; после правок — снова task gate.

8. Прибраться и доложить

• Убери worktree/ветки только успешно влитых задач (git worktree remove + git branch -d уже сделаны на шаге 5); в конце git worktree prune. Worktree/ветки провалившихся задач не трогай — они нужны пользователю для ручного дожатия.
• Доложи кратко: какие задачи сделаны, план волн и порядок интеграции, какие развилки решались, коммиты по задачам, итог финальной сверки, ссылки на архивные change. Отдельно перечисли провалившиеся задачи с причиной, их отчётом и путём к оставленному worktree/ветке.

Тонкости

• Номера миграций раздаёт оркестратор (шаг 2), сабагент берёт назначенный, а не «следующий свободный» — тогда migration-задачи безопасны параллельно.
• Изоляция параллельных тестов. Прежде чем гнать несколько task test разом, убедись, что тесты не делят фиксированный TCP-порт или файл БД (обычно берут t.TempDir()/эфемерный порт — тогда ок). Если делят — гони такие тесты последовательно, а не в параллельной под-пачке.
• Ревью выполненного — до чистки беклога; это забота task-pipeline внутри каждого сабагента (память review-before-backlog-cleanup). Оркестратор дублировать не должен.
• Не пропускай openspec validate --strict — это тоже внутри task-pipeline.
• Если сабагент вернул крупную переработку/смену подхода — это развилка, не вливай молча, вынеси пользователю.
• Держи пользователя в цикле короткими репликами на переходах фаз (план → волны → интеграция → финальная сверка), но не проси подтверждать механику.