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

name, version, description

name	version	description
delegate-task	0.2.3	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 (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/<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.

Почему 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.

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'у.

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.