К основному содержанию
скилл CX Codex

queue-handoff — скилл для Claude Code: что делает и как установить

Передаёт задачи через очередь OpenRig при смене хода агента, блокировках или эскалации на человека, не давая процессам засыпать.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add mvschwarz/openrig --skill queue-handoff -a claude-code
Открыть на GitHub

Что делает queue-handoff

Скилл регламентирует передачу рабочих задач через очередь rig queue. Вместо того чтобы бросать контекст в чате при уплотнении диалога или обрыве связи, агент фиксирует статус в очереди. Правило «горячей картошки» требует завершать ход реальным действием: передать управление новому исполнителю, эскалировать вопрос человеку или зафиксировать итог. Набранная инструкция, оставленная в буфере без отправки, считается сбоем и глушит процесс.

Конечный автомат строго проверяет причины закрытия задачи. Переходы со статусами handed_off_to и escalation требуют явной цели в closure_target. Совмещать финальное завершение со статусом ожидания демон OpenRig запрещает. Если работа упёрлась в другой процесс, агент вызывает команду rig queue block <id> --on <child>, и задача вернётся в статус ожидания сразу после снятия блокировки.

В CLI версии 0.3.1 команды создания и передачи задач будят получателя по умолчанию. Флаг --no-nudge отключает это уведомление, но нужен только для холодной парковки или ручных проверок. Флага --notify в этой версии нет: вызов с ним сломает команду. После передачи эстафеты агент обязан проверить свою очередь и взять следующее дело, а не уходить в спячку.

Какие задачи решает

  • передать незавершённую задачу следующему агенту через очередь rig queue
  • заблокировать задачу до завершения зависимого процесса
  • эскалировать проблему человеку с сохранением записи в очереди вместо сообщения в чате
  • закрыть устаревшие исходящие назначения при переходе фазы проекта
  • исключить простой агента при наличии готовых задач в собственном входящем списке

Примеры запросов агенту

  • Передай эту задачу следующему агенту через rig queue handoff с описанием шагов
  • Заблокируй задачу #12 до окончания работы над процессом #15 через rig queue block
  • Отправь эскалацию человеку в очередь с флагом --no-nudge для ручного подтверждения

Как установить queue-handoff

1Через Skills CLI (Vercel)

npx skills add mvschwarz/openrig --skill queue-handoff -a claude-code

2Вручную: положить файлы

~/.claude/skills/queue-handoff/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/queue-handoff/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о queue-handoff

Как установить queue-handoff в Claude Code?

Выполните команду npx skills add mvschwarz/openrig --skill queue-handoff -a claude-code. Конфигурация запишется по пути ~/.claude/skills/queue-handoff/SKILL.md.

Что делает скилл queue-handoff?

Он задаёт правила передачи задач между агентами через очередь OpenRig, защищая ход работы от потери контекста при сжатии истории или прерываниях.

Зачем нужен флаг --no-nudge в CLI 0.3.1?

Команды очереди по умолчанию отправляют пинг для пробуждения получателя, а --no-nudge служит явным отключением уведомления для холодной парковки или ручных гейтов.

Исходный текст

SKILL.md · Apache-2.0
---
name: queue-handoff
description: Use when ending a turn, finishing a slice, blocked on another agent's work, or escalating to a human — durable work handoff via queue items so the system keeps moving across compactions, missed messages, and interruptions. Covers the hot-potato terminal-turn-rule (active work ends by passing the ball, not by going idle), default-nudge semantics, and when `--no-nudge` is appropriate for intentional cold park or human gate.
metadata:
  cli_surfaces_referenced:
    - queue
    - queue create
    - queue handoff
    - queue handoff-and-complete
  openrig:
    stage: factory-approved
    sibling_skills:
      - watchdog
      - refocusing
      - human-in-the-loop
---

# Queue Handoff

Durable work handoff via queue items. Lets the system keep moving
through compactions, missed messages, and interruptions by passing the
ball forward instead of leaving work suspended in chat or in-flight
without an owner.

## Use this when

- **Ending a turn on substantive work.** Active work should end by
  passing the ball to an owner or to the human — never by going idle
  with the rig appearing dormant.
- **Finishing a slice that has a clear next step.** Default-nudge:
  receiver gets a wake-ping plus the durable queue item.
- **Blocked on another agent's work.** Use `rig queue block <id> --on <child>`
  (or `rig queue update <id> --state blocked --blocked-on <child>`). The item
  stays active and returns to pending when its blocker completes.
