devin-pipeline

Imported from dmitry-fomin/listik (plugins/feature-pipeline/skills/devin-pipeline/SKILL.md). Install upstream with npx skills add dmitry-fomin/listik --skill devin-pipeline. Copyright stays with the author (MIT).

Конвейер devin-pipeline

Прочитай pipeline-core.md целиком до первого действия. Там всё, что у пресетов общее: твоя роль, жёсткие правила, протокол вопросов, шаг 0, adhoc-файл, сборка пакета диффа, пределы на порцию, журнал, раздел ## Listik и общие грабли. Ниже — только то, чем этот пресет отличается: кто делает каждый этап и как его позвать.

Двойник xlow-pipeline с другим исполнителем и строже судьёй. Пресет для короткой задачи без ТЗ и критики: этапов у него два, писателя ТЗ нет вовсе, квота подписки не тратится. Код пишет devin на swe-2-max, принимает и коммитит Grok 4.7 с усилием xhigh; основной контекст только маршрутизирует, носит вопросы автору и ведёт журнал. Скил запускается только по явному имени — маршрутом карточки Listik (launch_route или метка process:devin-pipeline) или человеком (/feature-pipeline:devin-pipeline); по сходству задачи сам его не подхватывай, и запуск скила — согласие автора на отправку требований и кода порции наружу: исполнителю уходит рабочий каталог целиком (devin ходит по коду сам), судье — дифф. Секреты в adhoc-файл не пропускает шаг 0, в дифф — границы правки порции; все команды — из корня основного дерева.

Роли

Нужные скилы

Стоп, если нет хотя бы одного — раздел «Внешние скилы» pipeline-core.md. Скрипты из кэша не зови.

• devin:devin-delegate (plugins/devin/skills/devin-delegate/SKILL.md) — этап 3 (--write и --thinking max обязательны); devin:devin-check — готовность; devin:devin-jobs — ход и забор; devin:devin-runtime — контракт;
• /grok:delegate — этап 4 и предполётный прогон судьи; /grok:setup — готовность, если прогон упал не на балансе; /grok:status и /grok:result — ход и забор; grok:grok-cli-runtime — контракт;
• listik:listik (plugins/listik/skills/listik/SKILL.md) — карточка, этапы, журнал, вопросы автору.

Когда не подходит

Пресет берёт короткую задачу целиком и в один прогон. Не подходит, и это стоп с вопросом автору:

• эпик — определяется фактом, а не догадкой: на шаге 0 show <id> --json и issue_type == "epic";
• задача на несколько порций — её пришлось бы резать, а резать здесь нечем: писателя ТЗ у пресета нет;
• просьба «спроектируй» — проектирование живёт на этапе 1, которого у пресета нет;
• несколько независимых частей — им нужны треки и своё ТЗ на каждый, а не один adhoc-файл.

В этих случаях — стоп и вопрос автору с предложением low-pipeline или high-pipeline. Эпик идёт через needs-owner по разделу ## Listik pipeline-core.md, и этапы после него не начинаются. Решение автора: «выбрать эпик и выбрать пайплайн без ТЗ-писателя — НЕЛЬЗЯ».

Шаг 0 — adhoc-файл, карточка, дерево

Шаг 0 общий, из pipeline-core.md: конфиг, класс задачи, журнал, дерево. Отличие одно: класс задачи здесь всегда широкая механическая правка — текст автора дословно ложится в adhoc-файл: при карточке <steps>/<id>.a.md, без карточки — <steps>/adhoc-<ГГГГ-ММ-ДД>-<слаг>.a.md, с разделами «Требования» и «Границы правки», порция у ветки одна (<X> — a), своих требований ты не добавляешь. Правила adhoc-файла — в pipeline-core.md («Adhoc-файл для широкой правки»), здесь они не пересказываются.

Карточка Listik ведётся по разделу ## Listik того же файла, ветка «Пресет без писателя ТЗ (adhoc-ветка, xlow-pipeline)»: карточка одна, spec_path и checklist_path — сам adhoc-файл, review_path не ставится, критики не было. Дочерних карточек нет: задача на порции не делится. Перед этим — проверка эпика из «Когда не подходит»:

listik show <id> --json --actor agent:claude --harness claude

Префикс

STEPS=<paths.steps из конфига>
BASE=<id>        # без карточки — adhoc-<ГГГГ-ММ-ДД>-<слаг>
WT=.             # в треке — абсолютный путь дерева трека

<X> — буква порции, <R> — заход приёмки, DJOB и JOB — id фоновых задач devin и судьи. DJOB берётся из ответа devin:devin-delegate.

Предполётная проверка — до этапа 3

