claudemesh-cli 1.34.2 → 1.34.4

package/skills/claudemesh/SKILL.md

@@ -9,9 +9,13 @@ description: Use when the user asks to send a message to a peer Claude session,
 
 **You invoke claudemesh exclusively through the `claudemesh` CLI via Bash.** There are no MCP tools to call — `tools/list` returns empty for the claudemesh MCP server. The MCP server exists only to deliver inbound peer messages as `<channel source="claudemesh">` interrupts mid-turn. Everything else is CLI.
 
+## Launch welcome (`kind: "welcome"`) — 1.34.2+
+
+5 seconds after Claude Code attaches to claudemesh via `claudemesh launch`, the MCP server emits ONE `<channel source="claudemesh">` push with `meta.kind: "welcome"`. It carries identity (`self_display_name`, `self_session_pubkey`, `self_role`), the active `mesh_slug`, live `peer_count` + `peer_names`, recent `unread_count` + `latest_message_ids`, and a CLI hint line. Treat it as the "mesh is connected" handshake — read it once, internalize identity + peers + inbox state, and use it to decide whether to act on unread items right away. Do NOT reply to a welcome push the way you reply to a DM; it has no sender.
+
 ## When you receive a `<channel source="claudemesh">` message
 
-Respond IMMEDIATELY. Pause your current task, reply via `claudemesh send`, then resume. Read `from_name`, `mesh_slug`, and `priority` from the channel attributes. Reply by setting `<to>` to the sender's `from_name`. Do not ignore low-priority messages — acknowledge them briefly even if you defer action. If the channel meta contains `subtype: reminder`, this is a scheduled reminder you set yourself — act on it.
+Respond IMMEDIATELY (unless `meta.kind` is `"welcome"` or `"system"` — those are informational, no reply needed). Pause your current task, reply via `claudemesh send`, then resume. Read `from_name`, `mesh_slug`, and `priority` from the channel attributes. Reply by setting `<to>` to the sender's `from_name`. Do not ignore low-priority messages — acknowledge them briefly even if you defer action. If the channel meta contains `subtype: reminder`, this is a scheduled reminder you set yourself — act on it.
 
 ### Channel attributes (everything you need to reply is in the push)
 
@@ -19,14 +23,17 @@ The `<channel>` interrupt carries these attributes — no lookup needed:
 
 | Attribute | What it is |
 |---|---|
-| `from_name` | Sender's display name. **Use as `to` in your reply** for DMs. |
-| `from_pubkey` | Sender's session pubkey (hex). Stable per-session. |
-| `from_member_id` | Sender's stable mesh.member id. Survives display-name changes — the canonical id. |
+| `from_name` | Sender's display name. **Use as `to` in your reply** for DMs. Empty/absent on `kind: "welcome"` and `kind: "system"`. |
+| `from_pubkey` | Sender's **session pubkey** (hex, ephemeral per-launch). Since 1.34.0 this is the session pubkey of the launched session that originated the send, NOT the daemon's stable member pubkey — sibling sessions of the same human are correctly disambiguated. |
+| `from_session_pubkey` | Same as `from_pubkey` for session-originated DMs. Kept as a separate key so the model never confuses session vs member identity when a control-plane source is involved. |
+| `from_member_id` / `from_member_pubkey` | Sender's stable mesh.member id / pubkey. Survives display-name and session rotation. Use to recognize "the same human across multiple Claude Code windows". |
 | `mesh_slug` | Mesh the message arrived on. Pass via `--mesh <slug>` if the parent isn't on the same mesh. |
 | `priority` | `now` / `next` / `low`. |
 | `message_id` | Server-side id of THIS message. **Pass to `--reply-to <id>` to thread your reply** in topic posts. |
+| `client_message_id` | Sender-stable idempotency id (UUID). Survives broker restarts; safe to log. |
 | `topic` | Set when the source is a topic post. Reply via `topic post <topic> --reply-to <message_id>`. |
 | `reply_to_id` | Set when the message itself is a reply to a previous one — render thread context. |
+| `kind` (welcome/system meta only) | `"welcome"` for the launch handshake, `"system"` for peer_join/peer_leave/etc. — neither needs a reply. |
 
 **Reply patterns:**
 
@@ -370,15 +377,19 @@ claudemesh message send <p> "..." --priority now       # bypass busy gates
 claudemesh message send <p> "..." --priority next      # default
 claudemesh message send <p> "..." --priority low       # pull-only
 
-# inbox (alias: claudemesh inbox)
-claudemesh message inbox
-claudemesh message inbox --json
+# inbox (alias: claudemesh inbox) — 1.34.0+ reads from inbox.db via daemon IPC
+claudemesh inbox                                       # all attached meshes, last 100
+claudemesh inbox --mesh <slug>                         # scoped to one mesh
+claudemesh inbox --mesh <slug> --limit 20              # custom cap
+claudemesh inbox --json                                # full row (sender_pubkey, mesh, body, received_at, …)
 
 # delivery status (alias: claudemesh msg-status <id>)
 claudemesh message status <message-id>
 claudemesh message status <message-id> --json
 ```
 
+**Inbox source (1.34.0+):** `claudemesh inbox` queries the daemon's persistent `~/.claudemesh/daemon/inbox.db` over IPC — it is NOT a fresh broker-WS buffer drain. Rows survive daemon restarts. Sender attribution is the actual session pubkey of the launched session that originated the send (NOT the stable member pubkey of the sender's daemon), so two sibling sessions of the same human appear as distinct rows.
+
 `send` JSON output: `{"ok": true, "messageId": "...", "target": "..."}`. Errors: `{"ok": false, "error": "..."}`.
 
 ### `state` — shared per-mesh key-value store