- **Escalating to the human.** Make the escalation a durable attention
  item, not just a chat message.

## Don't use this when

- The work is genuinely complete and there's no follow-on owner. Use
  `closure_reason: no-follow-on` (terminal completion) or
  `canceled`/`denied` as appropriate.
- The handoff would be too small and turn work into bureaucracy. Bundle
  the work into a coherent slice instead of decomposing every step.
- The handoff would be too broad and lose ownership/proof/closure
  criteria. Shape the qitem so the receiver knows the expected next
  action and closure evidence.

## The hot-potato terminal-turn-rule

Active work ends by passing the ball to a named next owner or to the
human. The qitem state machine enforces this:

`pending → in-progress → done` requires `closure_reason` from one of:

- `handed_off_to` — work continues at a different seat (target = new owner)
- `denied` — receiver rejected the work
- `canceled` — sender or receiver withdrew
- `no-follow-on` — terminal completion, nothing else needed
- `escalation` — kicked up to a higher tier (target = escalation target)
- `superseded` — replaced by another qitem (target = successor qitem id)

Two of those (`handed_off_to`, `escalation`) additionally
require `closure_target`. The daemon enforces this at the domain layer;
every surface (CLI, MCP, future UI) inherits the same guarantee.

`done` is terminal. `closure_reason: blocked_on` is valid only on an active
`state=blocked` park record, as used by workflow writers; combining it with
`state=done` is rejected. Use the block command above to wait on another qitem.

**The drafted-park failure (draft ≠ throw).** The rule is about the *actual* pass, not the
intention to pass. A turn that ends with a self-instruction **typed into your own prompt but left
unsent** — a drafted go-ahead, a next-atom note you never sent — has **not** handed off; it has
**parked**, and the seat sits idle for as long as nobody notices. Drafting the handoff feels like
doing it; it isn't. **Your last act on a turn must be an EDIT or a SEND** — a committed change, a
`rig send`, a `rig queue` handoff — **never a drafted prompt line left in the buffer.** If your
final output is an instruction addressed to yourself, you haven't ended the turn, you've stalled it.

**The dispatcher's other half — supersession closes your own outbox.** Ending your turn cleanly is
only half the rule; the other half fires when *you* move the world. **When a phase transition or a
fold receipt supersedes work you dispatched, close those dispatches yourself — with a citation to the
event that superseded them.** Closure-on-supersession belongs to the **dispatcher, never the
receiver.** Make it a habit: after every fold receipt / phase transition, run an **outbox audit** —
*which of my open dispatches did this just make moot?* — and close them with the citation.

*Why it must live with you:* stale dispatch-debt is **invisible to the dispatcher** because it lands
on someone else's queue — the cost is externalized, so no feedback loop ever fires to make you clean
it up. The receiver inherits debt they did not create and must burn cycles verifying it before they
can hold cleanly; a queue full of stale-pending makes *check-before-holding* — the discipline you
most want cheap — expensive, and it degrades the idle-detector's signal (a real owner looks the same
as a stale dispatch). Close it at the source: the moment your own transition mooted it.

