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), там она либо становится задачей, либо остаётся идеей.

Формат файла задачи и индекса держит скилл backlog — здесь мы беклог только читаем. Если по ходу выбора вскрылось, что задача устарела, дублируется или разрослась в эпик, это работа для скилла backlog, а не для пайплайна.

Оцени тривиальность (влияет на шаг 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. (Нетривиальная) Ревью предложения — профиль design, ДО кода

Первый чекпоинт ревью-процесса. Вызови Skill review-pipeline с профилем design и ссылкой на change <id>. Он запустит jellybit-review-specs (режим «дизайн/спеки ДО кода»), jellybit-review-rubric (фаза 1: приёмочные критерии для задуманного узла), jellybit-review-idiom и jellybit-review-architecture по предложению.

Смысл профиля: архитектурная находка на готовом коде стоит переписывания и потому игнорируется — та же находка здесь стоит абзаца обсуждения. Рубрику из jellybit-review-rubric перенеси в tasks.md как приёмочные критерии.

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 gate и добейся зелёного — он же гейт следующего шага.

Поведенческая верификация (нетривиальные задачи с рантайм-поверхностью). Если задача меняет реальное поведение (новый флоу, схема БД, эндпоинт/htmx-путь, разбор входа) — зелёных юнит-тестов мало: прогони изменение вживую через Skill run, чтобы увидеть его end-to-end, а не только в тестах. Пропусти для чисто внутренних правок без наблюдаемого рантайма (рефактор, доки, правка только тестов). Под task-batch запуск идёт в worktree задачи — портами/БД не конфликтуй с соседними прогонами.

7. Ревью кода — Skill review-pipeline

Второй чекпоинт. Вызови Skill review-pipeline, дав ссылку на change <id>, базу диффа и профиль. Профиль выбирается по факту изменения, а не по ощущению важности (правило — в самом скилле):

• миграция, новый пакет, изменение публичного контракта, раскладка файлов/пути → deep;
• иначе меняется поведение, видимое снаружи → standard;
• иначе (багфикс, локальная правка, доки) → quick.

Скилл сам гоняет гейт, нужные проходы и обязательный триаж. Возвращает отчёт с потолком 7 пунктов, разметкой Действие: инлайн | развилка и секцией границ покрытия.

Отработай так же, как шаг 5: помеченное инлайн чини сам и не логируй, развилка — на пользователя через AskUserQuestion (вопрос уже сформулирован триажем). После правок — снова task gate.

Границы покрытия из отчёта не выбрасывай — они уезжают в финальный доклад (шаг 10) сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно», превращается в ложное ощущение проверенности.

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. Реализованное не держим в беклоге и на кладбище CLOSED.md не пишем — у него есть коммит, спека и ADR (формат — скилл backlog).
• Суть переехавшего решения — в docs/specs/docs/adr, если ещё не там.
• Если менялась структура БД — убедись, что ER-схема docs/specs/database.md обновлена в этом же change.
• Проверь согласованность индекса командой check скилла backlog — индекс не должен ссылаться на удалённый файл.

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) остаётся всегда, но в профиле quick — гейт, сверка со спекой, триаж.
• Гейт блокирует: пока task gate красный, опиниативные проходы не запускаются. Чинить и перезапускать, а не «посмотреть заодно».
• Если ревью предлагает крупную переработку — это развилка, не правь молча, вынеси пользователю.
• Держи пользователя в цикле короткими репликами на переходах фаз, но не проси подтверждать механику.