Queue handoff skill

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.

by mvschwarz·Apache-2.0 license·★ 4,707 Stars on the repo·GitHub ↗

Use now

Files of Queue handoff

mvschwarz/main1 file shown
SKILL.md
Show the full text174 lines

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. Park the qitem with closure_reason: blocked_on and the blocker qitem id.
  • 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)
  • blocked_on — parked pending another qitem (target = blocker qitem id)
  • 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)

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

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.

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.

1---
2name: queue-handoff
3description: 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.
4metadata:
5 cli_surfaces_referenced:
6 - queue
7 - queue create
8 - queue handoff
9 - queue handoff-and-complete
10 openrig:
11 stage: factory-approved
12 sibling_skills:
13 - watchdog
14 - refocusing
15 - human-in-the-loop
16---
17 
18# Queue Handoff
19 
20Durable work handoff via queue items. Lets the system keep moving
21through compactions, missed messages, and interruptions by passing the
22ball forward instead of leaving work suspended in chat or in-flight
23without an owner.
24 
25## Use this when
26 
27- **Ending a turn on substantive work.** Active work should end by
28 passing the ball to an owner or to the human — never by going idle
29 with the rig appearing dormant.
30- **Finishing a slice that has a clear next step.** Default-nudge:
31 receiver gets a wake-ping plus the durable queue item.
32- **Blocked on another agent's work.** Park the qitem with
33 `closure_reason: blocked_on` and the blocker qitem id.
34- **Escalating to the human.** Make the escalation a durable attention
35 item, not just a chat message.
36 
37## Don't use this when
38 
39- The work is genuinely complete and there's no follow-on owner. Use
40 `closure_reason: no-follow-on` (terminal completion) or
41 `canceled`/`denied` as appropriate.
42- The handoff would be too small and turn work into bureaucracy. Bundle
43 the work into a coherent slice instead of decomposing every step.
44- The handoff would be too broad and lose ownership/proof/closure
45 criteria. Shape the qitem so the receiver knows the expected next
46 action and closure evidence.
47 
48## The hot-potato terminal-turn-rule
49 
50Active work ends by passing the ball to a named next owner or to the
51human. The qitem state machine enforces this:
52 
53`pending → in-progress → done` requires `closure_reason` from one of:
54 
55- `handed_off_to` — work continues at a different seat (target = new owner)
56- `blocked_on` — parked pending another qitem (target = blocker qitem id)
57- `denied` — receiver rejected the work
58- `canceled` — sender or receiver withdrew
59- `no-follow-on` — terminal completion, nothing else needed
60- `escalation` — kicked up to a higher tier (target = escalation target)
61 
62Three of those (`handed_off_to`, `blocked_on`, `escalation`) additionally
63require `closure_target`. The daemon enforces this at the domain layer;
64every surface (CLI, MCP, future UI) inherits the same guarantee.
65 
66**The drafted-park failure (draft ≠ throw).** The rule is about the *actual* pass, not the
67intention to pass. A turn that ends with a self-instruction **typed into your own prompt but left
68unsent** — a drafted go-ahead, a next-atom note you never sent — has **not** handed off; it has
69**parked**, and the seat sits idle for as long as nobody notices. Drafting the handoff feels like
70doing it; it isn't. **Your last act on a turn must be an EDIT or a SEND** — a committed change, a
71`rig send`, a `rig queue` handoff — **never a drafted prompt line left in the buffer.** If your
72final output is an instruction addressed to yourself, you haven't ended the turn, you've stalled it.
73 
74**The dispatcher's other half — supersession closes your own outbox.** Ending your turn cleanly is
75only half the rule; the other half fires when *you* move the world. **When a phase transition or a
76fold receipt supersedes work you dispatched, close those dispatches yourself — with a citation to the
77event that superseded them.** Closure-on-supersession belongs to the **dispatcher, never the
78receiver.** Make it a habit: after every fold receipt / phase transition, run an **outbox audit** —
79*which of my open dispatches did this just make moot?* — and close them with the citation.
80 
81*Why it must live with you:* stale dispatch-debt is **invisible to the dispatcher** because it lands
82on someone else's queue — the cost is externalized, so no feedback loop ever fires to make you clean
83it up. The receiver inherits debt they did not create and must burn cycles verifying it before they
84can hold cleanly; a queue full of stale-pending makes *check-before-holding* — the discipline you
85most want cheap — expensive, and it degrades the idle-detector's signal (a real owner looks the same
86as a stale dispatch). Close it at the source: the moment your own transition mooted it.
87 
88**And after you hand off, PULL — don't idle with a stocked queue.** Handing the baton off ends the
89*sequential* thread; it does not end *your* turn if your own queue still holds work. The circulation
90pattern: finish → (1) hand the baton off so sequential work continues → (2) **check your OWN queue and
91pull the next item** rather than going idle → (3) go truly idle only when your queue is **exhausted**,
92then wait for the baton. An agent idling on top of a stocked queue is the single biggest utilization
93leak (see `orchestration-team` → *queue depth is the orchestrator's product*). This is pull-not-push at
94the seat level and needs no new machinery — the last act *after a handoff* is a **PULL**.
95 
96## Default-nudge semantics (the syntax footgun)
97 
98| Command | Nudges by default? | When to use |
99|---|---|---|
100| `rig queue create` | yes | New qitem created from scratch |
101| `rig queue handoff` | yes | Transactional close-as-handed-off + create-new |
102| `rig queue handoff-and-complete` | yes | Atomic close + create-new; default nudge wakes the new owner |
103 
104**Footgun**: `--no-nudge` accidentally added to a live-loop handoff.
105The shipped 0.3.1 CLI nudges by default on every queue write surface
106(`rig queue create`, `rig queue handoff`, AND `rig queue handoff-and-complete`).
107The only suppression flag is `--no-nudge` — appropriate for intentional
108cold park, human-gate signal, or a deliberate poll-driven workflow, but
109NOT for live-loop handoffs where motion matters.
110 
111**Rule**: in a live loop, omit `--no-nudge` and trust the default.
112`--no-nudge` is the opt-out, not the opt-in. If you find yourself
113reaching for `--notify`, stop — that flag does not exist on the
114shipped 0.3.1 CLI; you may be following a stale instruction that
115inverted the default-nudge polarity.
116 
117## Queue-body hygiene (token + parse safety)
118 
119The qitem body is durable DATA the daemon stores and replays on every
120`rig queue show <id>` / `--json` read. Keep it small and parse-safe — a
121bloated or malformed body costs every future reader, not just the
122recipient.
123 
124- **No large command output in bodies.** Do NOT paste `rig ps`/`--nodes`
125 dumps, big JSON blobs, full proof output, diffs, or transcript chunks
126 into a qitem body. **Link the artifact PATH** (e.g.
127 `missions/<m>/<slice>/proof.md`) or **summarize in prose**, then point
128 at the file for the detail. A pasted dump makes `rig queue show <id>
129 --full --json` large. Compact defaults limit a preview, but the stored body
130 still costs readers who need full detail. Keep evidence in its durable artifact.
131- **Substantive bodies go through `--body-file`, not inline `--body`.**
132 For anything beyond a short line, write the body to a file and pass
133 `--body-file <path>` (or `-` for stdin). Inline `--body` with shell
134 metacharacters is fragile.
135- **No raw backticks in bodies.** Backticks in an inline body are shell
136 command-substitution and corrupt the payload (or execute). If you need
137 code/command spans, use `--body-file`, or drop the backticks and write
138 the command in plain text.
139 
140Heuristic: if the thing you want to include is more than a few lines or
141contains shell metacharacters (backticks, `$`, quotes, newlines-with-pipes),
142it belongs in a file you LINK, not in the body you paste.
143 
144The current `rig queue show` returns a bounded body preview by default;
145`--full` returns the complete body and chain fields. Preview truncation does
146not truncate the stored work. Check `bodyTruncated` and `bodyBytes`, then request
147full content when needed; keep large supporting evidence in linked artifacts.
148 
149## Failure modes (6; verbatim)
150 
1511. Agent ends a turn without a handoff, so the rig appears idle.
1522. 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.
1533. Queue item is too small and turns work into bureaucracy.
1544. Queue item is too broad and loses ownership, proof, or closure criteria.
1555. Human escalation happens in chat but not as a durable attention item.
1566. 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.
157 
158## Durable handoff field shape
159 
160Every qitem carries:
161 
162- `handed_off_to` — destination session (qualified `pod-member@rig` form)
163- `handed_off_from` — predecessor qitem id (the source session is `source_session`)
164- `state` — one of: `pending | in-progress | done | blocked | failed | denied | canceled | handed-off`
165- `closure_reason` + `closure_target` — set on terminal closure per hot-potato rule
166 
167**(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."
168 
169The fields are auditable on the daemon-backed `rig queue` surface. Watchdog
170policies and workflow runtime project new owners off these fields.
171 
172If a daemon-backed coordination command fails, debug the command/runtime/schema
173edge directly — don't fall back to stale pre-upgrade assumptions.
174 

Discussion

Alternatives