Cross Pipeline

---
name: cross-pipeline
description: "Конвейер реализации на пресете cross-pipeline — ТЗ пишет Devin на SWE-2 с усилием max, ТЗ критикуют сразу DeepSeek V4.1 Flash в pi и Sonnet 5.5 high, код пишет GLM 5.3 Flash в pi, принимает и коммитит Grok 4.7 на xhigh; основной контекст только маршрутизирует, носит вопросы автору и ведёт журнал. Вызывай, когда шаг спеки или фичу надо провести через ТЗ, критику, реализацию и независимую приёмку, а автор ТЗ и исполнитель должны быть на разных вендорах: ТЗ пишет Devin, код — GLM, принимает Grok. Состав ролей зашит в текст этого скила и не читается из ячеек `roles` маршрута. Запускай только по явному имени: маршрутом карточки Listik (launch_route или метка process:<ключ>) или когда человек назвал пресет; по сходству задачи сам не подхватывай."
argument-hint: "[путь к <id>.<X>.md или описание задачи]"
license: MIT
---

# Конвейер cross-pipeline

Четыре этапа, и автор ТЗ, исполнитель и судья — три разных вендора: ТЗ пишет Devin, ТЗ критикуют сразу
DeepSeek V4.1 Flash в pi и Sonnet 5.5 high, код пишет GLM 5.3 Flash в pi, принимает и коммитит Grok. Основной контекст (Claude) — только оркестратор:
маршрутизирует этапы, носит вопросы автору и ведёт журнал; сам код не пишет и порцию не коммитит.
Состав ролей зашит в текст этого скила, а не читается из ячеек `roles` маршрута.

**Прочитай [pipeline-core.md](../../references/pipeline-core.md) целиком до первого действия.** Там всё, что у
пресетов общее: твоя роль, жёсткие правила, протокол вопросов, шаг 0, треки, сборка пакета диффа, пределы на
порцию, журнал и общие грабли. Ниже — только то, чем cross-pipeline отличается: кто делает каждый этап и как
его позвать.

Скил запускается только по явному имени — маршрутом карточки Listik (`launch_route` или метка
`process:cross-pipeline`) или человеком (`/feature-pipeline:cross-pipeline`); по сходству задачи сам его не
подхватывай. Запуск скила — согласие автора на отправку **ТЗ, чек-листа, кода и диффа порции** наружу:
критикам — шаг, ТЗ порции и чек-лист, код на чтение, исполнителю в pi — рабочее дерево целиком, судье — дифф. Секреты
в ТЗ не пропускает этап 1, в дифф — границы правки порции. Все команды — из корня основного дерева.

## Роли

| Этап | Чем зовётся | Параметры | Что возвращает |
| --- | --- | --- | --- |
| 1. ТЗ и чек-листы | скил `devin:devin-delegate` | `--thinking max`, `--write`; пишет `<id>.md`, `<id>.<X>.md`, `<id>.check-<X>.md` в каталог шагов | `готово`, `не смог` или `вопрос` |
| 2. Критика ТЗ | два критика одним сообщением: `deepseek` — скил `pi:pi-delegate`, фоновой задачей; `sonnet` — `Agent` `feature-pipeline:pipeline-critic`, **`model: sonnet` в вызове**, фоном | канал `deepseek` (DeepSeek V4.1 Flash), `--permission read`; Sonnet 5.5 high; кворум — оба | по файлу на критика, потом твоя сводка `review-<X>.md` с разделами «Блокирующие» и «Существенные» |
| 3. Реализация | скил `pi:pi-delegate` | `--channel glm`, `--permission write` (`--write`), рабочий каталог — дерево карточки | `готово`, `не смог` или `вопрос` |
| 4. Приёмка и коммит | `/grok:delegate` | `--background --write --no-web --model grok-4.7 --effort xhigh` | `зелёный` с хешем или `красный` |

## Нужные скилы

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

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

## Префикс

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

`<X>` — буква порции, `<R>` — номер захода приёмки, `DJOB` и `PJOB` — id фоновых задач devin и pi,
`JOB` — id фоновой задачи судьи.

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

