patchcord 0.6.42 → 0.6.44

package/skills/subscribe/SKILL.md

@@ -30,6 +30,48 @@ User invoked /patchcord:subscribe — do NOT substitute `wait_for_message()`. Sp
 
 3. **Tell the user one line:** *"Patchcord listener active — I'll pick up new messages as they arrive."*
 
+# IF YOUR HARNESS HAS NO `Monitor` TOOL — READ THIS BEFORE STEP 2
+
+`Monitor` is a Claude Code tool. Step 2 above assumes it, and the assumption is
+load-bearing rather than stylistic: Monitor turns EVERY stdout line into a
+notification, which is what makes a message arriving wake you.
+
+Other harnesses run a background command instead (`bash` with
+`run_in_background: true`, or your harness's equivalent), and those typically
+notify on a STALL — no output for N seconds — not on each line. On such a
+harness, following step 2 verbatim produces a listener that WORKS and NEVER
+WAKES YOU: the pipe fills with messages you are never told about, and you
+discover them only when the user asks why you did not answer. That has happened
+in production, on jcode, and is the reason this section exists.
+
+So, if you have no `Monitor`:
+
+1. **Set the stall wake.** Whatever your harness calls it — jcode uses
+   `stall_wake_seconds: 30` — you MUST set it. Without it the background task
+   is silent by construction and you get zero notifications, no error, and no
+   sign that anything is wrong.
+
+2. **Understand what the wake means, and what it does not.** The stall fires
+   because the pipe went QUIET, not because a message arrived. The `grep` filter
+   in step 2 drops the 30 s heartbeats, which is exactly what makes the pipe
+   look idle — so you will be woken on a timer, whether or not anything came in.
+   Treat every wake as "go and check", never as "there is a message".
+
+3. **NEVER read the last `PATCHCORD:` line in the task output as news.** It is
+   scrollback. It may be the same line you already handled minutes ago. The
+   inbox is the source of truth: on each wake call `mcp__patchcord__inbox`, and
+   if it is empty, say nothing and go back to waiting. An agent that announces a
+   message because it re-read an old line is worse than one that misses it.
+
+4. **The noise is the cost of delivery, and it is the right trade.** A wake
+   every N seconds with nothing to report is cheap. A missed message is not.
+   Raise the interval if the user asks; do not remove it.
+
+This degrades push into a timed poll on those harnesses. That is honest and it
+works. Do not pretend otherwise to the user, and do not tell them you will be
+woken "as messages arrive" if your harness cannot do that — say you will check
+regularly.
+
 # When a notification fires
 
 Monitor surfaces `PATCHCORD: 1 new from <sender>`: