Files
claude-skills/skills/delegate-task/SKILL.md
vitya 24db19b6b7 feat(hermes): map delegate-task as pending (MCP audit gate)
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>
2026-06-09 12:23:03 +03:00

7.2 KiB
Raw Blame History

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)
  • weightcheap-ok | needs-claude | needs-human
  • notify — slug проекта-комиссионера (кому писать inbox при close/park)
  • allow_upgradetrue/false (опционально; разрешить ли fallback на tier выше если нет matching backend)

Steps

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

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

  1. Критическая инфраструктура? — задача меняет: поллер/агент-раннер, MCP серверы (projects-meta, interns), механизм claim/close/heartbeat, deploy-инфру (traefik, docker, systemd), CI/CD пайплайны, git hooks.
    • Если даweight: needs-human принудительно, без обсуждения. Объяснить пользователю почему.
    • Если нет → идти дальше.
  2. Интерны — разрешены? (да/нет, per задача)
  3. Автопуш — разрешён? (да/нет, per задача)
  4. Контекстные скилы сверх дефолтов? — предложить по содержанию задачи (например claude-api для работы с Anthropic SDK, frontend-design для UI, using-interns если интерны разрешены), пользователь утверждает.
  5. 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.