**And after you hand off, PULL — don't idle with a stocked queue.** Handing the baton off ends the
*sequential* thread; it does not end *your* turn if your own queue still holds work. The circulation
pattern: finish → (1) hand the baton off so sequential work continues → (2) **check your OWN queue and
pull the next item** rather than going idle → (3) go truly idle only when your queue is **exhausted**,
then wait for the baton. An agent idling on top of a stocked queue is the single biggest utilization
leak (see `orchestration-team` → *queue depth is the orchestrator's product*). This is pull-not-push at
the seat level and needs no new machinery — the last act *after a handoff* is a **PULL**.

## Default-nudge semantics (the syntax footgun)

| Command | Nudges by default? | When to use |
|---|---|---|
| `rig queue create` | yes | New qitem created from scratch |
| `rig queue handoff` | yes | Transactional close-as-handed-off + create-new |
| `rig queue handoff-and-complete` | yes | Atomic close + create-new; default nudge wakes the new owner |

**Footgun**: `--no-nudge` accidentally added to a live-loop handoff.
The shipped 0.3.1 CLI nudges by default on every queue write surface
(`rig queue create`, `rig queue handoff`, AND `rig queue handoff-and-complete`).
The only suppression flag is `--no-nudge` — appropriate for intentional
cold park, human-gate signal, or a deliberate poll-driven workflow, but
NOT for live-loop handoffs where motion matters.

**Rule**: in a live loop, omit `--no-nudge` and trust the default.
`--no-nudge` is the opt-out, not the opt-in. If you find yourself
reaching for `--notify`, stop — that flag does not exist on the
shipped 0.3.1 CLI; you may be following a stale instruction that
inverted the default-nudge polarity.

## Every queue row

- **`--summary "<what it is and why this seat>"`** on every `create`, `handoff` and `handoff-and-complete`: one or two plain sentences. It is the row's subject in RECENT, the story and the needs-you view, and a handoff does not inherit it from the source row.
- **Scope tags `project:<id>`, `mission:<id>`, `slice:<id>`** on project work, set when you create the row (`--tags`; `create` also takes `--mission` and `--slice`). Tags can't be edited afterwards. A handoff keeps the source row's tags unless you pass `--tags` or `--gate`, either of which replaces them; repeat the scope tags in `--tags` when you use `--gate`.
- **Pass work on with `handoff-and-complete`.** It closes your row as done and records the next row as its successor in one step. A `create` followed by `update --state done --closure-reason handed_off_to` records no successor, and the stuck sweep raises a recovery item for it.
- **Close what you hold.** A row you claimed ends in a handoff or an `update --state done --closure-reason …`; `rig queue overdue` lists claimed rows past their deadline.
- **Use the write's response.** Read the row back only when the response doesn't show what you need (an indeterminate outcome, a field the compact output left out, downstream wake or pickup, a team custody rule): openrig-user, "After a queue write".
- **Brief for the model that will read it.** Before handing a peer open-ended work, check which model it runs: `delegating-work`, "Check what kind of agent you're handing it to".

## Queue-body hygiene (token + parse safety)

The qitem body is durable DATA the daemon stores and replays on every
`rig queue show <id>` / `--json` read. Keep it small and parse-safe — a
bloated or malformed body costs every future reader, not just the
recipient.

- **No large command output in bodies.** Do NOT paste `rig ps`/`--nodes`
  dumps, big JSON blobs, full proof output, diffs, or transcript chunks
  into a qitem body. **Link the artifact PATH** (e.g.
  `missions/<m>/<slice>/proof.md`) or **summarize in prose**, then point
  at the file for the detail. A pasted dump makes `rig queue show <id>
  --full --json` large. Compact defaults limit a preview, but the stored body
  still costs readers who need full detail. Keep evidence in its durable artifact.
- **Substantive bodies go through `--body-file`, not inline `--body`.**
  For anything beyond a short line, write the body to a file and pass
  `--body-file <path>` (or `-` for stdin). Inline `--body` with shell
  metacharacters is fragile.
- **No raw backticks in bodies.** Backticks in an inline body are shell
  command-substitution and corrupt the payload (or execute). If you need
  code/command spans, use `--body-file`, or drop the backticks and write
  the command in plain text.

Heuristic: if the thing you want to include is more than a few lines or
contains shell metacharacters (backticks, `$`, quotes, newlines-with-pipes),
it belongs in a file you LINK, not in the body you paste.

The current `rig queue show` returns a bounded body preview by default;
`--full` returns the complete body and chain fields. Preview truncation does
not truncate the stored work. Check `bodyTruncated` and `bodyBytes`, then request
full content when needed; keep large supporting evidence in linked artifacts.

## Failure modes (6; verbatim)

1. Agent ends a turn without a handoff, so the rig appears idle.
2. Agent creates a queue item with `--no-nudge` inside a live loop, intending suppression of attention but breaking immediate motion. `--no-nudge` is for intentional cold park / human gate, not for routine live-loop handoffs. The opposite footgun — adding a `--notify` flag that does not exist on the shipped 0.3.1 CLI — comes from following stale instructions; the default already nudges.
3. Queue item is too small and turns work into bureaucracy.
4. Queue item is too broad and loses ownership, proof, or closure criteria.
5. Human escalation happens in chat but not as a durable attention item.
6. Agent pastes a large command dump (ps/nodes, big JSON, proof blob) into the qitem body, bloating the stored DATA so every full-body read is large. Link the proof PATH or summarize in prose; substantive bodies go through `--body-file`; no raw backticks inline.

## Durable handoff field shape

Every qitem carries:

- `handed_off_to` — destination session (qualified `pod-member@rig` form)
- `handed_off_from` — predecessor qitem id (the source session is `source_session`)
- `state` — one of: `pending | in-progress | done | blocked | failed | denied | canceled | handed-off`
- `closure_reason` + `closure_target` — set on terminal closure per hot-potato rule

**(0.5.0) `--body-context <ref>` — context riding the handoff.** `rig queue create … --body-context <ref>` attaches a composed context pack to the qitem. The snapshot rule: the qitem stores the **resolved content** in its body **plus the ref for provenance** — the handoff carries what was actually sent, and a later edit to the library never silently rewrites a past handoff's history. (The `rig context` noun composes the ref; the queue delivers it — the noun has no send.) See `openrig-user` → "Context packs and paced delivery."

The fields are auditable on the daemon-backed `rig queue` surface. Watchdog
policies and workflow runtime project new owners off these fields.

If a daemon-backed coordination command fails, debug the command/runtime/schema
edge directly — don't fall back to stale pre-upgrade assumptions.

© mvschwarz · Apache-2.0 · mvschwarz/openrig

Похожие скиллы

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →
setup-matt-pocock-skills Matt Pocock Скилл настраивает репозиторий для инженерных скиллов Matt Pocock: задаёт трекер задач, метки триажа и расположение доменной документации. Запустите его перед первым использованием остальных скиллов. 1 052 851установок ask-matt Matt Pocock Помогает выбрать подходящий скилл или рабочий поток из набора Matt Pocock. Пригодится, когда непонятно, с чего начать задачу: от идеи до разбора бага. 766 587установок to-tickets Matt Pocock Разбивает план, спецификацию или переписку на небольшие сквозные задачи и отмечает, какие из них блокируют остальные. Пригодится, когда нужно согласовать порядок работы до публикации задач в трекере. 711 230установок writing-plans Jesse Vincent Скилл превращает требования к многошаговой задаче в подробный план реализации до начала работы с кодом. Пригодится, когда исполнителю нужно зафиксировать файлы, интерфейсы и проверки. CX Codex 282 859установок caveman-review JuliusBrussee Пишет замечания к коду одной строкой: место, проблема, исправление. Пригодится, когда ревью диффа или PR надо пройти быстро и без воды. CX Codex +1 411 800установок caveman-compress JuliusBrussee Сжимает CLAUDE.md, списки задач и другие текстовые файлы в краткий формат, сохраняя читаемую резервную копию. CX Codex +1 411 500установок

Из того же набора49

session-compaction-and-restore Скилл для тех, кто думает, что переживёт компакцию, рестарт и смену места: помогает не потерять рабочий контекст и намерение задачи. CX Codex +1 ★ 8 227звёзд репо seat-continuity-and-handover Скилл помогает передавать роль агента новому исполнителю в OpenRig без потери контекста и подмены адреса места. Пригодится при перезапуске, форке или плановой ротации субагентов. CX Codex +1 ★ 8 227звёзд репо retiring-and-inheriting-a-seat Скилл передаёт планируемое место от агента, чей контекст близок к порогу, свежему преемнику. Он сохраняет пакет handover и историю места. CX Codex +1 ★ 8 227звёзд репо refocusing Скилл для длинных сессий: заново привязывает агента к текущей цели и контексту, не теряя наработанное. CX Codex +1 ★ 8 227звёзд репо orienting-to-an-inherited-seat Скилл помогает агенту освоиться в существующей рабочей позиции после плановой передачи от другого агента. Он объясняет, что принять от предшественника, а что проверить самостоятельно. CX Codex +1 ★ 8 227звёзд репо openrig-user Скилл-справочник по CLI rig: подсказывает точный синтаксис команд, форму JSON, значения по умолчанию и смысл ошибок, когда команда уже известна. CX Codex +1 ★ 8 227звёзд репо openrig-operating-model Организует контекст агентов по двум иерархиям OpenRig. Помогает понять, куда записать выводы и как проследить правила от рабочего места до флота. CX Codex +1 ★ 8 227звёзд репо mission-slice-sop Помогает агенту вести миссию или срез от постановки задачи до проверки и передачи следующему участнику. Пригодится в проектах, где работу фиксируют в файлах OpenRig. CX Codex +1 ★ 8 227звёзд репо

Спонсоры проекта

Компании, которые помогают держать аналитику открытой