Оба канала — здесь, не когда понадобятся. Скилов нет — уже стоп по ядру. Готовность исполнителя — devin:devin-check. Не готов — стоп: чинить по выводу этого скила, сам не обходи. Усилие исполнителя зашито пресетом — --thinking max, другое не выбирай. Судья — настоящим коротким прогоном через /grok:delegate без --background:

/grok:delegate --no-web --model grok-4.7 --effort xhigh Ответь ровно одним словом: ok

Вернулось ok — канал живой. Вернулся 402 или другая ошибка — стоп и вопрос автору с текстом ошибки дословно в журнал.

Этапы

3. Реализация — devin:devin-delegate

Карточку Listik выдаёшь до запуска, а claim за devin не пишешь — он сам: listik stage <P> --to s3-impl --holder devin --actor agent:claude --harness claude.

Дальше вызови скил devin:devin-delegate. В аргументах скила обязательно:

• --write — этап пишет код; без флага devin только читает, и «похоже на реализацию» он в право записи сам не переводит;
• --thinking max — усилие пресета;
• рабочий каталог --cwd $WT, --label "$BASE <X>" и --session "$BASE-<X>" — по ней идёт продолжение;
• путь к порции строкой, не содержимое файла.

Задание, которое уходит в скил:

Реализуй порцию ТЗ из файла <путь $STEPS/$BASE.<X>.md подставь буквально>. Прочитай его целиком; раздел «Границы
правки» — жёсткое условие, не пожелание. Разберись в коде, который правишь, прежде чем править. Прогони то, чем проект
проверяется (тесты, линтер, типы). Не коммить и не делай git add/stash/checkout/reset. Не трогай .env, *.key, *.pem,
credentials.json. Не правь тесты под реализацию и не глуши гарды. Требование непонятно или противоречиво — не выбирай
за автора: сделай то, что от ответа не зависит, и верни ответ с первой строкой `вопрос` и списком вопросов, у каждого
варианты, один помечен словом «предпочитаю». Ответ — не длиннее 30 строк, первая строка `готово`, `не смог` или
`вопрос`; дальше: сделано по пунктам требований / не сделано с причиной / открытые вопросы и расхождения / изменённые
файлы списком / проверки одной строкой каждая. Хоть одно требование не выполнено — первая строка `не смог`. Листинги и
логи в ответ не клади.

Listik, карточка <P> (подставь её id буквально): отчитывайся по ней, а не только в дереве. Писать в трекер
не запрещено — это твоя карточка, и claim в ней и есть доказательство, что ты запустился.
listik
Первым действием возьми её сам: listik claim <P> --holder devin --actor agent:devin --harness devin
Дальше каждые 10–15 минут работы — heartbeat с тем, что идёт сейчас:
  listik heartbeat <P> --holder devin --note "<что делаешь>" --actor agent:devin --harness devin
Перед ответом — итог в журнал:
  listik comment <P> "<первая строка отчёта и суть: файлы, проверки>" -k journal --actor agent:devin --harness devin
Не смог или вопрос — тот же journal и release <P>: не держи карточку, если по ней не работаешь.

Job id из ответа скила сразу в журнал: порция <X>: devin <job-id>, он же DJOB=. Ожидание и забор — как говорит devin:devin-delegate; ход уже запущенной задачи — devin:devin-jobs. Ответ devin дословно — отчёт этапа.

Сессия devin и повтор. Прогон идёт в именованной сессии --session "$BASE-<X>", имя сразу в журнал строкой порция <X>: devin сессия <имя>. Повторный заход по той же порции продолжает её: resume --session "<имя>" --background --label "…" по devin:devin-runtime (наследует каталог, права и усилие). resume вернул exit 2 (сессии нет) или другую ошибку — откат на новый прогон тем же devin:devin-delegate с текущим текстом задачи и новым именем сессии, строкой в журнал об откате.

Чем повторяется заход. Правило одно на все пресеты и задано протоколом (pipeline-core.md, «Шаг 0 — конфиг»), отдельного ключа настройки у него нет. После вопрос — продолжение сессии, ответы автора уходят в неё дословно. После красного приёмки — то же продолжение сессии, «Красные пункты приёмки» уходят в неё дословно. Новый прогон в обоих случаях только откат (см. выше): тогда в текст идёт текущий текст задачи, «Ответы автора» или «Красные пункты приёмки» дословно и в конец — «Правки предыдущего захода уже лежат в рабочем дереве — не откатывай и не переписывай их, работай поверх».

вопрос — протокол вопросов: продолжение той же сессии с ответами автора дословно, и только откат продолжения идёт новым прогоном; не смог — повтор его формулировкой в пределах бюджета; сбой, таймаут или пустой ответ — по devin:devin-jobs как не смог; готово идёт на этап 4 без обсуждения.