**Стоп-фактор.** Любая роль недоступна (предполётная проверка не прошла, харнесс не установлен или не залогинен, запуск упал, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `listik needs-owner <id> "<вопрос>"` и тот же вопрос в чат, и больше ничего. Запасного исполнителя нет: роль не подменяется ни другим харнессом, ни другой моделью, ни локальным субагентом, в headless тоже (`pipeline-core.md`, «Стоп-фактор»). Повтор того же харнесса и той же модели в той же роли — не подмена. Исключение — критики этапа 2: они идут по кворуму, и выбывший критик не стоп, пока кворум пресета набран (`pipeline-core.md`, «Критика ТЗ»).

Все четыре канала — здесь, не когда понадобятся. Скилов нет — уже стоп по ядру. Готовность автора ТЗ —
`devin:devin-check`, исполнителя и критика `deepseek` — `pi:pi-check` полной пробой: отвечают оба канала, `glm` (этап 3) и `deepseek`
(критик); у Sonnet предполёта нет, выбывание критика на предполёте — по ядру (`pipeline-core.md`, «Критика ТЗ»); автор ТЗ или исполнитель не готов — **стоп**, чинить по выводу этих скилов, сам не обходи. Судья —
**настоящим коротким прогоном**, как в `xlow-pipeline`:

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

Вернулось `ok` — канал живой. Вернулся 402 или другая ошибка — **стоп и вопрос автору** с текстом ошибки
дословно: без судьи порция застрянет в рабочем дереве без коммита. Сам канал не подменяешь.

## Этапы

### 1. ТЗ и чек-листы — `devin:devin-delegate`, один раз на шаг

**Стоп-фактор.** Харнесс этапа недоступен (запуск упал, не залогинен, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `needs-owner` и тот же вопрос в чат; подмены другим харнессом, моделью или локальным субагентом нет (`pipeline-core.md`, «Стоп-фактор»).

Карточку Listik на этом этапе держит сессия: этапы 1–2 ведёт сам оркестратор. Дальше **вызови скил
`devin:devin-delegate`**. В аргументах обязательно: `--thinking max` (усилие пресета), `--write` (иначе devin
не запишет бумаги), рабочий каталог `--cwd $WT`, `--label "$BASE spec"`, `--session "$BASE-spec"` — по ней
идёт продолжение. Задание:

```
Напиши ТЗ шага и чек-листы его порций. Прочитай исходную спеку или текст автора (путь подставь буквально)
и разложи работу на порции. Имя бумаг: <id>.md — шаг с таблицей порций, <id>.<X>.md — ТЗ порции, где <X>
буква порции, <id>.check-<X>.md — чек-лист её приёмки; каталог — STEPS=docs/specs/steps. Рабочее
дерево — WT=<абсолютный путь дерева карточки>. Код не трогай и не правь: твои правки — только бумаги в
каталоге шагов. Не коммить и не делай git add/stash/checkout/reset. Не трогай .env, *.key, *.pem,
credentials.json. Порция добавляет или чинит проверку (барьер, claim, шлюз, гард, валидацию, отказ API) —
в её чек-листе негативный контроль: сценарий, на котором проверка обязана отказать, и наблюдаемый отказ
(тест, падающий на коде до правки, или команда с ошибкой и её текстом/кодом). Неясное — не додумывай: верни ответ с первой строкой `вопрос` и списком вопросов, у
каждого варианты, один помечен словом «предпочитаю». Ответ — не длиннее 30 строк, первая строка `готово`,
`не смог` или `вопрос`; дальше: сделано по пунктам требований / не сделано с причиной / открытые вопросы и
расхождения / изменённые файлы списком / проверки одной строкой каждая. Листинги и логи в ответ не клади.
```

`вопрос` — протокол вопросов. `готово` — в журнал `шаг <id>: старт, пресет cross-pipeline, порций <K>`;
названные агентом допущения покажи автору одной репликой: молчание — согласие. Job id и имя сессии devin —
в журнал строками `порция <X>: devin <job-id>` и `порция <X>: devin сессия <имя>`.

### 2. Критика ТЗ — DeepSeek + Sonnet

**Стоп-фактор.** Критики этапа идут по кворуму, а не по правилу недоступной роли: выбывший критик (запуск упал, не залогинен, ответила не та модель, ответ негоден или не пришёл за окно) — не стоп, пока кворум пресета набран. Не набран — стоп по ядру: журнал `стоп: критика — кворум не набран: <кто не дал годного ответа и почему>`, `needs-owner` и тот же вопрос в чат (`pipeline-core.md`, «Критика ТЗ»).

Состав — два критика: `deepseek` — `pi:pi-delegate`, канал `deepseek` (DeepSeek V4.1 Flash), `--permission read`, фоновой задачей, ответ — `result` через `pi:pi-jobs`; `sonnet` — `Agent` `feature-pipeline:pipeline-critic` с **`model: sonnet` в вызове** (Sonnet 5.5 high), фоном. Кворум — годные ответы обоих. Оба запускаются одним сообщением, с одним заданием.
Проверка на секреты, старые ответы, запуск, задание, окно 15 минут, забор, годность, повтор, журнал выбывших и правила сведения в `$STEPS/$BASE.review-<X>.md` — `pipeline-core.md`, «Критика ТЗ».

Решение по сводке — твоё, по ядру (`pipeline-core.md`, «Решение по сводке»): каждому пункту
`принять`, `отклонить` или `автору` в `$STEPS/$BASE.decisions-<X>.md`, автору — только пункты `автору`, строка в журнал.
Есть `принять` или `автору` — **автору ТЗ**: возобнови `devin:devin-delegate` продолжением сессии `$BASE-spec`
с путями к `$STEPS/$BASE.decisions-<X>.md` и `$STEPS/$BASE.review-<X>.md`. Одна критика на порцию, поправленное ТЗ не критикуется.

### 3. Реализация — `pi:pi-delegate`

**Стоп-фактор.** Харнесс этапа недоступен (запуск упал, не залогинен, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `needs-owner` и тот же вопрос в чат; подмены другим харнессом, моделью или локальным субагентом нет (`pipeline-core.md`, «Стоп-фактор»).

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

Дальше **вызови скил `pi:pi-delegate`**. В аргументах обязательно: `--channel glm` (GLM 5.3 Flash),
`--permission write` (`--write`), рабочий каталог `--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 pi --actor agent:pi --harness pi
Дальше каждые 10–15 минут работы — heartbeat с тем, что идёт сейчас:
  listik heartbeat <P> --holder pi --note "<что делаешь>" --actor agent:pi --harness pi
Перед ответом — итог в журнал:
  listik comment <P> "<первая строка отчёта и суть: файлы, проверки>" -k journal --actor agent:pi --harness pi
Не смог или вопрос — тот же journal и release <P>: не держи карточку, если по ней не работаешь.
```

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

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

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

**Стоп-фактор.** Харнесс этапа недоступен (запуск упал, не залогинен, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `needs-owner` и тот же вопрос в чат; подмены другим харнессом, моделью или локальным субагентом нет (`pipeline-core.md`, «Стоп-фактор»).

Судья единственный видит требования, чек-лист и код одновременно, поэтому вердикт и коммит — его. Подсказок
«это не дефект» ему не давай: находку разрешаешь ты по отчёту. Собери пакет диффа по `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`:

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

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

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

Чек-лист содержит негативный контроль — прогони его и покажи отказ выводом команды; отказа нет — красный
пункт. Порция добавляет или чинит проверку (барьер, `claim`, шлюз, гард, валидацию, отказ API), а негативного
контроля в чек-листе нет — построй сценарий отказа сам и прогони его.

Каждое число, SHA и цитата в вердикте и отчёте — копией из вывода команды этого захода: хеш — из
`git rev-parse --short HEAD` после коммита, счётчики — из вывода раннера тестов, место в файле — `path:line`;
числа не из вывода в вердикт не идут. Утверждение исполнителя с числом или хешем сверяй с выводом своей
команды, а не принимай на веру.

Вердикт первой строкой:
- `зелёный` — все пункты чек-листа закрыты, проверки зелёные, срезанных углов нет. Тогда сам закоммить
  порцию. `git add` — только новые и изменённые пути порции; удалённый через `git rm` путь в него не
  передавай: упадёт `did not match any files` и не застейджит **ничего**. Коммить `git commit -m "<сообщение>"
  -- <все пути порции, включая удалённые>`. После проверь `git show --stat --name-status HEAD` — ровно пути
  порции. Неполный — второй коммит поверх; `--amend`, `rebase` и `--no-verify` запрещены. Не добавляй `-A` и
  `.`: в дереве может лежать чужое. Не коммить бумаги шага (каталог ТЗ и файлы `*.journal.md`). Не пушить. Не
  трогать .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`), иначе с этапа 2.
- **красный** — коммита нет, порция на этап 3 с пунктами дословно, в пределах бюджета; повтор идёт
  продолжением сессии исполнителя (правило `pipeline-core.md`, «Шаг 0 — конфиг»), а новый прогон — только
  откат, когда продолжить нельзя.
- **`failed`, `402` или пустой ответ** — это не красное: вердикта не было. Строка в журнал и вопрос автору;
  порция остаётся незакрытой, следующую не начинаешь.

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

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

| Симптом | Причина | Что делать |
| --- | --- | --- |
| Бумаги ТЗ не записались | у `devin:devin-delegate` забыт `--write` | перезапуск скила с `--write`; ответ без бумаг отчётом этапа не считается |
| Код написан не GLM | у `pi:pi-delegate` забыт `--channel glm` | канал обязателен в каждом запуске этапа 3 |
| pi вернул разбор вместо правки | в `pi:pi-delegate` забыт `--permission write` | перезапуск скила с `--permission write` |
| Исполнителю ушло содержимое ТЗ | в скил попал текст файла, а не путь | в задание идёт путь к порции |
| Порция закоммичена недоделанной | `готово` от pi принято на веру без судьи | судья не опционален: «готово» проверяет только приёмка |
| Судья упал с 402, порция повисла | баланс Grok Build исчерпан | предполётный прогон судьи до этапа 1; 402 по ходу — вопрос автору |
| Судья сказал «зелёный», коммита нет | прогон оборвался после вердикта | `git log --oneline -1` после каждого зелёного; нет коммита — вопрос автору |
| Повтор после `вопрос` или красного начал сессию с нуля | имя сессии не попало в журнал или `resume` вернул exit 2 | это откат, а не сбой: новый прогон с текущим текстом задачи, строка в журнал |