claude-skills/skills/delegate-task/SKILL.md

name, version, description

name	version	description
delegate-task	0.2.1	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 <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)

Steps

1. Pre-flight gate (5 вопросов пользователю)

Спросить до составления тела задачи:

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)

2. Составить тело задачи по шаблону

Секции строго по порядку:

<Цель — одно-два предложения. Acceptance criteria если есть.>

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

- 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]

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

3. Dry-run preview

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

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

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

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

Если задача имплементационная — создать парную <slug>-review (status=blocked, blocker=<slug>). Пропустить для: pointers-тасок, ops-тасок, research-тасок, любых non-impl.

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.
• Не назначать weight: cheap-ok для задач где дисциплина критична (review, security, schema migration) — слабые модели могут игнорировать invoke-инструкции.
• Не назначать weight: needs-claude или cheap-ok задачам, меняющим критическую инфраструктуру (поллер, MCP серверы, deploy, CI/CD) — только needs-human.