Add delegate-task to hermes/mapping.yaml. Mode: pending with intended {auto, mcp} — the skill calls mcp__projects-meta__tasks_create (cross-project Gitea side-effect), so it needs a behavioral audit via delegate-task-test-trigger before promotion to auto, mirroring the other MCP-touching pending entries (using-vds-ops, using-wiki-graph).
Bump delegate-task SKILL.md 0.1.0 -> 0.2.0 (project-discipline Rule 3).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
7.2 KiB
name, version, description
| name | version | description |
|---|---|---|
| delegate-task | 0.2.0 | Use when delegating a task to another agent or project via mcp__projects-meta__tasks_create. Triggers: «делегировать таску», «delegate task», «создать задачу на агента», «поставить задачу агенту», «tasks_create для». Does NOT apply when doing the work yourself or for 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 для».
Не применяется:
- Работа которую выполняешь сам в текущей сессии.
- 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-humannotify— slug проекта-комиссионера (кому писать inbox при close/park)allow_upgrade—true/false(опционально; разрешить ли fallback на tier выше если нет matching backend)
Steps
1. Pre-flight gate (5 вопросов пользователю)
Спросить до составления тела задачи:
- Критическая инфраструктура? — задача меняет: поллер/агент-раннер, MCP серверы (projects-meta, interns), механизм claim/close/heartbeat, deploy-инфру (traefik, docker, systemd), CI/CD пайплайны, git hooks.
- Если да →
weight: needs-humanпринудительно, без обсуждения. Объяснить пользователю почему. - Если нет → идти дальше.
- Если да →
- Интерны — разрешены? (да/нет, per задача)
- Автопуш — разрешён? (да/нет, per задача)
- Контекстные скилы сверх дефолтов? — предложить по содержанию задачи (например
claude-apiдля работы с Anthropic SDK,frontend-designдля UI,using-internsесли интерны разрешены), пользователь утверждает. - 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» в тексте слабее чем «invoketdd-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.