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

name, description

name

description

task-pipeline

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

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

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

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

Предпосылки

• OpenSpec и скиллы opsx:* — жёсткая предпосылка, а не опция. На них стоят шаги 2, 3, 7 и 9, проход review-specs и ревью дизайна (они завязаны на openspec/changes/<id>/specs/*/spec.md и на openspec validate --strict). Проект без OpenSpec этим пайплайном не ведётся — подключай OpenSpec, а не вырождай цикл: ветка деградации здесь не пишется, потому что непроверенная ветка деградации хуже честного отказа.
• Скиллы зовутся с пространством имён — av-dev-pipeline:review-pipeline, av-dev-pm:docs, av-dev-pm:tasks. Короткое имя может разрешиться в устаревшую проектную копию, и это произойдёт молча.
• Проектные копии этих скиллов и агентов удаляются при установке плагина (.claude/skills/ — и голые имена task-pipeline, review-pipeline, task-batch, и с префиксом проекта: <проект>-task-pipeline, <проект>-review-pipeline; .claude/agents/<проект>-review-*.md). Две копии одного скилла расходятся, и побеждает та, что короче названа.

Перед стартом прочитай CLAUDE.md проекта и то, на что он ссылается, если ещё не в контексте. Проектные факты, нужные ревью — инварианты, семантика гейта, объёмы, модель угроз, прецеденты, — живут в документах канона av-dev-pm; карта «что где» — references/project-facts.md конвейера ревью.

Документов канона нет — проект к нему не приведён. Скажи это строкой и предложи скилл av-dev-pm:canon: одна операция на проект против поразрядной деградации на каждой задаче. Работу при этом не останавливай.

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

• Беклогом, спринтом, целями и приоритетами. Задача приходит извне. Пайплайн её не выбирает, не приоритизирует, не заводит и не переоценивает; если в проекте есть свой процесс управления задачами — он и решает, что брать.
• Форматом задач. Пайплайн не правит индексы руками и не выдумывает путь к скрипту учёта: он зовёт Skill av-dev-pm:tasks, который этим владеет (шаг 12). Закрытие как таковое — его работа, и это осознанное решение с названной ценой: приёмщик и исполнитель совпали. Закрытие поэтому не окончательно — человек на сессии возвращает задачу reopen с причиной, а доклад по критериям приёмки становится единственным, по чему приёмка вообще возможна. Плагина av-dev-pm в проекте нет — вызов не разрешится, и тогда учёт остаётся владельцу, о чём говорится в докладе.
• Заведением задач из урожая ревью. Отложенные находки отдаются списком (см. шаг 8); превращать их в задачи — работа того, кто ведёт задачи проекта.
• Определением ценности. «Нужна ли эта функциональность» — не вопрос пайплайна ни на одном шаге.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаги

Двенадцать шагов с одной развилкой и одним досрочным исходом:

flowchart TD
    s1["1. Прочитать задачу<br/>критерии приёмки выписать сразу"]
    triv{"тривиальная?"}
    big["исход «оказалась крупнее задачи»<br/>объявляется ДО заведения change"]
    s2["2. opsx:explore — груминг идеи"]
    s3["3. opsx:propose — change, дельта-спеки, tasks.md"]
    s4["4. разметка задачи — review-scope:<br/>размер, сложность, метка, план тем"]
    s5["5. ревью дизайна, состав по метке"]
    s6["6. отработать замечания + validate --strict"]
    s7["7. opsx:apply — код, гейт, поведенческая верификация"]
    s8["8. ревью кода, состав по той же метки"]
    s9["9. opsx:archive"]
    s10["10. синк документации — av-dev-pm:docs"]
    s11["11. коммит работы — av-dev-git:commit"]
    s12["12. закрыть задачу — av-dev-pm:tasks,<br/>вторым коммитом учёта"]

    s1 --> triv
    s1 -.-> big
    triv -->|"нет: идея или мутная постановка"| s2
    s2 --> s3
    triv -->|"да: шаг 2 пропускается"| s3
    s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11 --> s12
    s4 -.->|"план задачи: та же метка"| s8

Разметка стоит одна и обслуживает обе стадии ревью — шаги 5 и 8. Это и есть пунктирное ребро на схеме: план, посчитанный на шаге 4, доезжает до ревью кода без пересчёта. Раньше разметка была первым проходом внутри шага ревью кода, а состав ревью дизайна называл сам пайплайн — то есть одна и та же величина считалась дважды, и один из двух раз тем, кто только что написал предложение.

Два чекпоинта ревью — шаги 5 и 8 — единственные места, где зовётся конвейер; порядок «сперва коммит работы, потом коммит учёта» на схеме тоже ребро, и оно обязательное (шаг 12).

Схема — сводка: содержание каждого шага в его разделе ниже, и при расхождении прав текст.

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

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

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

Оцени тривиальность — теперь она влияет ровно на один шаг, второй:

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

На состав ревью тривиальность больше не влияет — это работа шага 4. Раньше она решала и то, звать ли ревью предложения вовсе; теперь глубину обеих стадий называет метку, и тривиальная задача просто получает small. Разница существенная: «пропустить ревью дизайна» и «пройти его одним самым дешёвым проходом» — не одно и то же, а сверка дельта-спек стоит меньше, чем разбор того, что она поймала бы.

Здесь же — проверка на «крупнее задачи»: если видно, что одним заходом это не мерджится, объявляй исход до заведения 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. Разметка задачи — агент review-scope

Один запуск на всю задачу, и он обслуживает оба чекпоинта ревью. Запусти агента review-scope, дав ему корень проекта, идентификатор change, базу диффа и запись задачи. Кода на этот момент нет, и это условие его работы, а не помеха.

Он возвращает план задачи:

• размер (малое / среднее / крупное) и сложность (знакомое / незнакомое), каждое с обоснованием по факту;
• метка как максимум по двум осям: small, medium или large;
• состав ревью дизайна — что звать на шаге 5;
• таблицу тем «тема → дом → глубина → кто закрывает» — для шага 8;
• разнесение документов проекта по трём категориям и строку про директивы.

Метка выбираешь не ты. Раньше состав ревью дизайна называл этот пайплайн («крупное или незнакомое?»), то есть тот же оркестратор, который только что довёл предложение до propose. Разведённости с автором в этой точке не было вовсе; теперь есть.

План держи в контексте до конца задачи. На диск он не пишется: файл-план стал бы четвёртым артефактом рядом с proposal.md, tasks.md и design.md, пережил бы задачу и разошёлся бы с ней молча. Прервался пайплайн — повтори шаг 4, это самый дешёвый его проход.

Разметка повторяется ровно в одном случае — если на шаге 6 правки изменили сами дельта-спеки: план выведен из них, и план по отменённым требованиям назовёт не те темы. Во всех прочих случаях, включая переделку формы кода на шаге 8, метка остаётся прежней.

5. Ревью предложения — ДО кода, состав по метке

Первый чекпоинт. Вызови Skill av-dev-pipeline:review-pipeline, дав ссылку на change <id>, план разметки с шага 4 и указание, что это ревью дизайна.

Состав приходит планом, а не решается здесь:

Метка	Проходы на предложении
small	specs
medium	specs, rubric
large	specs, rubric, architecture + вопрос автору о трёх формах решения

review-specs в режиме «дизайн ДО кода» идёт на каждой задаче: это самый дешёвый чекпоинт конвейера, и он ловит то, что на готовом коде уже не чинят. Остальные включаются меткой, потому что чекпоинт стоит на каждой задаче и каждый лишний проход здесь умножается на число задач.

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

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

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

7. Написать код — opsx:apply

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

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

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

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

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

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

Метка ты не выбираешь, и это правило, а не упрощение. Её назвал review-scope ещё на шаге 4 — по размеру и сложности, с обоснованием по каждой оси. Причина в разведённости: ты только что написал этот код, и решать, насколько глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение известно заранее. Правило выбора живёт в скилле конвейера, проектные триггеры — в docs/review.*, подраздел «Триггеры метки».

Метка не пересматривается по факту диффа. Дифф может выйти крупнее, чем ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй запуск разметчика, ровно то, ради устранения чего он и переехал на шаг 4.

Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь. Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а не команда конвейеру. Место, где такое несогласие превращается в изменение правил, — журнал дефектов docs/review.md, и только постфактум.

Плана нет — ревью кода не запускается. Триаж требует план обязательным входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась сессия, ушёл контекст) — повтори шаг 4, а не гони прогон без него.

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

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

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

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

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

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

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

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

9. Архивировать — opsx:archive

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

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

Ревью выполненного — до этого шага. Затем вызови Skill av-dev-pm:docs: он владеет содержимым документов канона и ведёт чек-лист синка. Плагина нет — шаг всё равно делается, см. ниже.

Правило одно и оно жёсткое: принуждённое отрицание. Доклад обязан назвать каждый документ канона — либо чем он обновлён, либо «не требуется, потому что…». Нетронутые группируются одной строкой с общей причиной. Список триггеров прозой уже проверен на живом проекте и дал 6 записей ADR на 43 изменения; работает только обязательное отрицание.

Список документов и их триггеров здесь не дублируется — он в чек-листе скилла av-dev-pm:docs, и копия уже однажды разошлась с оригиналом, потеряв два триггера.

Плагина av-dev-pm в проекте нет — путь в его дерево не разрешится ниоткуда, поэтому за списком иди в свой reference: references/project-facts.md конвейера ревью перечисляет все документы канона с их предметом. Пройди по этому перечню — каждый документ получает строку, отрицание остаётся обязательным. Триггеры при этом ты знаешь хуже, и это называется в докладе строкой: «синк сделан по перечню документов, без списка триггеров — плагина av-dev-pm нет». Канона в проекте тоже нет — назови это исходом и предложи av-dev-pm:canon.

11. Коммит

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

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

12. Закрыть задачу — после коммита, не раньше

Вызови Skill av-dev-pm:tasks и попроси закрыть задачу как реализованную — он владеет форматом и двигает строку из набора спринта сам. Путь к его скрипту не выясняй и индексы руками не правь: мост между плагинами — вызов скилла, а не путь.

Порядок обязателен. Закрытие удаляет файл задачи; сделанное до коммита оно оставило бы задачу закрытой без единого следа работы, если шаг 11 упадёт.

Закрытие тоже коммитится — вторым коммитом, тут же. Удаление файла задачи и правка индексов (их имена знает av-dev-pm, не ты) — это правки в рабочем дереве, и оставить их незакоммиченными нельзя по трём причинам: task-batch следом делает rebase и worktree remove, а те откажут на грязном дереве; закрытие, не доехавшее до основной ветки, оставит задачу открытой молча; и опора «набор спринта под git показывает, что и когда закрыто» без коммита — пустые слова. Сообщение короткое, про учёт, а не про работу: закрыта задача <slug>. Это второй коммит осознанно: правило «одна задача — один осмысленный коммит» про работу, а учёт — не работа.

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

Приёмщик и исполнитель здесь совпадают, и закрытие не окончательно: человек на сессии может вернуть задачу (reopen с причиной). Поэтому доклад по критериям приёмки — не формальность, а единственное, по чему приёмка вообще возможна.

Готово — доложи кратко.

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

Тонкости

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