---
name: task-pipeline
description: Автономно проводит одну задачу через полный цикл Spec Driven Development — от постановки до коммита (opsx explore→propose→ревью спек профилем design→apply→ревью кода→archive→коммит), с обязательными чекпоинтами ревью и докладом об исходе. Использовать, когда просят взять/сделать задачу или довести идею до реализации.
---

# Пайплайн задачи

Оркестратор **одной** задачи по Spec Driven Development: проводит её от
постановки до коммита максимально автономно. Механику не согласовываем — делаем.

Это тонкая обёртка над каноническими скиллами `opsx:explore` / `opsx:propose` /
`opsx:apply` / `opsx:archive` — вызывай их через Skill, не переизобретай их шаги.
Ревью — скилл `av-dev-pipeline:review-pipeline`, он же держит правило выбора
профиля.

## Предпосылки

- **OpenSpec и скиллы `opsx:*`** — внешняя обвязка, на которой стоят шаги 2, 3, 6
  и 8, а также проход `review-specs` и профиль `design` (они завязаны на
  `openspec/changes/<id>/specs/*/spec.md` и на `openspec validate --strict`). В
  проекте без OpenSpec эти шаги упадут на «нет такого скилла»: либо подключаем
  OpenSpec, либо цикл вырождается в «прочитать задачу → код → ревью кода →
  коммит», и об отсутствии спекового контура говорится в докладе.
- **Скиллы зовутся с пространством имён** — `av-dev-pipeline:review-pipeline`,
  `av-dev-pipeline:project-brief`. Короткое имя может разрешиться в устаревшую
  проектную копию, и это произойдёт молча.
- **Проектные копии этих скиллов и агентов удаляются при установке плагина**
  (`.claude/skills/{task-pipeline,review-pipeline,task-batch}`,
  `.claude/agents/<проект>-review-*.md`). Две копии одного скилла расходятся, и
  побеждает та, что короче названа.

Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается
(архитектура, конвенции), если ещё не в контексте. Проектные факты, нужные ревью
— инварианты, команда гейта, объёмы, модель угроз, прецеденты, — живут в брифе
(`docs/review-brief.md`, контракт — в references конвейера ревью).

**Брифа нет ни по одному пути — заведи его, а не работай в деградированном
режиме.** Вызови Skill **`av-dev-pipeline:project-brief`**: он соберёт бриф из
`CLAUDE.md`, архитектуры, файла задач и конвенций, покажет человеку и вернёт
путь, который дальше передаётся ревью. Это механика: спрашивать разрешения не
нужно. Один шаг один раз на проект — против деградации на каждой задаче.

## Границы: чем пайплайн не владеет

- **Беклогом, спринтом, целями и приоритетами.** Задача приходит извне. Пайплайн
  её не выбирает, не приоритизирует, не заводит и не переоценивает; если в
  проекте есть свой процесс управления задачами — он и решает, что брать.
- **Записями учёта.** Пайплайн **не закрывает задачу**, не двигает её по
  статусам, не правит индекс и не зовёт скриптов учёта. Он сообщает исход;
  закрытие — акт владельца спринта **после приёмки**, и оно происходит снаружи.
  Закрыть задачу самому — значит закрыть её до коммита и до всякой приёмки, то
  есть заверить собственную работу.
- **Заведением задач из урожая ревью.** Отложенные находки отдаются **списком**
  (см. шаг 7); превращать их в задачи — работа того, кто ведёт задачи проекта.
- **Определением ценности.** «Нужна ли эта функциональность» — не вопрос
  пайплайна ни на одном шаге.

Пайплайн владеет **своим** определением готовности (ниже) и **сообщает
наблюдаемый исход**. Что с исходом делать дальше — не его дело.

## Наблюдаемые исходы

Ровно три, и каждый обязан быть назван в докладе прямо:

- **сделана** — определение готовности выполнено целиком;
- **не доведена** — с причиной и с записанным вопросом; что именно сделано и до
  какой границы, названо явно;
- **оказалась крупнее задачи** — распознаётся **до заведения change**, иначе его
  придётся выбрасывать. Дальше — декомпозиция, и это не работа пайплайна.

## Определение готовности

Задача сделана, когда верно всё:

1. гейт проекта зелёный;
2. ревью проведено **по профилю**, состав прогона сверен с таблицей профилей
   поимённо, непущенные проходы названы в границах покрытия;
3. change заархивирован, дельты влиты в актуальные спеки;
4. коммит сделан в текущую ветку;
5. **критерии приёмки, если проект их дал, выписаны поимённо, и по каждому назван
   оракул и наблюдаемый исход** — «прогнал вот это, увидел вот то». Это **доклад,
   а не сертификация: приёмка — не работа пайплайна.** Исполнитель, ставящий себе
   галочку «принято», проверяет свою работу своим же взглядом — по границе это
   может делать только декоррелированный приёмщик. Критерии приходят снаружи;
   пайплайн их не сочиняет и не занижает. Расхождение «по каждому критерию исход
   есть, а суть задачи не достигнута» — дефект критериев, и о нём сообщается, а
   не молча дорабатывается.

