vitya
8b22d16c20
«создать задачу себе» false-positive-fired delegate-task instead of using-tasks (5/5 trials, found by delegate-task-test-trigger). Root cause: the self-task phrase shares the stem «создать задачу» with the positive trigger «создать задачу на агента», and the abstract "Does NOT apply when doing the work yourself" carve-out cannot beat a literal stem-match under the using-superpowers 1%-rule. Fix: make the negative literal + routed. Description now lists «создать задачу себе» / «task for myself» / «поставить себе задачу» -> using-tasks; body "Ne primenyaetsya" gains a self-assigned bullet plus a disambiguator («на агента»/«агенту»/«в проект X» = delegate; «себе» = own board). PATCH bump 0.2.0 -> 0.2.1. Verification (fresh-context subagents, simulated available-skills registry, no hint): positives 5/5 -> delegate-task (no regression); negative «создать задачу себе на завтра» 4/5 -> using-tasks (was 0/5). The 1 residual miss reasoned correctly but tripped on an eval-harness artifact (prompt forced skill-name-before-reasoning), not description ambiguity. Wiki: concept page delegate-task-negative-trigger-fp.md + index/log. Board: [delegate-task-description-fp-fix] -> done. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
111 lines
7.7 KiB
Markdown
111 lines
7.7 KiB
Markdown
---
|
||
name: delegate-task
|
||
version: 0.2.1
|
||
description: >
|
||
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`.
|