opencode-config/.opencode/skills/run-pipeline/SKILL.md

---
name: run-pipeline
description: Автономный исполнитель PR-пайплайна. Делегирует 7 фаз subagent'ам, не импровизирует порядок, не мержит при красном CI.
---

# Run Pipeline

Автономная процедура-loop для проведения PR через 7 фаз. Source of truth для
порядка и действий — `pipeline_status` tool. NEXT action из tool явно
указывает `subagent_type` + `template` (кроме MERGE — `merge_pr` tool).

## ПРОТОКОЛ (ЖЁСТКО)

Каждая итерация (БЕЗ ИСКЛЮЧЕНИЙ):

1. Вызови tool `pipeline_status({pr_number: M})` — вернёт статус всех фаз + строку `NEXT: <action>`.
2. Если вывод содержит `Status: COMPLETE` → финальный репорт пользователю, exit.
3. Если вывод содержит `AMBIGUOUS` → репорт пользователю с причиной, STOP.
4. Иначе — исполни action из строки `NEXT:` (используй prompt templates A-E ниже).
5. 1 строка прогресса пользователю (формат: `✅ <phase> — <action executed>`).
6. Re-loop (шаг 1).

### ЗАПРЕЩЕНО

- ЛЮБОЙ action БЕЗ предшествующего вызова `pipeline_status` = protocol violation.
- Импровизировать порядок. Решать сам какой subagent запускать — читай `NEXT:`.
- Пропускать вызов `pipeline_status`, даже если «кажется, что фаза уже ✅» — скрипт решает.
- Делать bash `sleep` для ожидания CI — `pipeline_status` сам блокирует до 5 мин (polling Actions API внутри `check_ci`). Один вызов → финальный статус.
- Merge при CI ❌ (transitive guard в скрипте).
- Передавать `--admin` flag в `merge_pr` (или raw `gh pr merge`) — никогда.
- Параллелить subagents (последовательно: action → `pipeline_status` → next action).

### Остановы

- Subagent error → 1 retry, потом STOP + report пользователю.
- `AMBIGUOUS` в выводе `pipeline_status` → STOP + report.
- 5 итераций подряд без прогресса (та же фаза ❌) → STOP + report.

## Prompt templates

### Template A (implement_issue)

```
Реализуй issue #N в текущем репо (working directory = корень репо).
1. Checkout new branch `type/scope/kebab-description` от master.
2. Реализуй по спеке issue (точно, без отклонений). Если спека содержит ошибки,
   зафикь и продолжай — не додумывай.
3. Создай handoff + ADR: `bash .opencode/scripts/scaffold-handoff.sh M <slug>`
   (M — будет PR номер, используй placeholder `<PR-NUMBER>` в handoff
   frontmatter, потом исправишь после create_pr).
4. Коммиты через `commit({ message: "type(scope): description" })` tool (НЕ
   raw `git commit` — заблокирован deny). Формат: ≤72 chars, English, no
   period, no body unless necessary. Минимум 3-4 логических коммита.
5. Push ветку (`git push -u origin HEAD`), затем создай PR через tool:
   `create_pr({ title: "type(scope): description", body: "## Что сделано\n...\n\n## Почему\n...\n\nCloses #N", issue_number: N })`.
6. После получения PR номера — исправь placeholder `<PR-NUMBER>` в handoff
   frontmatter, отдельный коммит `docs(handoff): set PR number` через
   `commit` tool, push.
7. Верни PR номер M.
```

### Template B (docs-review)