Пункты 1–4 — своё. Пункт 5 — внешнее: пайплайн доводит его до наблюдаемого
исхода и передаёт дальше.

## Принцип автономности

**Умолчание — делать, а не спрашивать.** Задача доводится до коммита без участия
человека; предполагается, что так пройдёт большинство задач.

Наткнулся на вопрос, который решать не тебе, — **не останавливайся и не
спрашивай**. Запиши его и продолжай:

1. **Запиши вопрос там, где проект держит вопросы** (секция беклога, файл
   задачи, трекер — это знает проект). Если проект не сказал, куда, — отдельной
   секцией `Вопросы` в своём докладе, и это тоже исход. Тело отвечает на три
   вещи: **что именно решить**, **какие есть варианты и цена каждого**, **что
   стоит, пока решения нет**. Плюс твоя рекомендация — человек чаще соглашается,
   чем выбирает заново, и готовое суждение экономит ему весь контекст.
2. **Переформулируй задачу на остаток** — то, что делается без этого решения.
   Назови границу: докуда доводим сейчас.
3. Доведи остаток до конца и закоммить. Задача не «висит на вопросе», она сделана
   в объявленных границах.

**Что остатком не является — правило живёт не здесь.** Канонический текст с обеими
оговорками — в плагине `av-dev-tasks`, скилл `av-dev-tasks:session`, раздел
`## Вопрос, блокер, необратимое`, подраздел «Отличать вопрос от застревания».
Правило принадлежит управлению задачами, потому что решает **сделана задача или
вышла**, — это исход планирования, а не исполнения. **Ссылайся, не
пересказывай:** копия, заведённая здесь, уже однажды разошлась с оригиналом и
потеряла из перечня самое необратимое — запись **наружу**.

Коротко, чтобы знать, когда идти читать: остаток проверяется двумя порогами —
**материализация нерешённого** (запись состояния, зависящего от неотвеченного
вопроса) и **пол по пользе** (из остатка пропала польза, названная в постановке).
Оба порога — стоп: первый поднимает решение до начала записи, второй даёт исход
«не доведена».

Плагин `av-dev-tasks` не подключён — правило не отменяется, а становится
осторожнее: прежде чем записать зависящее от нерешённого куда бы то ни было —
в хранилище, в журнал, в витрину или наружу, — спрашивай человека.

Нет полезного остатка — задача заканчивается исходом «не доведена», вопрос
записан, ничего не коммитится наполовину.

### Когда всё-таки спрашивать

Узко и по другому основанию — не «сложное решение», а **необратимое действие**:

- деплой, выкладка наружу, смена публичного адреса или токенов;
- удаление или перезапись рабочих данных, включая подрезку архивов;
- всё, что уходит за пределы машины.

Здесь ошибка не откатывается коммитом, поэтому спрашиваем даже когда решение
кажется очевидным. Развилка в дизайне — вопрос в запись; необратимое действие —
вопрос человеку сейчас.

Стиль правок — заточка под проект и конвенции, right-size, без золочения.

## Шаги

### 1. Прочитать задачу

Задача задана извне (slug, файл, ссылка, описание) — прочитай её и связанные
спеки и черновики. Не задана — попроси у вызывающего; сам в беклог не лезь и
приоритеты не интерпретируй.

Если проект даёт задаче **критерии приёмки**, выпиши их сразу: на шаге 3 они
уезжают в `tasks.md` change. Файл задачи может быть удалён до коммита, а
критерии обязаны его пережить.

Оцени тривиальность (влияет на шаг 4):

- **тривиальная** — локальная правка без изменения поведения, спек и схемы,
  решение очевидно. Explore и ревью спек пропускаются;
- **нетривиальная** — новое или изменённое поведение, дизайн-развилки, задеты
  инварианты, схема или несколько capability. Полный цикл.

Здесь же — проверка на «крупнее задачи»: если видно, что одним заходом это не
мерджится, объявляй исход **до** заведения change.

### 2. (Опц.) Груммить идею — `opsx:explore`

Только для идей и мутных постановок. Вызови Skill `opsx:explore`. Развилку
грумминга не выноси на человека — запиши вопросом и груми остаток. Выход: ясная
постановка, готовая к 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>`.

Критерии приёмки задачи, если они были, копируются в `tasks.md` отдельным блоком.

### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода

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

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

### 5. Отработать замечания ревью предложения

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

### 6. Написать код — `opsx:apply`

Вызови Skill `opsx:apply` для реализации `tasks.md`. Код — по конвенциям проекта
(файл назван в разделе `## Карта` брифа). Меняешь схему — обнови её описание в
документации тем же change, если проект этого требует: гейт обычно это проверяет.

Прогони гейт и добейся зелёного — он же гейт следующего шага.

**Поведенческая верификация.** Если задача меняет реальное поведение (новый
эндпоинт, разбор входа, схема, форма ответа) — зелёных юнит-тестов мало. Подними
изменение вживую командой из раздела `## Команды` брифа и прогони сценарий.
Пропусти только для чисто внутренних правок без наблюдаемого рантайма.

