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

name, description

name	description
task-pipeline	Автономно проводит задачу 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 <id>.

4. (Нетривиальная) Ревью спек — сабагент, ДО кода

Первый чекпоинт ревью-процесса из CLAUDE.md. Запусти один сабагент jellybit-review-specs (Agent tool, subagent_type) в режиме «дизайн/спеки ДО кода». Charter самодостаточен — дай ссылку на change <id>. Агент проверит полноту покрытия, сценарии GIVEN/WHEN/THEN, scope, инварианты безопасности данных, согласованность со спеками и capability-нарезкой, наличие SHALL/MUST.

5. Отработать замечания ревью спек

• Мелочь и явные улучшения — правь сам в спеках/дизайне.
• Развилки (компромисс, scope, инвариант) — на пользователя (AskUserQuestion).
• После правок перепрогони openspec validate --strict <id>.

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 (<id>) и 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/<slug>.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/<slug>); коммит идёт туда, а слияние в master через rebase/ff делает оркестратор. Ничего дополнительно делать не нужно.

Сообщение — по-русски, в стиле недавних коммитов (git log --oneline -8): область

• суть. Одна задача — один осмысленный коммит (или несколько по фазам, если так шёл apply).

Готово — доложи пользователю кратко: что сделано, какие развилки решались, ссылки на архивный change и спеки.

Тонкости

• Не завязывайся на master и корень репо. Скилл работает в текущем worktree и на текущей ветке: не делай git checkout/switch, не создавай веток, не пушь. При одиночном запуске это master, под task-batch — ветка задачи в своём worktree; поведение одинаковое.
• Не пропускай openspec validate --strict перед архивацией.
• Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) оставляем, но одним сабагентом на всё. Два параллельных ревьювера — только на нетривиальных.
• Если сабагент-ревьюер сам предлагает крупную переработку — это развилка, не правь молча, вынеси пользователю.
• Держи пользователя в цикле короткими репликами на переходах фаз, но не проси подтверждать механику.