--- name: delegate-task version: 0.2.4 description: > Use when delegating a task to another agent or project via mcp__projects-meta__tasks_create. Triggers: «делегировать таску», «delegate task», «создать задачу на агента», «поставить задачу агенту», «tasks_create для». Does NOT apply to self-assigned tasks on your own board («создать задачу себе», «task for myself», «поставить себе задачу» → using-tasks), to work you do yourself, or to workshop-internal tasks. --- # delegate-task Унифицированный формат постановки задач на агентов через `mcp__projects-meta__tasks_create`. Обеспечивает что каждая делегированная задача содержит: обязательные скилы (императивный invoke), pre-flight разрешения, steering-loop поля (notify/weight/allow_upgrade). ## When to use Перед каждым вызовом `mcp__projects-meta__tasks_create` для другого проекта или агента. **Активируется:** «делегировать таску», «delegate task», «создать задачу на агента», «поставить задачу агенту», «tasks_create для». **Не применяется:** - Работа которую выполняешь сам в текущей сессии. - Self-assigned таски на своей доске («создать задачу себе», «task for myself», «поставить себе задачу») → `using-tasks`, не делегирование. Дизамбигуатор: «на агента»/«агенту»/«в проект X» = делегирование; «себе»/«myself» = своя доска. - Workshop-internal таски (`.workshop/.tasks/` — workshop-meta, не делегирование). - `tasks_create` с `target=agenda` (cross-project agenda — не делегирование агенту). ## Inputs - `target_project` — qualified `/` (обязательно) - `slug` — kebab-case latin - Краткое описание задачи (цель + acceptance criteria) - `weight` — `cheap-ok | needs-claude | needs-human` - `notify` — slug проекта-комиссионера (кому писать inbox при close/park) - `allow_upgrade` — `true/false` (опционально; разрешить ли fallback на tier выше если нет matching backend) ## Steps ### 1. Pre-flight gate (6 вопросов пользователю) Спросить **до** составления тела задачи: 0. **Критическая инфраструктура?** — задача меняет: поллер/агент-раннер, MCP серверы (projects-meta, interns), механизм claim/close/heartbeat, deploy-инфру (traefik, docker, systemd), CI/CD пайплайны, git hooks. - Если **да** → `weight: needs-human` принудительно, без обсуждения. Объяснить пользователю почему. - Если **нет** → идти дальше. 1. **Интерны — разрешены?** (да/нет, per задача) 2. **Автопуш — разрешён?** (да/нет, per задача) 3. **Контекстные скилы сверх дефолтов?** — предложить по содержанию задачи (например `claude-api` для работы с Anthropic SDK, `frontend-design` для UI, `using-interns` если интерны разрешены), пользователь утверждает. 4. **notify — кому докладывать о завершении/затыке?** (slug проекта; обычно `.workshop` или `OpeItcLoc03/workshop`) 5. **Session-break после этой задачи?** — нужен ли разрыв сессии после её закрытия (domain-switch, milestone, heavy infra)? - Если **да** → проставить `session_break` в теле задачи (см. шаблон): `true` или строка-hint с названием следующего трека. `using-tasks` остановится после close и предложит завершить сессию, не клеймя следующую задачу. - Если **нет** → поле не добавлять (дефолт — агент продолжает `claim-next`). ### 2. Составить тело задачи по шаблону Секции строго по порядку: ``` <Цель — одно-два предложения. Acceptance criteria если есть.> ## Обязательные скилы — вызвать до начала работы - invoke `tdd-criteria` — до написания кода - invoke `using-tasks` — для управления статусом задачи - invoke `project-discipline` — дисциплина коммитов/пушей - invoke `using-wiki` после закрытия — заингесть .wiki/concepts/.md [если кросс-проектная: - invoke `using-projects-meta` — cross-project tasks/wiki] [контекстные скилы из шага 1.3] **TDD:** да | нет — <причина> **Разрешения:** интерны: да/нет | автопуш: да/нет **weight:** cheap-ok | needs-claude | needs-human **notify:** [**allow_upgrade:** true/false] [**session_break:** true | "<следующий трек / hint>"] # optional — using-tasks остановится после close, не клеймит следующую задачу ``` **Когда ставить `session_break`** (опционально; по умолчанию НЕ ставить — это маркер реальной границы, не дефолт). Три случая: 1. **Смена домена / репо** — задача завершает один трек перед переходом на несвязанный. 2. **Milestone-задача** — последняя в группе sub-tasks одной фичи. 3. **Тяжёлая инфра-задача** — shared checkout, migrations, deploy — где разумно остановиться и проверить состояние. Значение: `true` (следующий трек = «см. STATUS.md») либо строка-hint с названием следующего трека. Потребитель — `using-tasks` v1.2.0+ (Task completion step 6): после close печатает `🔚 SESSION BOUNDARY …` и останавливается, не клеймя следующую задачу. Дизайн: `.wiki/concepts/delegate-task-session-break.md`. **Почему `invoke` а не триггер-фраза:** CLAUDE.md ненадёжен (уплывает при compression, слабые модели игнорируют). Тело задачи читается активно — императив `invoke` это прямая команда, не пассивный матчинг. ### 3. Dry-run preview `tasks_create(confirm=false)` — показать пользователю preview до реального коммита. ### 4. Подтверждение и создание После OK пользователя: `tasks_create(confirm=true)`. ### 5. Парная review-таска (только для impl-задач) Если задача имплементационная — создать парную `-review` (status=blocked, blocker=``). Пропустить для: pointers-тасок, ops-тасок, research-тасок, любых non-impl. **`weight` review-таски — наследовать от impl-таски, но не ниже `needs-claude`** (проставлять явно при `tasks_create`): - impl `needs-human` → review `needs-human` (критично-инфраструктурное изменение нельзя ревьюить слабым tier'ом — ревью наследует строгость impl). - impl `needs-claude` → review `needs-claude`. - impl `cheap-ok` → review `needs-claude` (флор: review дисциплинарно-критична, см. What NOT to do — cheap-ok сюда не опускать). Без явного `weight` поллер не маршрутизирует review-таску (reconciler её пропускает) — поэтому проставлять всегда, даже когда impl и review совпадают по tier'у. ### 6. Downstream-задача для ЖИВОЙ сессии → требовать task + inbox-письмо Если тело задачи **поручает агенту самому создать downstream-задачу** для другого проекта, где работает **живая интерактивная сессия** (напр. прог сам ставит deploy-таску админу), — в ТЗ **явно потребуй И `tasks_create`, И inbox-письмо** тому проекту (`/.claude-inbox/-.md`). Причина: таска на борде живую сессию **НЕ пингует**. Поллер подхватит по `Weight`/`Notify`, но живая интерактивная сессия узнаёт только через inbox-монитор / Stop-хук — т.е. через письмо. ТЗ, требующее лишь `tasks_create`, оставляет downstream-таску висеть незамеченной, и кто-то доделывает пинг руками. Правило: poller-driven таргет → `Weight`/`Notify` обязательны; live-сессия → inbox-письмо обязательно; **не уверен, поллер или живой — требуй ОБА.** Это же правило применяй, когда пингуешь пира сам: task + letter, не только task. ## Failure modes - **Пользователь отказывает на pre-flight** → abort, задачу не создавать. - **Пользователь отклоняет dry-run preview** → abort. - **notify не указан** → переспросить, не пропускать молча. Без notify steering-loop не замыкается. - **weight не указан** → переспросить. Без weight поллер не знает кому отдать задачу. - **tasks_create упал** → сообщить пользователю, не делать retry без явного запроса. ## Side effects - Создаёт таску в target-проекте через `mcp__projects-meta__tasks_create` (Gitea commit). - Опционально создаёт парную review-таску (status=blocked). ## What NOT to do - Не пропускать pre-flight gate — даже если кажется что всё очевидно. - Не использовать пассивные триггер-фразы вместо `invoke` — «tdd-criteria» в тексте слабее чем «invoke `tdd-criteria`». - Не пропускать `notify` — без него boss не узнает о завершении. - Не пропускать `weight` — без него fleet routing слеп. - Не создавать review-таску для pointers/ops/research задач — только для impl. - Не создавать review-таску без `weight` — reconciler/поллер её пропустит. Наследовать от impl, флор `needs-claude` (см. Step 5). - Не назначать `weight: cheap-ok` для задач где дисциплина критична (review, security, schema migration) — слабые модели могут игнорировать invoke-инструкции. - Не назначать `weight: needs-claude` или `cheap-ok` задачам, меняющим критическую инфраструктуру (поллер, MCP серверы, deploy, CI/CD) — только `needs-human`. - Не ставить `session_break` рутинно на каждую задачу — это маркер реальной границы (domain-switch / milestone / heavy infra), не дефолт; иначе `using-tasks` рвёт сессию после каждого close. - **Не поручать агенту создать downstream-таску для живой сессии без парного inbox-письма** (см. Step 6). `tasks_create` в чужой борд живую сессию не пингует — ТЗ обязано требовать И таску, И письмо, иначе downstream-таска висит незамеченной.