avandClaude Opus 4.8
c28745f369
Скилл беклога переехал из глобального ~/.claude/skills в плагин av-dev-backlog (маркетплейс av-dev-skills). Подключаем его на уровне проекта через .claude/settings.json (extraKnownMarketplaces + enabledPlugins по git-URL), чтобы был активен у всех, кто открывает репозиторий. Правки в доках под новую раскладку: - task-pipeline: убран зашитый путь к backlog.py (его больше нет) — проверка индекса идёт командой check самого скилла; - CLAUDE.md: зафиксировано, что скилл backlog поставляется плагином и как вызывается. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
178 lines
14 KiB
Markdown
178 lines
14 KiB
Markdown
---
|
||
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), там она либо становится задачей, либо остаётся идеей.
|
||
|
||
Формат файла задачи и индекса держит скилл `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` красный, опиниативные проходы не запускаются.
|
||
Чинить и перезапускать, а не «посмотреть заодно».
|
||
- Если ревью предлагает крупную переработку — это развилка, не правь молча,
|
||
вынеси пользователю.
|
||
- Держи пользователя в цикле короткими репликами на переходах фаз, но не проси
|
||
подтверждать механику.
|