Queue Orchestrator

Behavior:

• Creates a visible inbound queue task.
• The queue task enters the same routing substrate used by other inbound work.
• Nothing is hidden from Codex; later service execution leases the same queue item.

Edit Or Reprioritize An Existing Queue Task

ctox queue edit --message-key "<message_key>" [--title "<label>"] [--prompt "<text>"] [--thread-key "<thread>"] [--skill "<skill>"] [--clear-skill] [--priority "<urgent|high|normal|low>"]
ctox queue reprioritize --message-key "<message_key>" --priority "<urgent|high|normal|low>"

Mark Queue Outcome

ctox queue block --message-key "<message_key>" --reason "<why>"
ctox queue release --message-key "<message_key>" [--priority "<urgent|high|normal|low>"] [--note "<text>"] [--clear-note]
ctox queue fail --message-key "<message_key>" --reason "<why>"
ctox queue complete --message-key "<message_key>" [--note "<text>"]
ctox queue cancel --message-key "<message_key>" [--reason "<why>"]

Operating Pattern

1. Read the queue if ordering or existing work matters.
2. Add follow-up work explicitly with ctox queue add.
3. If a task should be decomposed first, use ctox plan draft and then enqueue only the concrete slices that should really execute.
4. Prefer one coherent queue task per execution slice.
5. Use --parent-message-key when a follow-up task clearly descends from an earlier queue item.

Important Boundaries

• The queue tool changes explicit queue state only.
• It does not replace the Codex execution loop.
• It does not inject hidden planning logic.
• It does not send owner communication itself.

Do Not

• Do not create speculative queue tasks for work that is not actually needed.
• Do not leave blockers only in prose if the queue item should stop moving.
• Do not assume leased work is invisible; it is still the same queue item moving through the normal inbound path.

Contracts

Read references/queue-contracts.md before using this skill for real work.