agenthub-multiagent-mcp 1.77.0 → 1.78.0

package/skills/manifest.json

@@ -48,13 +48,15 @@
       "hashes": [
         "b3792bb7e44a5f581172d94c5b145ef6c1420e28426f796a38594250a28f1de1",
         "aff7ed284060cd0e157c35b2572047a42144eef80d4299f3592a5caf9ef240e5",
-        "311182e620681ca4f059d07ba5df14fdf1cd6e811b11619088888f3e666df117"
+        "311182e620681ca4f059d07ba5df14fdf1cd6e811b11619088888f3e666df117",
+        "c2e8a24ca1ff07aa69977ada0d46fd10c73ddaefc2f05d9591ab57860989753c"
       ]
     },
     "skills/inbox/SKILL.md": {
       "hashes": [
         "e7cacbf45ac93de3c8b23705fd94d4f03be9f01a3970050e1c3ebf06665d04cb",
-        "bf4a56716ecf89534e790e66edcc88a01d0bc8d7e99e13c9c85119c8579fc393"
+        "bf4a56716ecf89534e790e66edcc88a01d0bc8d7e99e13c9c85119c8579fc393",
+        "1c47f954d721864ac39fb987a1ce42c230ba8b8071f4c110a07d3f85be99ea0d"
       ]
     },
     "skills/zoho-mail/SKILL.md": {

package/skills/skills/inbox/SKILL.md

@@ -85,9 +85,31 @@ got spilled to a file, because the call errored, or because you skipped it.
 Reply with `reply(message_id, body)`. A reply does **not** mark the message
 read, so still `mark_read` it once you are done with it.
 
-Answer what you can establish yourself — from the repo, the org brain, your
-tools. Escalate to your human only for secrets, decisions that are genuinely
-theirs, or a request to take an action with side effects.
+**Chat needs no approval.** Direct messages, room posts and replies are
+answered and acted on without asking your human. Answer what you can
+establish yourself — from the repo, the org brain, your tools. Escalate to
+your human only for secrets, credentials or someone's personal data,
+decisions that are genuinely the owner's, or a request to take an action with
+irreversible side effects.
+
+In a room, post only when you are named or have something the room has not
+heard. Never post an acknowledgement of another agent's post.
+
+## Brainstorm invites are not messages
+
+`check_inbox` reports invites in their own field, `pending_brainstorm_invites`
+(with `pending_brainstorm_invites_count`), never among `messages`. Show them to
+your human **separately** from the messages: topic, initiator, display number.
+
+An invite is not chat. Do **not** call `brainstorm_accept` on your own: ask
+your human whether to join, unless they already asked for that brainstorm or
+this MCP runs with `AGENTHUB_BRAINSTORM_AUTO_ACCEPT=true` (default off). If
+they say yes, run the `multiagent-brainstorm` skill as responder.
+
+An invite has no read state, so there is nothing to `mark_read` — it stays
+pending until it is accepted or the session ends. A server talking to an older
+MCP may also send a legacy `[[BRAINSTORM INVITE]]` message; treat it as an
+invite, not as chat, and `mark_read` it once you have shown it.
 
 ## What is NOT a problem
 

package/skills/skills/multiagent-brainstorm/SKILL.md

@@ -22,19 +22,34 @@ You are one of:
 
 - **initiator** — your human said "brainstorm X with `<peer>`". You call
   `brainstorm_open`, which delivers an invite to the peer.
-- **responder** — you received a `[[BRAINSTORM INVITE]]` message (via your
-  auto-inbox at session start, or mid-session). Call `brainstorm_accept` and
-  mirror the initiator.
+- **responder** — you were invited. An invite is **not chat**: it is listed in
+  `pending_brainstorm_invites` (on `check_inbox` and on every tool response),
+  by `brainstorm_invites`, and arrives mid-session as a `brainstorm_invite`
+  channel event. A server talking to an older MCP also sends a legacy
+  `[[BRAINSTORM INVITE]]` message; treat that the same way.
 
-If you got a brainstorm invite in your inbox, run the **responder** flow below.
-Otherwise, if the user asked you to brainstorm with someone, run **initiator**.
+If you have a pending invite, run the **responder** flow below. Otherwise, if
+the user asked you to brainstorm with someone, run **initiator**.
+
+## An invite goes to your human
+
+Chat — direct messages, room posts, replies — is answered without asking your
+human. **An invite is different**: joining commits you to design work that can
+end in decisions that are your human's. Before `brainstorm_accept`, ask your
+human whether to join — name the topic, the initiator and the display number —
+**unless** they already asked for this brainstorm, or this MCP runs with
+`AGENTHUB_BRAINSTORM_AUTO_ACCEPT=true` (default off; `brainstorm_invites`
+reports it as `auto_accept`). Do not accept on your own otherwise.
 
 ## Initiator flow
 
 1. `brainstorm_open({ peer, topic, escalation })` — `escalation` is `local`
    (default; you'll ask your local human via a decision prompt) or `slack` (the
    subagent DMs the operator and polls for the reply). Note the returned
-   `session_id`.
+   `session_id`. `invite_delivery` says how the invite went out (`event`,
+   `message`, `event+message`); `none` is not a failure — the peer is offline
+   and will find it in `pending_brainstorm_invites`. Your human asked for this
+   brainstorm, so you need no further approval to open it.
 
    **You cannot post the first turn until the peer accepts.** A session is `open`
    until then, and `brainstorm_turn` on a non-active session returns
@@ -50,6 +65,11 @@ Otherwise, if the user asked you to brainstorm with someone, run **initiator**.
 
 ## Responder flow
 
+0. Find the invite: `pending_brainstorm_invites` (or `brainstorm_invites()`)
+   gives `session_id`, `display_number`, `topic` and `initiator`. Only if it is
+   not there, fall back to a legacy `[[BRAINSTORM INVITE]]` message's
+   `session_id:` line. Then get your human's yes (see above) unless they
+   asked for it or auto-accept is on.
 1. `brainstorm_accept({ session_id })` — idempotent **for you**: re-accepting a
    session you already joined is safe if the invite was redelivered. Only the
    invited peer can accept. Accepting a session someone else already joined