--- name: task-pipeline description: Автономно проводит задачу jellybit через полный цикл SDD — от выбора в беклоге до коммита (opsx explore→propose→ревью спек→apply→ревью кода→archive→чистка беклога). Использовать, когда пользователь просит взять/сделать задачу из беклога или довести идею до реализации. --- # Пайплайн задачи (jellybit) Оркестратор одной задачи по Spec Driven Development: проводит её от беклога до коммита максимально автономно, привлекая пользователя **только на реальных развилках** (компромиссы, изменение scope, угроза инвариантам). Механику не согласовываем — делаем. Перед стартом прочитай `CLAUDE.md`, а также `README.md`, `BRIEF.md`, `docs/specs/architecture.md`, если ещё не в контексте. Это тонкая обёртка над каноническими скиллами `opsx:explore` / `opsx:propose` / `opsx:apply` / `opsx:archive` — вызывай их через Skill, не переизобретай их шаги. ## Принцип автономности Зови пользователя (через **AskUserQuestion**) только когда решение реально его: - **Выбор задачи**, если он не задан явно. - **Развилки грумминга** на explore: несколько равнозначных направлений, спорный scope, продуктовый компромисс. - **Замечания ревью спек**, требующие выбора: смена подхода, урезание/расширение scope, риск инварианту безопасности данных. - Всё остальное — механика: делаем без спроса. Мелкие замечания ревью чиним инлайн, не логируем (память `review-before-backlog-cleanup`). Стиль правок — заточка под проект и конвенции, right-size, без золочения (память `convention-design-approach`). ## Шаги ### 1. Выбрать / прочитать задачу - Если задача задана (slug, файл в `docs/backlog/`, ссылка Tududi или описание) — прочитай её файл и связанные спеки/ADR/черновики. - Если не задана — покажи топ-кандидатов из `docs/backlog/README.md` (высокий приоритет, не `[идея]`) через **AskUserQuestion** и дай выбрать. - Задача с префиксом `[идея]` (ещё без решения «делаем») — сперва обязательно через explore (шаг 2), там она либо становится задачей, либо остаётся идеей. Оцени тривиальность (влияет на шаг 4): - **Тривиальная** — локальная правка без изменения поведения/спек/схемы БД, очевидное решение. Explore и ревью спек пропускаем. - **Нетривиальная** — новое/изменённое поведение, дизайн-развилки, затрагивает инварианты, схему БД или несколько capability. Полный цикл. ### 2. (Опц.) Груммить идею — `opsx:explore` Только для `[идея]`-задач или когда постановка мутная. Вызови Skill `opsx:explore`. Развилки грумминга — на пользователя (AskUserQuestion). Выход: ясная постановка, готовая к propose. **В explore не пишем код.** ### 3. Завести change — `opsx:propose` Вызови Skill `opsx:propose`. Получаем `proposal.md`, дизайн (для нетривиальных), дельта-спеки (`ADDED`/`MODIFIED`/`REMOVED Requirements`), `tasks.md`. Каждое `### Requirement` содержит `SHALL`/`MUST`; структурные заголовки английские, сценарии `GIVEN/WHEN/THEN`. Прогони `openspec validate --strict `. ### 4. (Нетривиальная) Ревью спек — сабагент, ДО кода Первый чекпоинт ревью-процесса из CLAUDE.md. Запусти **один** сабагент `jellybit-review-specs` (Agent tool, `subagent_type`) в режиме «дизайн/спеки ДО кода». Charter самодостаточен — дай ссылку на change ``. Агент проверит полноту покрытия, сценарии `GIVEN/WHEN/THEN`, scope, инварианты безопасности данных, согласованность со спеками и capability-нарезкой, наличие `SHALL`/`MUST`. ### 5. Отработать замечания ревью спек - Мелочь и явные улучшения — правь сам в спеках/дизайне. - Развилки (компромисс, scope, инвариант) — на пользователя (AskUserQuestion). - После правок перепрогони `openspec validate --strict `. ### 6. Написать код — `opsx:apply` Вызови Skill `opsx:apply` для реализации `tasks.md`. Код по конвенциям `docs/conventions/*`: ошибки stdlib с `%w`/`errors.Is`, логи только `slog` без секретов, время в UTC через `store.Now()`, ULID через `internal/ident`, миграции goose + синк ER-схемы `docs/specs/database.md`, htmx по web-ui-конвенции. Прогони `task test` и `task lint` (или `task build`), добейся зелёного. **Поведенческая верификация (нетривиальные задачи с рантайм-поверхностью).** Если задача меняет реальное поведение (новый флоу, схема БД, эндпоинт/htmx-путь, разбор входа) — зелёных юнит-тестов мало: прогони через Skill **`verify`**, чтобы прокатить изменение end-to-end и увидеть его вживую, а не только в тестах. Пропусти для чисто внутренних правок без наблюдаемого рантайма (рефактор, доки, правка только тестов). Под `task-batch` verify идёт в worktree задачи — портами/БД не конфликтуй с соседними прогонами. ### 7. Ревью кода — сабагент(ы) Второй чекпоинт. Ревьюеры — кастомные агенты из `.claude/agents/` (запускай их через Agent tool с `subagent_type`). Число зависит от тривиальности: - **Тривиальная задача — один сабагент** `jellybit-review-code`. В промпте добавь просьбу дополнительно **бегло сверить соответствие дельта-спекам и tasks.md** (он единственный, покрывает и спеки, и конвенции). - **Нетривиальная — два параллельных сабагента одним сообщением**, чтобы шли конкурентно: `jellybit-review-specs` (оптика спек) и `jellybit-review-code` (оптика архитектуры/конвенций/стиля). Charter'ы агентов самодостаточны — детальный промпт писать не нужно, дай ссылку на change (``) и diff/список файлов (`git diff`). Отработай так же, как шаг 5: мелочь чини инлайн, развилки — на пользователя. После правок — снова `task test`/`task lint`. ### 8. Архивировать — `opsx:archive` Вызови Skill `opsx:archive`: change уезжает в `openspec/changes/archive/`, дельты вливаются в `openspec/specs/`. ### 9. Закрыть беклог и синк доков Ревью выполненного — **до** чистки (память `review-before-backlog-cleanup`). Затем: - Удали файл задачи `docs/backlog/.md` и строку в `docs/backlog/README.md` (реализованное не держим в беклоге — CLAUDE.md). - Суть переехавшего решения — в `docs/specs`/`docs/adr`, если ещё не там. - Если менялась структура БД — убедись, что ER-схема `docs/specs/database.md` обновлена в этом же change. ### 10. Коммит Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не создавай и не переключай, ничего не пушь. Это работает в обоих режимах: - **Ручной запуск** — HEAD обычно на `master`, коммит идёт прямо в него, без feature-веток (память `commit-directly-to-master`). - **Под оркестратором `task-batch`** — HEAD на ветке задачи в изолированном worktree (`task/`); коммит идёт туда, а слияние в `master` через rebase/ff делает оркестратор. Ничего дополнительно делать не нужно. Сообщение — по-русски, в стиле недавних коммитов (`git log --oneline -8`): область + суть. Одна задача — один осмысленный коммит (или несколько по фазам, если так шёл apply). Готово — доложи пользователю кратко: что сделано, какие развилки решались, ссылки на архивный change и спеки. ## Тонкости - **Не завязывайся на master и корень репо.** Скилл работает в текущем worktree и на текущей ветке: не делай `git checkout`/`switch`, не создавай веток, не пушь. При одиночном запуске это master, под `task-batch` — ветка задачи в своём worktree; поведение одинаковое. - Не пропускай `openspec validate --strict` перед архивацией. - Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) оставляем, но одним сабагентом на всё. Два параллельных ревьювера — только на нетривиальных. - Если сабагент-ревьюер сам предлагает крупную переработку — это развилка, не правь молча, вынеси пользователю. - Держи пользователя в цикле короткими репликами на переходах фаз, но не проси подтверждать механику.