```
Review PR#M в текущем репо (pre-merge, режим docs).
1. `gh pr checkout M`.
2. Анализируй структурные изменения: `git diff origin/master...HEAD --stat`.
3. Сравни с `docs/project-map/` — обнови если structural changes.
4. Валидируй handoff `docs/handoff/pr-M-*.md`: 4 секции (Что сделано, Почему,
   Pending, Watch out) заполнены осмысленно (не пустые плейсхолдеры).
5. Валидируй ADR `docs/decisions/*-pr-M-*.md`: 4 секции (Статус, Контекст,
   Решение, Альтернативы).
6. Если криво — почини (edit: allow).
7. `git add docs/project-map/ docs/handoff/ docs/decisions/` (add — НЕ
   заблокирован), затем `commit({ message: "docs: update project map + handoff + ADR" })`
   tool, и `git push`.
8. **ВСЕГДА** оставь PR comment (даже если structural changes нет) — это
   детерминированный marker для `check_docs` в pipeline-status.py. Без comment
   pipeline блокируется на DOCS phase. Используй tool `post_docs_review` (НЕ
   raw bash-вызов `gh`) — tool гарантирует heading `## Docs Review Summary` и
   verdict-enum (zod), формат который парсит `check_docs`.
   `post_docs_review({ pr_number: M, verdict: "APPROVE|FIXED|NO_CHANGES", body: "- Project map: ...\n- Handoff: ...\n- ADR: ..." })`.
   Heading `## Docs Review Summary` — обязательно (regex `Docs Review`),
   tool добавляет его автоматически — НЕ форматируй heading/verdict вручную.
   Если tool вернул строку начинающуюся с `⚠️ ...failed` — СООБЩИ оркестратору
   о сбое и STOP (не fallback на raw bash).
```

### Template C (code_review)

```
Review PR#M в текущем репо.
1. `gh pr view M --json headRefName,body,title`.
2. `git diff origin/master...HEAD`.
3. Load project skills: `find .opencode/skills/ -name "SKILL.md"`, грузи каждый
   через `skill("<name>")`.
4. Проверь: code quality, architecture, error handling, security, testing,
   duplication, project-specific rules, PR hygiene, handoff/ADR (quick check).
5. Оставь review через tool `post_review` (НЕ `gh pr review --approve` —
   GitHub блокирует self-approve; НЕ raw bash-вызов `gh`) — tool гарантирует
   heading `## Code Review Summary` + verdict-enum которые парсит
   `pipeline-status.py`:
   `post_review({ pr_number: M, verdict: "APPROVE|REQUEST_CHANGES|NEEDS_DISCUSSION", body: "..." })`.
   Tool добавляет heading + verdict line автоматически — НЕ форматируй их
   вручную. Если tool вернул строку начинающуюся с `⚠️ ...failed` — СООБЩИ
   оркестратору о сбое и STOP (не fallback на raw bash).
   6. НЕ МЕРДЖИТЬ — merge делает основной агент через run-pipeline.
```

### Template D (fix_ci)

```
CI упал на PR#M. Чтобы получить <run-id>: `gh run list --branch <headRefName> --limit 1 --json databaseId,conclusion`.
Log: `gh run view <run-id> --log-failed` output:
<log>
1. `gh pr checkout M`.
2. Проанализируй log, найди причину.
3. Исправь (минимальные изменения, whitespace/formatting/logic fix).
4. Коммит через `commit({ message: "fix(ci): <description>" })` tool (НЕ raw
   `git commit`), push.
5. Не трогай логику unrelated файлов.
```

### Template E (memory_sync)

```
Дистиллируй PR#M в memory file
`app_data/opencode-memory/repos/{host}/{org}/{repo}.md`
(путь относительно корня репо; `{host}/{org}/{repo}` вычисли через
`git remote get-url origin` — см. `memory-syncer.md:38`).
1. Прочитай `docs/handoff/pr-M-*.md` и `docs/decisions/*-pr-M-*.md` с master
   (`git checkout master && git pull`).
2. Найди durable gotchas (не статусы, не "сейчас делаем"). Паттерны, указатели,
   non-obvious API quirks.
3. Добавь записи формата `- [YYYY-MM-DD, PR#M] <summary>` в конец файла
   (секция "Handoff digest").
4. Квитанция ВСЕГДА (даже если durable нет): `- [date, PR#M] — (нет durable-записей)`.
5. `memory_save` для commit + reindex + push.
6. Проверь `git status` основного репо — если staged что-то в `app_data/`,
   репорт пользователю (guard от случайного коммита в master).
```

### Template F (merge)

MERGE phase — main agent вызывает tool напрямую (НЕ subagent, НЕ raw bash).
`pipeline_status` сам решает, можно ли мержить (CI gate внутри скрипта —
transitive guard). После `NEXT: ...merge_pr...` → один вызов:

```
merge_pr({ pr_number: M })
```

Если вернулась `⚠️ merge_pr failed ...` → репорт пользователю, STOP (НЕ retry
через raw bash — это нарушит orchestrator-контракт). Если `PR #M merged
successfully ...` → 1 строка прогресса и re-loop (`pipeline_status` покажет
`Status: COMPLETE` или перейдёт на MEMORY phase).

## API Restrictions

Использовать только Actions API (`pipeline_status`, `gh run list`, `gh run view`, `gh api repos/.../actions/runs`). **Запрещено** `gh pr checks` и `gh pr view --json statusCheckRollup` — 403 на fine-grained PAT (scope `Checks: read` не существует).

## Rules

- `pipeline_status` — единственный source of truth для порядка шагов и действий.
- Скрипт read-only (только `gh api`/`gh pr view`, без мутаций).
- После каждой фазы → 1 строка прогресса юзеру.
- Если subagent error → 1 retry, потом STOP + report пользователю.
- `merge_pr({ pr_number: M })` tool — единственный способ мержить PR (без
  `--admin`, без raw bash). См. Template F.
- Если reviewer вердикт `REQUEST_CHANGES` → dispatch subagent (general) с prompt "fix reviewer comments: <list>", commit, push → re-loop (`pipeline_status` проверит CI автоматически).