# Delegation Manager > Координатор делегирования задач в GitHub-проекте (владелец + коллаборанты человек+Claude). Триггеры: «заведи задачу на …», «делегируй …», «статус делегированных», «какие PR готовы к мержу». Не для написания кода задачи и не для мержа/деплоя (необратимое — за владельцем). - Skill: `vibeengineering-llc/delegation-manager` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add vibeengineering-llc/delegation-manager` - Raw SKILL.md: https://api.skillmd.com/api/skills/vibeengineering-llc/delegation-manager/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: VibeEngineering-LLC (https://skillmd.com/u/vibeengineering-llc) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vibeengineering-llc/delegation-manager --- # delegation-manager — координатор делегирования в GitHub-проекте Владелец пишет часть кода сам (Claude Code), часть отдаёт коллаборантам (человек + его Claude). Этот скилл превращает сессию в **координатора делегирования**: завести задачу, назначить, отследить прогресс, свести статус — не ведя ручной учёт в голове. **Главный принцип: источник правды — GitHub, а не агент.** Всё состояние — в Issues, PR, Project-board. Агент — интерфейс к состоянию, не его хранилище. Сессия перезапустится и потеряет контекст — всё восстановится одним `gh issue list`. Никогда не держи «карту задач» только в памяти чата. Verbatim `gh`-команды, шаблон Issue, one-time настройка репо — `references/gh-playbook.md`. Экосистема мульти-агентного GitHub-контура — `references/multi-agent-github-ecosystem-2026-07-10.md`. ## Роли (hard-границы) | Роль | Инструмент | Действия | Гейт | |---|---|---|---| | **Владелец** | Claude Code + этот скилл | заводит Issues, ревьюит PR, **мержит**, двигает в `done` | мерж/тег/деплой — только он | | **Исполнитель** | свой Claude | берёт Issue, ведёт ветку `deleg/*`, открывает Draft PR, докладывает в PR | не мержит, не пушит в защищённые ветки | **Необратимое всегда за владельцем.** Координатор доводит задачу до `status:review` и говорит «готово к мержу #N» — но сам мерж/тег/деплой/force-push жмёт владелец. Не бюрократия, а защита от необратимой ошибки чужими руками. ## Машина состояний (единственная ось меток `status:*`) ``` status:ready → задача описана, назначена, ждёт исполнителя status:in-progress → исполнитель взял, ветка создана, Draft PR открыт status:review → PR готов (не draft), ждёт ревью/мержа владельца status:blocked → упёрлись, нужен вход владельца (обязателен коммент «почему») status:done → PR смержен, Issue закрыт ``` **Железное правило: метка меняется ТОЛЬКО вместе с действием.** Взял задачу → `ready`→`in-progress` И сразу пуш ветки + Draft PR (не «сначала метка, потом когда-нибудь ветка»). Это не даёт висящим задачам маскироваться под работу («агент крутится, прогресса ноль»). ## Единица делегирования = Issue с жёстким шаблоном Каждая задача/этап = **один** GitHub Issue по шаблону `.github/ISSUE_TEMPLATE/deleg.md` (полный текст — в `references/gh-playbook.md`). Три поля обязательны: **Задача** (что), **Границы** (какие файлы трогать / что НЕ трогать), **Definition of Done** (проверяемые критерии + команда тестов). Без явных Границ и DoD задача не делегируется — иначе исполнитель угадывает scope → scope-creep → неревьюибельный PR. ## Процедуры (что делает координатор; команды — в `references/gh-playbook.md`) - **Завести задачу** — `gh issue create` с меткой `delegated,status:ready`, назначить исполнителя, назвать владельцу номер. - **Свести картину** — `gh issue list --label delegated` + `gh pr list`, синтез строкой `Ready(N) | In-progress(N) | Review(N) | Blocked(N) | Done(N)` + что требует решения. - **Заблокированные** — `gh issue list --label status:blocked`, прочитать коммент «почему». - **Готовые к мержу** — `gh pr list --search "label:delegated draft:false"`, доложить «#N готов». **Сам не мержишь.** - **Двигать статус** — `gh issue edit` меняет метку (только вместе с действием, см. выше). Читаешь `gh` и синтезируешь **факт**, а не пересказываешь статус по памяти. ## One-issue-one-PR (против scope-creep) - Один Issue = одна ветка `deleg/<номер>-` = один PR. - PR трогает **только** файлы из «Границы» Issue. - Нашёл смежную проблему по ходу → **не чинишь молча**, а заводишь новый Issue `status:ready` и линкуешь. Не раздуваешь текущий PR. - PR открывается **Draft с первой минуты** (`gh pr create --draft`) с `Closes #N` в теле — владелец видит живые коммиты, Issue закроется сам при мерже. ## Трекинг и доклад - **Project-board**: колонки = статус-метки, deleg-Issues попадают по метке `delegated`. На «что там» — читаешь доску через `gh` и синтезируешь, не по памяти. - **Апдейты — в PR-коммент, не в личку** (владелец подписан на PR → уведомление само; формат — в `references/gh-playbook.md`). Никаких «статус-пингов» в чат. ## Анти-паттерны (не делать) - ❌ Держать список задач только в памяти чата. → Всегда в Issues. - ❌ Ставить `in-progress` без пуша ветки. → Метка = действие. - ❌ Мержить/тегать/деплоить за владельца. → Необратимое за ним. - ❌ Раздувать PR смежными правками. → Новый Issue. - ❌ Делегировать задачу без Границ и Definition of Done. → Шаблон обязателен. - ❌ Пересказывать статус по памяти. → Читать `gh`, синтезировать факт. ## Разовая настройка репо + эскалация **Настройка** (владелец, один раз): write-доступ исполнителю, branch-protection на `main`/`develop`, 6 меток (`delegated` + пять `status:*`), `.github/ISSUE_TEMPLATE/deleg.md`, Project-board, конвенции (команда тестов / базовая ветка / `deleg/*`) в `CLAUDE.md` репо. Пошагово с bash — `references/gh-playbook.md`. **Эскалация в Уровень 3:** задач стабильно 5+ параллельно → вынести координацию в **отдельную** сессию Claude Code (изоляция контекста + разделение actor≠coordinator). Скилл тот же, живёт в выделенном окне. До 5 задач — overhead не оправдан.