Тулинг: скилл task-pipeline + два ревьювера качества
Скилл .claude/skills/task-pipeline оркеструет задачу по SDD от беклога до коммита (opsx explore→propose→ревью спек→apply→ревью кода→archive→чистка беклога), автономно, с выходом на пользователя только на развилках. Кастомные ревьюверы .claude/agents: jellybit-review-specs (оптика спек) и jellybit-review-code (архитектура/инварианты/конвенции/стиль). Подключены как чекпоинты скилла: на тривиальной задаче — один review-code, на нетривиальной — оба параллельно. Частично закрывает беклог-задачу agenty-revyuvery-kachestva: остался ревьювер наименований (ждёт словарь единого языка). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,136 @@
|
||||
---
|
||||
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 <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`), добейся зелёного.
|
||||
|
||||
### 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. Коммит
|
||||
|
||||
Коммить **прямо в master**, без feature-веток (память
|
||||
`commit-directly-to-master`). Сообщение — по-русски, в стиле недавних коммитов
|
||||
(`git log --oneline -8`): область + суть. Одна задача — один осмысленный коммит
|
||||
(или несколько по фазам, если так шёл apply).
|
||||
|
||||
Готово — доложи пользователю кратко: что сделано, какие развилки решались, ссылки
|
||||
на архивный change и спеки.
|
||||
|
||||
## Тонкости
|
||||
|
||||
- Не пропускай `openspec validate --strict` перед архивацией.
|
||||
- Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) оставляем, но
|
||||
одним сабагентом на всё. Два параллельных ревьювера — только на нетривиальных.
|
||||
- Если сабагент-ревьюер сам предлагает крупную переработку — это развилка, не
|
||||
правь молча, вынеси пользователю.
|
||||
- Держи пользователя в цикле короткими репликами на переходах фаз, но не проси
|
||||
подтверждать механику.
|
||||
Reference in New Issue
Block a user