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/<номер>_*), не бери «следующий свободный» сам.
   • Ревью-чекпоинты: попробуй запустить агентов jellybit-review-specs / jellybit-review-code через Agent tool (как в task-pipeline). Если вложенный запуск сабагента недоступен — проведи ревью инлайн, используя charter'ы .claude/agents/jellybit-review-*.md как чеклист. Чекпоинт «ревью спек ДО кода» не пропускай.
   • Коммит. task-pipeline коммитит в текущую ветку — а это твоя task/<slug> в worktree, так что специально ничего переопределять не нужно. Всё остальное (opsx:archive, чистка беклога docs/backlog/<slug>.md + строка индекса, синк спек/ADR) ложится коммитами туда же. Master не трогай, ветку не переключай, ничего не пушь, новых worktree не создавай.
   • task test / task lint в своём 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 test (+ task lint) на 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 test + task lint (+ task build). Зелёное — обязательно.

7. Финальная сверка кода с требованиями — по затронутым capability

Собери объединение затронутых capability по всем задачам. Запусти по одному сабагенту-ревьюверу на каждую затронутую capability, все в одном сообщении (параллельно), subagent_type: jellybit-review-specs. Каждому дай:

• имя capability и путь openspec/specs/<cap>/spec.md;
• интегрированный diff git diff <база>..HEAD, сфокусированный на файлах этой capability;
• задание: сверить код на master с требованиями capability — покрытие ### Requirement (все содержат SHALL/MUST), сценарии GIVEN/WHEN/THEN, инварианты безопасности данных, непротиворечивость код↔спека после слияния нескольких задач (косвенные рассинхроны на стыках).

Опционально, если задач много и они пересекаются, добавь один jellybit-review-code на весь интегрированный diff (архитектура/конвенции/стиль сквозняком). Замечания отрабатывай как в task-pipeline: мелочь чини инлайн, развилки — на пользователя; после правок — снова task test/task lint.

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.
• Если сабагент вернул крупную переработку/смену подхода — это развилка, не вливай молча, вынеси пользователю.
• Держи пользователя в цикле короткими репликами на переходах фаз (план → волны → интеграция → финальная сверка), но не проси подтверждать механику.