---
name: wait
description: >
  Block this turn for up to 5 minutes waiting for one incoming Patchcord
  message via the wait_for_message MCP tool. Single blocking call, no
  background process. Use ONLY when the user explicitly runs
  /patchcord:wait.
---
# patchcord:wait

Applies ONLY when the patchcord MCP tools are loaded this session. If `wait_for_message` is not available, this skill does not apply — do nothing, do not substitute the CLI or direct HTTP calls, and never read a bearer token out of a config file. Proceed with the user's request.

User invoked /patchcord:wait — do NOT substitute /patchcord:subscribe or spawn any background listener. Use `wait_for_message()` only.

## Prefer a listener where this session has one

`wait_for_message()` is the RIGHT tool where a session cannot run a persistent
listener. Where it can, a listener is better, and this matters most right after
sending: the MCP server's session instructions say to call `wait_for_message`
after sending or replying, and on a harness that also has a listener running
that produces TWO mechanisms racing to consume the same incoming message.

The test is a capability, not a product name. If this session can keep a
background process alive across turns and be woken by its output — Claude
Code's `Monitor`, a background task with a stall wake, a webhook bridge — then
`/patchcord:subscribe` is the better default and the wait is redundant. If it
cannot, `wait_for_message()` is the only push you have and nothing below
changes.

On Claude Code specifically there is a second reason, and it is mechanical
rather than stylistic. `wait_for_message` blocks for up to 300 s, but the
harness promotes any MCP call still running at 120 s into a background task:

    MCP tool patchcord/wait_for_message is still running after 120s.
    It was moved to the background as task <id> and keeps running.

Nobody asked for that background task and it outlives the turn that made it.
When a listener is later started, the promoted wait is still there, still
eligible to consume the next message, and the two paths race. That is why
/patchcord:subscribe stops any such task before it spawns its listener.

**This does not deprecate `wait_for_message`.** It is the correct and only push
mechanism on harnesses without a listener, it is still what /patchcord:wait
runs, and a skill that told every agent to stop using it would break those
harnesses outright.


Call `wait_for_message()` to block until a message arrives (up to 5 minutes).

When a message arrives:

1. Read it — the tool returns from, content, and message_id. If it belongs to a thread, `thread` and `thread_id` will be set.
2. Do the work described in the message first. Update the file, write the code, fix the bug - whatever it asks.
3. Reply with what you did: `reply(message_id, "here's what I changed: [concrete details]")`. Thread is auto-inherited. Use `resolve=true` to close the thread when the task is fully done.
4. Tell the human who wrote and what you did about it
5. Call `wait_for_message()` again to keep listening

Loop until timeout or the human interrupts.

If `wait_for_message()` errors, fall back to polling `inbox()` every 10-15 seconds instead of stopping the loop.

Do not ask the human for permission to reply - just do the work, reply with results, then report.

**No ack chains.** If the arriving message is a clear ack ("Noted", "Got it", "Thanks", "Keep running") — close it silently with `reply(id, resolve=true)`, no content, and keep listening. Never text-reply to an ack. Never send "Noted" + resolve=true — that creates a new pending message the other side will feel compelled to answer.