codex-channels

name	codex-channels
description	[CODEX-CHANNELS] Set up or operate the local codex-channels runtime for Codex-first interaction routing.

codex-channels

Use this skill when you want to:

• bootstrap the local Codex integration for this machine or workspace
• run the local runtime health/demo flow
• inspect pending interactions without remembering every CLI flag
• reply to the newest interaction with less shell ceremony
• explain how the local runtime fits into Codex workflows

Execution-first rule

When the user invokes this skill with an obvious subcommand intent, run the matching codex-channels command first instead of only explaining it.

Examples:

• $codex-channels doctor -> run codex-channels doctor, then summarize the result.
• $codex-channels demo -> run codex-channels demo; if port binding needs approval, request it and continue.
• $codex-channels pending -> run codex-channels pending first.
• $codex-channels operator-status -> run the summary first and use it to choose the next step.
• $codex-channels next-step -> run the obvious next operator action when it is safe to do so.
• $codex-channels reply-latest --text ... -> run the command first, then summarize what was resolved.
• $codex-channels reply --id ... --text ... -> run the targeted reply first.

Only stay explanatory when:

• the user explicitly asks for docs or a summary
• a command would be destructive or materially ambiguous
• missing arguments prevent a safe execution-first interpretation

Fastest shortcuts

If you want dedicated shortcut skills instead of subcommands, use:

• $operator-status
• $next-step
• $channels-doctor
• $channels-demo
• $channels-pending
• $channels-reply-latest
• $channels-watch
• $channels-follow

Codex operator mode

When invoked from inside Codex, prefer doing the next operator step over only restating documentation.

Default workflow:

• If the user asks "what should I do next?", run codex-channels operator-status first and summarize the next action.
• If the user asks to keep an eye on the queue, run codex-channels watch so changes are surfaced only when the state actually changes.
• If the user asks whether the runtime is ready, run codex-channels doctor and summarize the result.
• If the user asks what is waiting, run codex-channels pending first and fall back to inspect only when deeper detail is needed.
• If the user asks to test the loop, use codex-channels demo and then point them toward pending and reply-latest.
• If the user asks to answer the newest request, prefer codex-channels reply-latest --text ... over making them copy an interaction id manually.
• If a step needs a local port bind, explain that approval/escalation is expected for the real runtime path.

Fastest operator check

For a single run-ready summary, prefer:

codex-channels operator-status

For the next obvious action, prefer:

codex-channels next-step

For low-noise monitoring that can also resolve the next request when text is provided, use:

codex-channels follow --text staging

For low-noise monitoring, prefer:

codex-channels watch

Guided operator flow

1. Install / expose the skill

codex-channels plugin-bootstrap

2. Check the current state

codex-channels operator-status
codex-channels watch
codex-channels next-step
codex-channels doctor
codex-channels pending

3. Generate a real interaction

codex-channels demo

4. Inspect what is waiting

codex-channels pending
codex-channels inspect

5. Reply

codex-channels reply-latest --text staging
# or
codex-channels reply --id <interaction-id> --text staging

Common commands

codex-channels plugin-bootstrap
codex-channels operator-status
codex-channels watch
codex-channels next-step
codex-channels doctor
codex-channels demo
codex-channels pending
codex-channels inspect
codex-channels reply-latest --text staging
codex-channels reply --id <interaction-id> --text staging

Additional watch guidance:

• Use watch only when you actually want background-style monitoring; default flows should stay quiet.
• Watch mode should surface changes, not spam repeated no-change summaries.
• Treat watch output as change events: runtime up/down, actionable interaction count changes, latest interaction changes, or next-step changes.
• Each change event should carry a compact next-step hint so the user can act without another full status query.

Additional follow guidance:

• Use follow --text ... when you want low-noise monitoring plus the ability to resolve the next actionable request automatically once it appears.
• If you omit --text, prefer plain watch so the command stays observation-only.

Scoped monitoring guidance:

• Use --source <name> when you only care about one producer such as codex-channels-demo.
• Use --kind <kind> when you only care about one interaction shape such as user_input_request.
• Use --focus-id <id> when you want watch/follow behavior pinned to one specific interaction.

Latest-overall guidance:

• operator-status can show a newer resolved interaction separately from the latest actionable one, which helps explain why the queue changed even if the newest actionable request is older.