refactor(pipeline): update templates and agent prompts for 6-phase (#209)

* refactor(run-pipeline): drop Template B and handoff refs for 6-phase

* refactor(agents): switch reviewer and memory-syncer to PR body

* refactor(docs): update pipeline to 6 phases and drop DOCS refs

* fix(docs): update RU pipeline row and memory-syncer description

---------

Co-authored-by: opencode-agent <agent@opencode.local>
This commit is contained in:
Sergey 2026-08-01 04:02:03 +03:00 committed by GitHub
parent 9dd462b764
commit 1d35c5ed1c
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
7 changed files with 41 additions and 86 deletions

View file

@ -1,5 +1,5 @@
---
description: Distills durable knowledge from merged PR handoffs into global memory. Read-only on repo, write-only on memory.
description: Distills durable knowledge from merged PRs into global memory. Read-only on repo, write-only on memory.
mode: subagent
temperature: 0.1
steps: 150
@ -41,7 +41,7 @@ You are **read-only on the repository** and **write-only on memory**. You CANNOT
1. Load the memory skill via `skill("memory")` to get distillation rules and format conventions.
2. Get the PR number from the invocation prompt.
3. Find the merged handoff file: `ls docs/handoff/pr-<N>-*` to discover the slug, then `cat docs/handoff/pr-<N>-<slug>.md` to read it (read-only — agent does not check out branches).
3. Прочитай PR body через `gh pr view <N> --json body,title` (PR body содержит 4 секции: Что сделано, Почему, Watch out, Pending). При необходимости — `gh issue view <issue-N>` для контекста.
4. Determine the repo: `git remote get-url origin` → parse `{host}/{org}/{repo}` (e.g. `github.com/slaid098/opencode-config`).
5. Resolve memory path: read `OPENCODE_MEMORY_DIR` env var (set globally via docker-compose; fallback `~/.local/share/opencode/opencode-memory/`) → `<memory_dir>/repos/{host}/{org}/{repo}.md`. Use `printenv OPENCODE_MEMORY_DIR` to inspect it.
6. Open the memory file (create if missing) via the `edit`/`write` tool — `edit: allow` permits this. The memory dir is an isolated git repo (post-commit hook auto-pushes), separate from the main repo.
@ -55,7 +55,7 @@ Durable (записывай):
- patterns, repository conventions
- pointers: «for X use Y, careful with Z»
- root causes of bugs
- ADR pointers: `- [date, PR#N] ADR-NN: <суть> → docs/decisions/NN-title.md` (do NOT copy ADR content — only the pointer)
- ADR pointers (исторические, для новых PR): `[date, PR#N] <architectural decision summary>` (без ADR-NN — старые ADR-NNN references в памяти остаются как исторические)
НЕ durable (НЕ записывай):
- статусы, «сейчас работаем над», текущие таски, ephemeral контекст
@ -109,7 +109,7 @@ This confirms the memory-sync phase was executed (audit trail).
1. NEVER call `git push`, `git commit`, `git add` — they are not in the allow-list and will be denied by the catch-all rule.
2. NEVER checkout branches or pull — you operate on the current state of the default branch (already merged).
3. ONLY edit files under `<memory_dir>/repos/{host}/{org}/{repo}.md`.
4. ONLY read files under `docs/handoff/` and `docs/decisions/`.
4. Read PR body via `gh pr view <N> --json body,title`. Optionally read `docs/decisions/*-pr-<N>-*.md` if exists (historical ADR). Do NOT read docs/handoff/ — handoff files are deprecated.
5. Receipt is mandatory even if no durable records found.
6. If memory file doesn't exist — create it with proper frontmatter (title, tags, summary, created, updated, importance).
7. Для debug-вывода используй `pwd`/`ls`/`cat`/`printenv`/`echo` (все в allow-list).

View file

@ -203,22 +203,11 @@ Examples of project-specific rules:
- No `.env` or secret files in the diff.
- Branch name is descriptive.
### 9. Documentation (if docs/project-map/ exists)
### 9. PR body quality
- Project map files accurately reflect current project structure
- New modules have corresponding map files in `docs/project-map/`
- Deleted/renamed modules have updated or removed map files
- No stale references to files or directories that no longer exist
- Map files follow the template (frontmatter + structure + purpose)
### 10. Handoff & ADR (quick check)
- `docs/handoff/pr-<N>-<slug>.md` exists in the diff (N = PR number)
- Handoff has all sections: Что сделано, Почему, Pending, Watch out
- Handoff content is meaningful — not empty placeholders
- If PR introduces architectural changes → `docs/decisions/<NN>-<title>.md` exists
- ADR has: Статус, Контекст, Решение, Альтернативы
- If handoff/ADR missing or empty → REQUEST_CHANGES
- PR body содержит `## Что сделано`, `## Почему`, `## Watch out` заполнены
осмысленно (не пустые плейсхолдеры, `—` допустим для Watch out/Pending если
нет контента). Если PR body неполный → REQUEST_CHANGES.
## Output Format

View file

@ -1,5 +1,5 @@
---
description: Run pipeline — autonomous 7-phase PR pipeline
description: Run pipeline — autonomous 6-phase PR pipeline
agent: build
---
Load the `run-pipeline` skill via `skill({name: "run-pipeline"})` and follow its ПРОТОКОЛ strictly. Each iteration: call `pipeline-status` tool, execute the `NEXT:` action it returns, repeat until COMPLETE or STOP. Полностью автономно — 1 строка прогресса после каждой фазы, STOP на AMBIGUOUS/error.

View file

@ -157,11 +157,10 @@ Label выбирай по типу задачи (совпадает с commit `t
После создания issue, цикл продолжается (см. `run-pipeline` skill для деталей PR процесса):
1. **Subagent**`task(general)` читает issue, реализует, коммитит, push, создаёт PR. Оркестрация — через `run-pipeline` skill.
2. **Docs review**`@docs-reviewer` subagent валидирует handoff + ADR, обновляет project map (pre-merge).
3. **Code review**`@reviewer` subagent ревьюит PR (diff, skills, standards), постит `## Code Review Summary` комментарий.
4. **Merge or Repeat** — APPROVE → `merge-pr({ pr_number: N })` tool (squash +
2. **Code review**`@reviewer` subagent ревьюит PR (diff, skills, standards), постит `## Code Review Summary` комментарий.
3. **Merge or Repeat** — APPROVE → `merge-pr({ pr_number: N })` tool (squash +
delete branch, без `--admin`; НЕ raw `gh pr merge` — заблокирован deny),
после CI ✅; замечания → fix subagent → re-review → merge.
5. **Memory-sync**`@memory-syncer` дистиллирует handoff + ADR в `<memory_dir>/repos/{host}/{org}/{repo}.md`.
4. **Memory-sync**`@memory-syncer` дистиллирует PR body в `<memory_dir>/repos/{host}/{org}/{repo}.md`.
См. `AGENTS.md` (Development Workflow) и `run-pipeline` skill — все три документа описывают одну и ту же full-subagent модель делегирования.

View file

@ -1,11 +1,11 @@
---
name: run-pipeline
description: Autonomous PR pipeline executor. Delegates 7 phases to subagents, does not improvise order, does not merge on red CI. Also when user says "запусти пайплайн", "pipeline", "run pipeline".
description: 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 через 7 фаз. Source of truth для
Автономная процедура-loop для проведения PR через 6 фаз. Source of truth для
порядка и действий — `pipeline-status` tool. NEXT action из tool явно
указывает `subagent_type` + `template` (кроме MERGE — `merge-pr` tool).
@ -16,7 +16,7 @@ description: Autonomous PR pipeline executor. Delegates 7 phases to subagents, d
1. Вызови tool `pipeline-status({pr_number: M})` — вернёт статус всех фаз + строку `NEXT: <action>`.
2. Если вывод содержит `Status: COMPLETE` → финальный репорт пользователю, exit.
3. Если вывод содержит `AMBIGUOUS` → репорт пользователю с причиной, STOP.
4. Иначе — исполни action из строки `NEXT:` (используй prompt templates A-E ниже).
4. Иначе — исполни action из строки `NEXT:` (используй prompt templates A, C, D, E, F ниже).
5. 1 строка прогресса пользователю (формат: `✅ <phase> — <action executed>`).
6. Re-loop (шаг 1).
@ -45,10 +45,7 @@ description: Autonomous PR pipeline executor. Delegates 7 phases to subagents, d
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 (НЕ
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`
@ -56,43 +53,12 @@ description: Autonomous PR pipeline executor. Delegates 7 phases to subagents, d
`git add <конкретные-пути>`, НЕ `git add -A` (иначе лишние файлы уйдут в
коммит). Если в индексе лишнее (например `memory-save` stage'нул всё
через `git add -A`) — не коммить: сначала `git restore --staged <file>`.
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.
Если найдёшь баг вне scope текущей задачи — загрузи skill `bug-discovery` через `skill("bug-discovery")` и следуй протоколу. НЕ чини баг сам. Сообщи оркестратору: "Created issue #N: ...".
```
### Template B (docs-review)
```
Review PR#M в текущем репо (pre-merge, режим docs).
1. `gh pr checkout M`.
2. Анализируй структурные изменения: `git diff origin/HEAD...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``git status` для проверки staged set
(`commit` tool НЕ делает `git add` — коммитит только staged; НЕ
`git add -A`, иначе лишние файлы уйдут в коммит). Затем
`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).
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: ...".
```
@ -105,7 +71,7 @@ Review PR#M в текущем репо.
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).
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 которые парсит
@ -144,11 +110,13 @@ Log: `gh run view <run-id> --log-failed` output:
(default `~/.local/share/opencode/opencode-memory`, override через `OPENCODE_MEMORY_DIR`;
`{host}/{org}/{repo}` вычисли через
`git remote get-url origin` — см. `memory-syncer.md:38`).
1. Прочитай `docs/handoff/pr-M-*.md` и `docs/decisions/*-pr-M-*.md` с текущего
состояния (уже смерженный default branch — checkout/pull НЕ нужны, запрещены
permission set'ом memory-syncer'а).
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.
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-записей)`.
@ -171,7 +139,7 @@ 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).
`Status: COMPLETE` или перейдёт на MEMORY phase — 6-я фаза).
## API Restrictions

View file

@ -14,19 +14,18 @@
- filesystem research, grep/glob/find, read-for-context → delegate to `explore` subagent
- file edits, write, code implementation → delegate to `general` subagent
- bash commands, git ops, tests → delegate to the matching subagent
- review → `reviewer`, docs → `docs-reviewer`, memory → `memory-syncer`
- review → `reviewer`, memory → `memory-syncer`
- Maximum: high-level plan + reports to user + delegation to `task` subagents.
- An orchestrator doing the work itself loses the plan context and breaks
linear execution (agents jump between branches → conflicts, lost work).
- ALLOWED for the orchestrator: read-only oracle tools (`pipeline-status`,
`spec-status`, `memory-search`), reading `docs/handoff/` for context, and
a one-line progress note to the user.
- Pipeline: delegate each phase (ISSUE → IMPLEMENT → DOCS → CI → REVIEW → MERGE → MEMORY) to a subagent.
`spec-status`, `memory-search`), and a one-line progress note to the user.
- Pipeline: delegate each phase (ISSUE → IMPLEMENT → CI → REVIEW → MERGE → MEMORY) to a subagent.
- Subagent error → 1 retry, then STOP + report.
## Pipeline
Pipeline: ISSUE → IMPLEMENT → DOCS → CI → REVIEW → MERGE → MEMORY.
Pipeline: ISSUE → IMPLEMENT → CI → REVIEW → MERGE → MEMORY.
`pipeline-status` = read-only oracle (NEXT action). `merge-pr` = orchestrator-safe merge wrapper. Execution via `/run-pipeline` skill.
## Bug Discovery Protocol (MANDATORY)
@ -37,7 +36,7 @@ If you find a bug outside current task scope — you MUST:
3. Do NOT fix the bug yourself.
4. Report to orchestrator: "Created issue #N: ...".
This applies to ALL subagents (general, reviewer, docs-reviewer, memory-syncer).
This applies to ALL subagents (general, reviewer, memory-syncer).
## Linear Execution
@ -45,12 +44,12 @@ This applies to ALL subagents (general, reviewer, docs-reviewer, memory-syncer).
- Cannot start a second pipeline until the first is complete (merge or close).
- Issues are created by ONE agent at a time (batch creation), not parallel agents.
- Parallel research (explore agents, 3-4 concurrently) — allowed.
- Parallel execution (implementation/review/docs) — PROHIBITED.
- Parallel execution (implementation/review) — PROHIBITED.
- Reason: agents jump between branches → conflicts, lost work, chaos.
## Read Path
Before starting a task in a repo: scan filenames in `docs/handoff/` (if any) — open relevant ones by topic.
Before starting a task in a repo, use `memory-search` to recall relevant durable knowledge (gotchas, conventions, prior decisions).
## Code Style

View file

@ -33,12 +33,12 @@ A ready-to-run Docker config. Clone, fill `.env`, start — it works. Versioning
| 🌐 Global skills | All skills mounted via volume — work across all projects |
| 🧠 Portable memory | Markdown + git, syncs through private repo — assistant remembers everything |
| 🔍 Dual search | Keyword (ripgrep) always works, semantic — optional via OpenAI API |
| 🔧 Pipeline | ISSUE → IMPLEMENT → DOCS → CI → REVIEW → MERGE → MEMORY |
| 🔧 Pipeline | ISSUE → IMPLEMENT → CI → REVIEW → MERGE → MEMORY |
| 🤖 Subagent orchestration | Orchestrator only plans, subagents execute |
| 📋 Linear execution | One pipeline at a time — no branch conflicts |
| 🐛 Auto-issue | Bug found mid-task — agent creates GitHub issue and continues |
| 🛠️ Skills & commands | Built-in skills and slash commands, main one — `/run-pipeline` |
| 👥 Subagents | Built-in role-based agents — review, docs, memory sync |
| 👥 Subagents | Built-in role-based agents — review, memory sync |
<!-- features-en:end -->
### ⚡ Quick Start
@ -72,12 +72,12 @@ Access at http://localhost:4096
| 🌐 Глобальные скиллы | Все скиллы прокидываются через volume — работают во всех проектах |
| 🧠 Переносимая память | Markdown + git, синк через приватный репозиторий — ассистент помнит всё |
| 🔍 Двойной поиск | Keyword (ripgrep) всегда работает, semantic — опционально через OpenAI API |
| 🔧 Пайплайн | ISSUE → IMPLEMENT → DOCS → CI → REVIEW → MERGE → MEMORY |
| 🔧 Пайплайн | ISSUE → IMPLEMENT → CI → REVIEW → MERGE → MEMORY |
| 🤖 Subagent-оркестрация | Оркестратор только планирует, исполняют subagent'ы |
| 📋 Линейное выполнение | Один пайплайн за раз — без конфликтов веток |
| 🐛 Auto-issue | Баг найден в процессе — агент сам создаёт GitHub issue и продолжает работу |
| 🛠️ Скиллы и команды | Встроенные скиллы и slash-команды, основной — `/run-pipeline` |
| 👥 Subagent'ы | Встроенные агенты по ролям — review, docs, memory sync |
| 👥 Subagent'ы | Встроенные агенты по ролям — review, memory sync |
<!-- features-ru:end -->
### ⚡ Быстрый старт