patchcord 0.5.114 → 0.5.115

package/bin/patchcord.mjs

@@ -1628,6 +1628,27 @@ if (!cmd || cmd === "install" || cmd === "agent" || cmd?.startsWith("--")) {
     }
   }
 
+  // Hermes — refresh patchcord skills to the current version on every run, so
+  // skill fixes land via `patchcord update` (the interactive choice 13 only
+  // installs them once). ~/.hermes/skills is Hermes-only, so no leak risk; only
+  // refresh when the integrations dir already exists (Hermes was set up before).
+  {
+    const hermesSkillsSrc = join(pluginRoot, "per-project-skills", "hermes");
+    const hermesSkillsDest = join(HOME, ".hermes", "skills", "integrations");
+    if (existsSync(hermesSkillsDest) && existsSync(hermesSkillsSrc)) {
+      let hermesChanged = false;
+      for (const name of readdirSync(hermesSkillsSrc)) {
+        const src = join(hermesSkillsSrc, name, "SKILL.md");
+        if (!existsSync(src)) continue;
+        const dest = join(hermesSkillsDest, name, "SKILL.md");
+        const want = readFileSync(src, "utf-8");
+        let cur = ""; try { cur = readFileSync(dest, "utf-8"); } catch {}
+        if (cur !== want) { mkdirSync(dirname(dest), { recursive: true }); writeFileSync(dest, want); hermesChanged = true; }
+      }
+      if (hermesChanged) globalChanges.push("Hermes patchcord skills refreshed");
+    }
+  }
+
   // Kimi CLI
   const hasKimi = run("which kimi");
   if (hasKimi) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.5.114",
+  "version": "0.5.115",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": "ppravdin",
   "license": "MIT",

package/per-project-skills/hermes/patchcord-inbox/SKILL.md

@@ -9,6 +9,8 @@ metadata:
 ---
 # Patchcord — inbox
 
+Applies only when the patchcord MCP tools (`mcp_patchcord_*`) are available this session. If they are not, do nothing — do not run the CLI as a substitute, do not read a bearer token from a config file, do not call the API directly, and do not web-search for setup. Just proceed with the user's request.
+
 ## When to use
 The user mentions patchcord / other agents / checking messages, or a Patchcord webhook fired ("new Patchcord messages").
 

package/per-project-skills/hermes/patchcord-subscribe/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: patchcord-subscribe
-description: Set up real-time Patchcord delivery so new messages wake this agent automatically via the gateway webhook bridge.
-version: 1.0.0
+description: Real-time Patchcord delivery options for Hermes. Hermes has no in-session listener, so this starts nothing in-turn — it drains the inbox and tells the human the optional one-time push setup.
+version: 2.0.0
 platforms: [macos, linux]
 metadata:
   hermes:
@@ -10,21 +10,19 @@ metadata:
 ---
 # Patchcord — subscribe (real-time)
 
-Hermes has no per-turn background-listener tool. Real-time delivery uses the
-gateway webhook plus the patchcord bridge: the bridge holds one realtime
-connection and POSTs to a Hermes webhook on each new message, and the always-on
-gateway injects a prompt that wakes the agent. No re-arm.
+Applies only when the patchcord MCP tools (`mcp_patchcord_*`) are available this session. If they are not, do nothing — do not run the CLI, do not read tokens from config files, do not call the API directly.
 
-## One-time setup
-1. Register a webhook route on the gateway:
-   `hermes webhook subscribe patchcord --prompt "You have new Patchcord messages. Run /patchcord-inbox now."`
-   Note the route URL it prints (e.g. `https://<gateway-host>/webhooks/patchcord`).
-2. Start the bridge under the gateway/tmux/systemd:
-   `PATCHCORD_HERMES_WEBHOOK=<route-url> patchcord subscribe --hermes`
-   It self-reconnects and survives JWT cycles — leave it running.
+**Hermes has no per-turn background-listener tool. There is nothing to start in this turn.** Do NOT web-search, do NOT fetch docs, do NOT guess or invent `hermes ...` commands.
 
-## When the webhook fires
-The gateway injects the prompt → run the **patchcord-inbox** skill: read inbox, reply to each message, report to the user.
+When invoked, do exactly this and stop:
+1. Run the **patchcord-inbox** skill now (drain anything pending).
+2. Tell the human: "Hermes can't hold a live listener — I'll check the inbox at the start of each session. For push delivery there's a one-time bridge the human sets up; want the steps?"
+3. Do not configure anything yourself.
 
-## No webhook available
-Fall back to polling: `hermes cron create` a job that runs `/patchcord-inbox` every few minutes.
+## One-time push setup (the HUMAN runs this, only if they ask)
+Real-time needs the patchcord bridge holding one realtime connection and POSTing to a Hermes webhook the human controls. Hand these to the human — never run them or invent command names yourself:
+- In Hermes, create a webhook route that, when it fires, injects the prompt: `You have new Patchcord messages. Run /patchcord-inbox now.` (Use whatever the installed Hermes version calls this — the human knows their CLI.)
+- Start the bridge pointed at that route URL and leave it running:
+  `PATCHCORD_HERMES_WEBHOOK=<route-url> patchcord subscribe --hermes`
+
+Once the bridge runs, each new message fires the webhook → the gateway wakes the agent → run **patchcord-inbox**. If the human doesn't want the bridge, checking inbox at session start is the whole feature — that's fine.

package/per-project-skills/hermes/patchcord-wait/SKILL.md

@@ -9,6 +9,8 @@ metadata:
 ---
 # Patchcord — wait
 
+Applies only when the patchcord MCP tools (`mcp_patchcord_*`) are available this session. If they are not, do nothing — do not run the CLI, read tokens from config files, call the API directly, or web-search for setup. Proceed with the user's request.
+
 ## When to use
 You sent a message and expect a reply, or the user asks you to wait for an incoming Patchcord message.