skills/skills/delegate-task/SKILL.md

name, author, version, description

name	author	version	description
delegate-task	ours	0.5.1	Use when delegating a task to another agent or project via mcp__projects-meta__tasks_create. Every cross-project delegation is a pair: tasks_create + covering letter to the recipient's inbox (event: created) — a task on the board does not ping a live session. 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 <owner>/<repo> (обязательно)
• 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)

Номер задаче присваивает сервер (tasks_create из счётчика OpeItcLoc03/agenda/task-counter) — постановщик номер не придумывает и не резервирует. Возвращённый #n из preview/confirm — машинный ключ задачи: им ссылаются блокеры, письма, decision-trail.

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 если есть.>
**Спека:** <path к design-решению или .brainstorm/…> — обязательно для задач
из дизайна/решения: импл читает дизайн, не угадывает

## Обязательные скилы — вызвать до начала работы

- invoke `tdd-criteria` — до написания кода
- invoke `using-tasks` — для управления статусом задачи
- invoke `project-discipline` — дисциплина коммитов/пушей
- invoke `using-wiki` после закрытия — заингесть .wiki/concepts/<slug>.md
[если кросс-проектная: - invoke `using-projects-meta` — cross-project tasks/wiki]
[контекстные скилы из шага 1.3]

**TDD:** да | нет — <причина>
**Разрешения:** интерны: да/нет | автопуш: да/нет
**weight:** cheap-ok | needs-claude | needs-human
**notify:** <commissioning-project-slug>
[**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.

Этапные цепочки (staged breakdown): если решение бьётся на этапы (1 → 1b → 3), создавай каждый этап отдельной таской со status: blocked + blocker: <номера-предшественников> (#n1, #n2 — номера, не слаги; номер = машинный ключ). Доска показывает порядок, поллер не возьмёт зависимую работу раньше времени. Таски в один репо создавай последовательно, не параллельно (иначе sha-lock конфликт — см. Failure modes).

Почему invoke а не триггер-фраза: AGENTS.md ненадёжен (уплывает при compression, слабые модели игнорируют). Тело задачи читается активно — императив invoke это прямая команда, не пассивный матчинг.

3. Dry-run preview

tasks_create(confirm=false) — показать пользователю preview до реального коммита.

4. Подтверждение и создание

После OK пользователя: tasks_create(confirm=true).

5. Сопроводительное письмо — обязательно при кросс-проектной делегации

После создания каждая кросс-проектная делегация дублируется письмом в инбокс получателя (канон — inter-session-messaging v2: канал Mappa, адрес из адресной книги ~/projects/.wiki/concepts/projects-address-book.md):

mcp__mappa__inbox_send(
  project: <адрес-получателя>,   # имя папки, из адресной книги
  from:    <своя-папка>,
  subject: "[event: created] #n slug",
  body:    "1-2 строки — что за задача, почему, slug; «разбери и возьми»"
)

(Мутация тасок гейтится лизом проекта — task_claim_next; доставка письма — карв-аут, лиза не требует.)

Причина: таска на борде не пингует живую сессию получателя. Поллер подхватит по Weight/Notify, но живая интерактивная сессия узнаёт только через inbox-монитор — т.е. через письмо. Правило «task + letter, не только task» — общий случай (шаг 7 — его частность для downstream-задач).

Пропуск: self-assigned задачи на своей доске; target=agenda (общая доска, конкретного получателя нет — steering-loop через Notify).

6. Парная review-таска (только для impl-задач)

Если задача имплементационная — создать парную <slug>-review (status=blocked, blocker=#n — номер impl-таски). Пропустить для: 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'у.

7. Downstream-задача для ЖИВОЙ сессии → требовать task + inbox-письмо

Если тело задачи поручает агенту самому создать downstream-задачу для другого проекта, где работает живая интерактивная сессия (напр. прог сам ставит deploy-таску админу), — в ТЗ явно потребуй И tasks_create, И inbox-письмо тому проекту (mcp__mappa__inbox_send(project=<target>, from=<своя>, subject="[event: created] #n slug", ...)).

Причина: таска на борде живую сессию НЕ пингует. Поллер подхватит по 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 упал → различить: PushRejected (sha-lock конфликт — репо уехало между preview и confirm; бывает при параллельном создании в один репо) → retry: повторить confirm — сервер перечитает актуальный base_sha. Другие ошибки → сообщить пользователю, не делать 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 6).
• Не назначать 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.
• Не создавать задачи из дизайна/решения без **Спека:**-ссылки — импл-агент угадывает пороги/скоуп вместо чтения дизайна.
• Не создавать несколько тасок в один репо параллельно — sha-lock конфликты (PushRejected); сериализуй confirm'ы.
• Не делегировать кросс-проектную задачу без сопроводительного письма в инбокс получателя (шаг 5, Mappa inbox_send). tasks_create в чужой борд живую сессию не пингует — task без letter остаётся незамеченной до поллера/руки.
• Не поручать агенту создать downstream-таску для живой сессии без парного inbox-письма (см. Step 7). tasks_create в чужой борд живую сессию не пингует — ТЗ обязано требовать И таску, И письмо, иначе downstream-таска висит незамеченной.