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

name	description
run-pipeline	Autonomous PR pipeline executor. Delegates 6 phases to subagents, does not improvise order, does not merge on red CI. Also when user says "запусти пайплайн", "pipeline", "run pipeline".

Run Pipeline

Автономная процедура-loop для проведения PR через 6 фаз. 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, C, D, E, F ниже).
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. Коммиты через `commit({ message: "type(scope): description" })` tool (НЕ
   raw `git commit` — заблокирован deny). Формат: ≤72 chars, English, no
   period, no body unless necessary. Минимум 3-4 логических коммита.
   Перед КАЖДЫМ `commit` — `git status` для проверки staged set. `commit`
   tool НЕ делает `git add` — коммитит только уже staged файлы. Используй
   `git add <конкретные-пути>`, НЕ `git add -A` (иначе лишние файлы уйдут в
   коммит). Если в индексе лишнее (например `memory-save` stage'нул всё
   через `git add -A`) — не коммить: сначала `git restore --staged <file>`.
4. Push ветку (`git push -u origin HEAD`), затем создай PR через tool:
   `create-pr({ title: "type(scope): description", body: "## Что сделано\n...\n\n## Почему\n...\n\n## Watch out\n...\n\n## Pending\n...\n\nCloses #N", issue_number: N })`.
   PR body ОБЯЗАТЕЛЬНО содержит 4 heading'а: `## Что сделано`, `## Почему`,
   `## Watch out`, `## Pending`. Заполни осмысленно (для Watch out/Pending
   можно `—` если реально нет контента).
5. Верни PR номер M.
Если найдёшь баг вне scope текущей задачи — загрузи skill `bug-discovery` через `skill("bug-discovery")` и следуй протоколу. НЕ чини баг сам. Сообщи оркестратору: "Created issue #N: ...".

Template C (code_review)

Review PR#M в текущем репо.
1. `gh pr view M --json headRefName,body,title`.
2. `git diff origin/HEAD...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.
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.
Если найдёшь баг вне scope текущей задачи — загрузи skill `bug-discovery` через `skill("bug-discovery")` и следуй протоколу. НЕ чини баг сам. Сообщи оркестратору: "Created issue #N: ...".

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. Перед коммитом — `git status` для проверки staged set (`commit` tool НЕ
   делает `git add` — коммитит только staged; используй
   `git add <конкретные-пути>`, НЕ `git add -A`). Коммит через
   `commit({ message: "fix(ci): <description>" })` tool (НЕ raw
   `git commit`), push.
5. Не трогай логику unrelated файлов.
Если найдёшь баг вне scope текущей задачи — загрузи skill `bug-discovery` через `skill("bug-discovery")` и следуй протоколу. НЕ чини баг сам. Сообщи оркестратору: "Created issue #N: ...".

Template E (memory_sync)

Дистиллируй PR#M в memory file
`<memory_dir>/repos/{host}/{org}/{repo}.md`
(default `~/.local/share/opencode/opencode-memory`, override через `OPENCODE_MEMORY_DIR`;
`{host}/{org}/{repo}` вычисли через
`git remote get-url origin` — см. `memory-syncer.md:38`).
1. Прочитай PR body через `gh pr view M --json body,title` (+ `gh issue view`
   для контекста issue, если PR ссылается на issue). Текущее состояние — уже
   смерженный default branch (checkout/pull НЕ нужны, запрещены permission
   set'ом memory-syncer'а).
2. Найди durable gotchas (не статусы, не "сейчас делаем"). Паттерны, указатели,
   non-obvious API quirks. Источник: PR body `## Watch out` (gotchas) +
   `## Pending` (follow-ups) + diff (`git diff` текущего state vs parent).
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 что-то в memory dir,
    репорт пользователю (guard от случайного коммита в master).
Если найдёшь баг вне scope текущей задачи — загрузи skill `bug-discovery` через `skill("bug-discovery")` и следуй протоколу. НЕ чини баг сам. Сообщи оркестратору: "Created issue #N: ...".

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 — 6-я фаза).

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: ", commit, push → re-loop (pipeline-status проверит CI автоматически).