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

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