**Сервис не оставляем лежать.** Если запуск упал — почини или откати до конца
шага.

### 7. Ревью кода — Skill `av-dev-pipeline:review-pipeline`

Второй чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`**, дав ссылку
на change `<id>`, базу диффа, путь к брифу, профиль **и режим запуска**.

**Правило выбора профиля живёт в скилле конвейера** (раздел «Профили»), проектные
триггеры — в разделе `## Триггеры` брифа. Здесь оно не пересказывается: три
копии одного правила расходятся, и работать будет та, которую прочитали
последней. Помни ровно одно — **профиль выбирается по факту изменения, а не по
ощущению важности**, и посмотри таблицу перед вызовом.

**Режим по умолчанию последовательный, и обосновывать его не надо.** Параллельно
гоняем только тогда, когда об этом попросили явно **и назвали набор** — какие
именно проходы или какую стадию. Просьба без набора основанием не считается:
гони последовательно и скажи строкой, что набор не был назван. Причина умолчания
— замеры: `adversary` и `ops` доказывают находки числами, а два меряющих прохода
на одной машине портят числа друг другу; находка с испорченным оракулом хуже
отсутствующей, потому что выглядит доказанной.

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

**Сверь состав прогона с таблицей профилей в скилле, прежде чем коммитить.**
Отчёт обязан называть запущенные проходы **поимённо и с исходом**; непущенный
идёт строкой «не запускался» в границы покрытия. Реестр короткий (4–8 проходов) —
сверка стоит одного взгляда. Почему это правило существует, объясняет раздел
«Профили» скилла конвейера; здесь — само требование.

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

**Урожай — списком, не задачами.** Отложенные находки (реальный `major` не для
этого мерджа, развилка, решённая «потом», пачка `nit`) собери в секцию доклада
`Урожай`: формулировка, оракул, провенанс. Задачи из него **заводит не пайплайн**
— у того, кто ведёт задачи проекта, своя нарезка, свой формат и свои правила
дублей. Твоя обязанность — не потерять и передать.

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

**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`) — это
обязательно, а не «если удобно».** По нему потом видно, что было найдено и что из
этого осталось в урожае. И это единственный **независимый** артефакт о составе
прогона: под оркестратором `task-batch` именно по нему сверяют полноту ревью
ветки, а не по твоей прозе — она написана тем же, кто мог проход и пропустить.

### 8. Архивировать — `opsx:archive`

Вызови Skill `opsx:archive`: change уезжает в архив, дельты вливаются в
актуальные спеки.

### 9. Синк документации

Ревью выполненного — до этого шага. Затем:

- суть переехавшего решения — в документацию проекта (архитектура, журнал
  решений), если её там ещё нет;
- менялась схема — её описание обновлено тем же change;
- новое, узнанное о внешнем формате или о данных, — в тот файл проекта, который
  это накапливает; такой файл обычно ценнее кода;
- воспроизведённый дефект (свой или чужой) — в раздел `## Прецеденты` брифа:
  класс, симптом, чем воспроизведён, чем закончилось. Это единственный артефакт,
  который делает следующее ревью умнее.

**Задачу пайплайн не закрывает.** Записи учёта — индекс, статус, спринт — он не
трогает вовсе: закрытие происходит **после приёмки** и делается владельцем
спринта, а пайплайн на этом шаге стоит до коммита и до всякой приёмки. Скриптов
и скиллов учёта не зови — их у тебя и нет: пути между плагинами не разрешаются, и
моста здесь намеренно не проложено. Твоё дело — назвать исход в докладе.

### 10. Коммит

Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
создавай и не переключай, ничего не пушь. При ручном запуске HEAD обычно на
основной ветке — коммит идёт прямо в неё; под оркестратором `task-batch` HEAD на
ветке задачи в изолированном worktree, и делать дополнительно ничего не нужно.

Сообщение — по-русски, скиллом `commit`, если он подключён (первая строка «что
сделано», тело списком 1–3 пункта, без трейлеров). Одна задача — один осмысленный
коммит.

Готово — доложи кратко. Доклад и есть выход пайплайна: **задача остаётся
открытой**, её закрывает владелец спринта после приёмки.

- **исход** задачи одним из трёх слов и, если не «сделана», чем ограничен
  результат;
- что сделано, какие вопросы записаны и куда;
- ссылка на архивный change и хеш коммита;
- по каждому критерию приёмки, если они были: **оракул и наблюдаемый исход** —
  это доклад приёмщику, а не отметка «принято»;
- **`Урожай`** — отложенные находки списком (формулировка, оракул, провенанс).
  Задачи из него заводит тот, кто ведёт задачи проекта;
- **одна строка границ покрытия**: какой профиль и режим гонялись, какие проходы
  не запускались и что проверить было невозможно. Доклад без неё сообщает
  «проверено», не сообщая, что именно.

## Тонкости

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