dev-skills/av-dev-pipeline/skills/task-pipeline/SKILL.md

name, description

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