@ctliz/agent-intercom-claude 0.15.0 → 0.15.1

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-intercom",
-  "version": "0.15.0",
+  "version": "0.15.1",
   "description": "Claude Code MCP plugin and wakeable worker for local Pi/Codex/Claude intercom messaging.",
   "author": {
     "name": "ctliz",

package/CHANGELOG.md

@@ -1,6 +1,8 @@
 # Changelog
 
-## Unreleased
+## 0.15.1 - 2026-10-04
+
+- Add shortest-path MCP instructions and align the Claude skill: send directly to known recipients; discover peers, diagnose connections, publish summaries, and poll inboxes only when needed. Keep team approval, reply threading, and natural-boundary inbound checks unchanged.
 
 ## 0.15.0 - 2026-10-02
 

package/claude/mcp-protocol.ts

@@ -270,7 +270,7 @@ export async function handleMcpRequest(request: JsonRpcRequest, runtime: ClaudeI
         protocolVersion: "2025-06-18",
         capabilities: { tools: {} },
         instructions: TASK_TEAM_GUIDANCE,
-        serverInfo: { name: "claude-intercom", version: "0.15.0" },
+        serverInfo: { name: "claude-intercom", version: "0.15.1" },
       });
     case "ping":
       return ok(request.id, {});

package/claude/team-guidance.ts

@@ -1,4 +1,10 @@
-export const TASK_TEAM_GUIDANCE = `Intercom task-team rules:
+export const TASK_TEAM_GUIDANCE = `Intercom shortest calling path:
+- For a known recipient, call intercom_send directly. Do not run intercom_whoami, intercom_team, intercom_list, or intercom_status as routine preflight checks.
+- Discover peers only when the target is unknown, missing, or ambiguous: intercom_team for managed or approved teammates, otherwise intercom_list. Use intercom_status only for connection errors; intercom_set_summary only for role discovery or meaningful status changes.
+- If the host requires tool discovery, discover only the selected tool and reuse its definition while it remains in context. Do not browse tool-definition directories or read unrelated definitions.
+- A standalone successful send needs no extra identity/status/pending checks or resending. Delivery is not task completion; diagnose uncertain delivery before retrying. Check intercom_pending at natural work boundaries when expecting a response or handling inbound messages, never in a tight loop.
+
+Intercom task-team rules:
 - When the user delegates to named peers and this task has no approved team, ask once whether to form a team with you and those peers. Wait for approval before creating a team or adding peers. An explicit create/join request is approval; never ask again for an approved task or inbound team message.
 - After approval, discover the connected peers, then intercom_join({ name: "launch", create: true, members: ["front", "writer"], work: "Current task" }) adds everyone in one call. Do not ask the user to join each terminal manually.
 - Membership is additive: joining another team preserves previous teams. Reuse the approved team for the same task; a different task may need a different team.

package/dist/claude-server.mjs

@@ -2953,7 +2953,13 @@ ${pendingAsks.map((entry) => {
 };
 
 // claude/team-guidance.ts
-var TASK_TEAM_GUIDANCE = `Intercom task-team rules:
+var TASK_TEAM_GUIDANCE = `Intercom shortest calling path:
+- For a known recipient, call intercom_send directly. Do not run intercom_whoami, intercom_team, intercom_list, or intercom_status as routine preflight checks.
+- Discover peers only when the target is unknown, missing, or ambiguous: intercom_team for managed or approved teammates, otherwise intercom_list. Use intercom_status only for connection errors; intercom_set_summary only for role discovery or meaningful status changes.
+- If the host requires tool discovery, discover only the selected tool and reuse its definition while it remains in context. Do not browse tool-definition directories or read unrelated definitions.
+- A standalone successful send needs no extra identity/status/pending checks or resending. Delivery is not task completion; diagnose uncertain delivery before retrying. Check intercom_pending at natural work boundaries when expecting a response or handling inbound messages, never in a tight loop.
+
+Intercom task-team rules:
 - When the user delegates to named peers and this task has no approved team, ask once whether to form a team with you and those peers. Wait for approval before creating a team or adding peers. An explicit create/join request is approval; never ask again for an approved task or inbound team message.
 - After approval, discover the connected peers, then intercom_join({ name: "launch", create: true, members: ["front", "writer"], work: "Current task" }) adds everyone in one call. Do not ask the user to join each terminal manually.
 - Membership is additive: joining another team preserves previous teams. Reuse the approved team for the same task; a different task may need a different team.
@@ -3191,7 +3197,7 @@ async function handleMcpRequest(request, runtime) {
         protocolVersion: "2025-06-18",
         capabilities: { tools: {} },
         instructions: TASK_TEAM_GUIDANCE,
-        serverInfo: { name: "claude-intercom", version: "0.15.0" }
+        serverInfo: { name: "claude-intercom", version: "0.15.1" }
       });
     case "ping":
       return ok(request.id, {});

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ctliz/agent-intercom-claude",
-  "version": "0.15.0",
+  "version": "0.15.1",
   "description": "Claude Code MCP plugin and wakeable worker for local messaging with Pi, Codex, OpenCode, Grok Build, and AGY agents.",
   "license": "AGPL-3.0-or-later",
   "type": "module",

package/skills/claude-intercom/SKILL.md

@@ -41,12 +41,12 @@ proxy-backed Claude profiles; `ccim` safe mode intentionally does not.
 
 ## Workflow
 
-1. Call `intercom_status` or `intercom_whoami` to confirm this session is connected.
-2. Call `intercom_set_summary` with a concise status so peers can discover your role.
+1. For a known recipient, call `intercom_send` directly. Do not run `intercom_whoami`, `intercom_team`, `intercom_list`, or `intercom_status` as routine preflight checks. If the host requires tool discovery, discover only the selected tool and reuse its definition while it remains in context.
+2. Discover peers only when the recipient is unknown, missing, or ambiguous: use `intercom_team` for managed or approved teammates, otherwise `intercom_list`. Check `intercom_status` only for connection errors. Use `intercom_set_summary` only when peers need to discover your role or a meaningful status change.
 3. When the user delegates to named peers and this task has no approved team, ask once whether to form a team with you and those peers. Wait for approval. An explicit create/join request is approval; never ask again for an approved task or inbound team message. After approval, discover peers and call `intercom_join({ name: "billing", create: true, members: ["front", "writer"], work: "Current task" })`. Do not ask the user to join each terminal manually. Reuse the approved team for the same task; new tasks may need new teams. Joining preserves all previous memberships and each team's manager/member roles.
 4. Use `intercom_send` for non-blocking updates and handoffs. Include `team` for task messages, especially when multiple teams are shared. Without a shared team, omit `team` for initial ungrouped contact; unrelated memberships do not block contact or silently create teams.
 5. Use `intercom_ask` only when you need the answer before continuing. Assignments, progress/status checkpoints, notifications, and completion reports use `intercom_send`.
-6. Call `intercom_pending` before ending a coordination turn, then answer blocking asks with `intercom_reply`.
+6. Check `intercom_pending` at natural work boundaries when expecting a response or handling inbound messages, then reply with the original selectors and team. A standalone successful send does not require a pending/identity/status check or a resend. Delivery is not task completion; diagnose uncertain delivery before retrying, and never poll in a tight loop.
 
 ## Patterns