Use when work should be added to, inspected in, reprioritized within, or otherwise managed through the explicit CTOX queue that feeds the normal inbound routing path.
Use this skill when Codex should work with durable queued tasks instead of keeping a hidden todo list.
The queue is explicit shared state. If you want future work to survive beyond the current turn, use ctox queue ....
Do not assume an external wrapper will decide the next task for you.
ctox queue list [--status "<status>"]... [--limit "<n>"]
ctox queue show --message-key "<message_key>"
Use this before reordering or adding follow-up work when the current queue state matters.
ctox queue add --title "<short label>" --prompt "<full task prompt>" [--thread-key "<thread>"] [--skill "<skill>"] [--priority "<urgent|high|normal|low>"] [--parent-message-key "<message_key>"]
Behavior:
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>"
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>"]
ctox queue add.ctox plan draft and then enqueue only the concrete slices that should really execute.--parent-message-key when a follow-up task clearly descends from an earlier queue item.Read references/queue-contracts.md before using this skill for real work.