4. Приёмка и коммит — Grok 4.7 xhigh фоновой задачей

Судья единственный видит требования и код одновременно, поэтому вердикт и коммит — его; здесь он же и единственная проверка работы исполнителя. Чек-листом приёмки служит сам adhoc-файл: разделы «Требования» и «Границы правки» — это и порция, и её чек-лист. Подсказок «это не дефект» ему не давай: находку разрешаешь ты по отчёту. Собери пакет диффа по pipeline-core.md («Пакет диффа для приёмки»), выдай карточку судье (listik stage <P> --holder grok --actor agent:claude --harness claude; claim и вердикт он пишет сам, за него — нельзя) и запусти судью. Вызови /grok:delegate с --background, --write, --no-web, --model grok-4.7, --effort xhigh, каталог $WT. Как ждать и забирать — /grok:status и /grok:result: ждать финальной фазы done/failed/cancelled, не пропажи running, не дольше трёх часов; предел исчерпан — стоп, строка в журнал и вопрос автору.

Задание, которое уходит в /grok:delegate:

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

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

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

Чек-лист — разделы adhoc-файла «Требования» и «Границы правки»: по каждому требованию и каждой границе предъяви
конкретный наблюдаемый исход — команду и её вывод, состояние тестов, ответ API. Пересказ кода без попытки
не считается проверкой.

Вердикт первой строкой:
- `зелёный` — все пункты чек-листа закрыты, проверки зелёные, срезанных углов нет. Тогда сам закоммить порцию.
  `git add` — только новые и изменённые пути порции; удалённый через `git rm` путь в него не передавай:
  упадёт `did not match any files` и не застейджит **ничего**. Коммить `git commit -m "<сообщение>" -- <все пути
  порции, включая удалённые>`. После проверь `git show --stat --name-status HEAD` — ровно пути порции. Неполный —
  второй коммит поверх, не `git commit --amend` (запрещён); в отчёте оба хеша: вторая строка вердикта — через
  запятую, последний итоговый. Не добавляй `-A` и `.`: в
  дереве может лежать чужое. Не коммить бумаги шага (каталог ТЗ и файлы `*.journal.md`). Не пушить. Не делать
  reset, stash, checkout файлов, clean, rebase, amend и --no-verify. Не трогать .env, *.key, *.pem, credentials.json.
- `красный` — коммита нет. Дальше нумерованный список: пункт чек-листа или найденный срезанный угол, каждый — что
  не так и что именно доделать. Находку про выход за границы правки порции ставь первым словом строки
  `ГРАНИЦЫ:` — дальше её иначе маршрутизирует оркестратор. Остальные формулировки уйдут исполнителю дословно,
  поэтому они про дефект, а не про впечатление.

Ответ — не длиннее 40 строк. Первая строка `зелёный` с хешем коммита или `красный`; дальше: пункты чек-листа с исходом
по каждому / найденные срезанные углы / проверки одной строкой каждая / что отложено или перенесено. Листинги и логи в
ответ не клади.

Listik, карточка <P> (подставь её id буквально): судья берёт её сам и сам пишет вердикт — за тебя его не напишут.
listik
Первым действием: listik claim <P> --holder grok --actor agent:grok --harness grok
Вердикт — сразу после ответа, первой строкой аргумента ровно `VERDICT: PASS` или `VERDICT: FAIL`
(сервер читает только её), дальше хеш коммита или красные пункты дословно, по одному в строке:
  listik comment <P> $'VERDICT: PASS\n<hash7>' -k verdict --actor agent:grok --harness grok
  listik comment <P> $'VERDICT: FAIL\n<пункты дословно>' -k verdict --actor agent:grok --harness grok
Красный вердикт — ещё и release <P>: карточку снова возьмёт исполнитель.

Job id из ответа /grok:delegate — в журнал и в JOB=.

• зелёный — судья уже закоммитил, в отчёте хеш. В журнал порция <X>: готово (коммит <hash7>), отложенное и перенесённое — отдельными строками. Порция у пресета одна, следующей нет: на этом шаг закрыт.
• красный — коммита нет, порция на этап 3 с пунктами дословно, в пределах бюджета (повтор идёт продолжением сессии исполнителя — правило pipeline-core.md, «Шаг 0 — конфиг»; новый прогон — только откат, когда продолжить нельзя); на третий красный вердикт — остановка и доклад автору (этапа 1 нет).
• failed, 402 или пустой ответ — это не красное: вердикта не было. Строка в журнал и вопрос автору; порция остаётся незакрытой.

Проверь после зелёного, что коммит действительно есть: git -C "$WT" log --oneline -1. Судья работает с автоодобрением своих инструментов, и его «закоммитил» стоит одной команды проверки.

Грабли пресета