vitya
5fc0ccc1d3
Пробел: ТЗ, поручающее прогу создать deploy-таску админу, требовало лишь tasks_create — таска на борде живую сессию не пингует, повисла бы незамеченной. Добавлен Step 6 + What-NOT-to-do bullet: poller→Weight/Notify, live→inbox-письмо, не уверен→оба. Инцидент тиража snolla (оператор вставлял прогам за меня). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
142 lines
13 KiB
Markdown
142 lines
13 KiB
Markdown
---
|
||
name: delegate-task
|
||
version: 0.2.4
|
||
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 (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'у.
|
||
|
||
### 6. Downstream-задача для ЖИВОЙ сессии → требовать task + inbox-письмо
|
||
|
||
Если тело задачи **поручает агенту самому создать downstream-задачу** для другого проекта, где работает **живая интерактивная сессия** (напр. прог сам ставит deploy-таску админу), — в ТЗ **явно потребуй И `tasks_create`, И inbox-письмо** тому проекту (`<target>/.claude-inbox/<ts>-<from>.md`).
|
||
|
||
Причина: таска на борде живую сессию **НЕ пингует**. Поллер подхватит по `Weight`/`Notify`, но живая интерактивная сессия узнаёт только через inbox-монитор / Stop-хук — т.е. через письмо. ТЗ, требующее лишь `tasks_create`, оставляет downstream-таску висеть незамеченной, и кто-то доделывает пинг руками.
|
||
|
||
Правило: poller-driven таргет → `Weight`/`Notify` обязательны; live-сессия → inbox-письмо обязательно; **не уверен, поллер или живой — требуй ОБА.** Это же правило применяй, когда пингуешь пира сам: task + letter, не только task.
|
||
|
||
## 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.
|
||
- **Не поручать агенту создать downstream-таску для живой сессии без парного inbox-письма** (см. Step 6). `tasks_create` в чужой борд живую сессию не пингует — ТЗ обязано требовать И таску, И письмо, иначе downstream-таска висит незамеченной.
|