Menu
Send a request and wait for the response on a channel pair
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Collaboratively refine a high-level ambition into a set of chunk prompts.
Migrate the project's ACTIVE chunks to the present-tense, intent-owning standard. Audits each chunk's goal against the code it claims to govern; rewrites retrospective framing inline; logs over-claims that need operator triage; historicalizes chunks with no enduring intent. Designed for full-corpus migrations — fans out across many parallel sub-agents at 5 chunks per agent.
Create a new chunk of work and refine its goal. Use when the operator wants to start new intent-bearing work, chunk something, define a piece of work, or break work into a chunk.
Update code references in the current chunk and move both the PLAN.md and the GOAL.md to the ACTIVE state.
Wake an entity by loading its identity, memories, and operational context
Set up a project steward via interactive interview
Based on SOC occupation classification
| name | swarm-request-response |
| description | Send a request and wait for the response on a channel pair |
Send a request to one channel and wait for the response on another. This encapsulates the request-response pattern over swarm channel pairs — advancing the response channel cursor to head, starting a background watch before sending the request (to prevent races), and filtering broadcast responses for relevance.
The most common channel pair is <project>-steward (request) /
<project>-changelog (response), but any two channels work.
$ARGUMENTS
Extract from the arguments:
myproject-steward)myproject-changelog)Project name shorthand: If the operator provides a project name instead of
explicit channels, derive the channel pair using the standard convention:
<project>-steward (request) and <project>-changelog (response).
If any required argument (request channel, response channel, message body) is missing, ask the operator and stop.
Query current channel state:
ve board channels [--swarm <swarm_id>] [--server <url>]
Output format: Each line is <name> head=<N> oldest=<N>.
Parse the head=<N> value for the response channel. This is the offset we'll
use to start the watch — it skips all historical messages so we only see
responses that arrive after we start.
If the response channel doesn't exist yet in the output, warn the operator and proceed with offset 0. The steward may create it on first response.
Start the watch before sending the request. This prevents the race condition where the steward responds before we're listening:
ve board watch <response_channel> --offset <head_position> --swarm <swarm_id> [--server <url>]
Run with run_in_background. The --offset flag starts from the head
position (ephemeral — does not modify the persisted cursor). Record the task
ID for later use.
Watch safety: There must be only one watch per channel. If a previous
watch on the response channel is still running from an earlier invocation,
TaskStop it first. The CLI's PID-based kill provides a safety net, but
explicit task lifecycle management is preferred.
Now that the watch is active, send the request:
ve board send <request_channel> "<message>" --swarm <swarm_id> [--server <url>]
Report the assigned position to the operator.
When the background watch returns a message, determine if it's actually a response to this specific request. The response channel is a broadcast channel — it may contain notifications from other requests or unrelated activity.
Filtering heuristic — use your judgment to assess relevance. Signals include:
If the message is NOT relevant:
ve board ack <response_channel>
--offset is needed now):
ve board watch <response_channel> --swarm <swarm_id> [--server <url>]
run_in_background. Record the new task ID.If the message IS relevant:
ve board ack <response_channel>
Watch timeout: If the background watch exits with code 144 (Claude Code
task timeout), the steward may not have responded yet. TaskStop the timed-out
task, then re-launch the watch (without --offset — use the persisted cursor
position, since no acks have changed it):
ve board watch <response_channel> --swarm <swarm_id> [--server <url>]
Run with run_in_background and continue waiting.
Why watch-before-send matters — if you send the request first, the
steward might respond before the watch starts, and the response is missed.
Starting the watch first ensures no responses are lost. The small window
between querying ve board channels and starting the watch is safe — any
message arriving in that window predates our request and will be correctly
filtered out as irrelevant.
--offset vs persisted cursor — the --offset flag is ephemeral and
used only for the initial watch to skip historical messages. After acking
irrelevant messages, subsequent re-watches use the persisted cursor
naturally (no --offset needed).
Channel pair convention — <project>-steward (request) /
<project>-changelog (response) is the standard pair, but any two channels
can form a request-response pair.
Broadcast channel filtering — the response channel is shared. Not every message on it is a response to your request. Use the filtering heuristic to distinguish relevant responses from unrelated activity.
Manual cursor management — this skill uses ve board ack explicitly
(like /steward-watch), not auto-advancing cursors (like /swarm-monitor).
Ack only after you've determined whether the message is relevant or not.