$npx -y skills add multica-ai/multica --skill multica-mentioningUse when an issue comment needs to @mention someone — link to a person, trigger another agent, hand work to a squad, or broadcast with @all. Documents the verified mention contract: how a mention link is built from a real UUID, the four mention types and exactly what each one enq
| 1 | # Mentioning & Delegating |
| 2 | |
| 3 | This skill states WHAT a mention link does in the Multica backend, traced to |
| 4 | source. WHETHER to mention at all — loop avoidance, staying silent on |
| 5 | acknowledgements — is in your runtime brief's Mentions section; follow that and |
| 6 | do not repeat it here. |
| 7 | |
| 8 | Every claim below is pinned to source in |
| 9 | `references/mentioning-source-map.md`. If behavior ever differs from this |
| 10 | document, the source map is where to re-check it. |
| 11 | |
| 12 | ## A mention link is built from a real UUID |
| 13 | |
| 14 | The backend recognizes a mention only through this Markdown shape: |
| 15 | |
| 16 | [@Label](mention://<type>/<id>) |
| 17 | |
| 18 | The parser (`util.MentionRe` in `server/internal/util/mention.go`) accepts |
| 19 | exactly four `<type>` values plus the `all` sentinel, and the `<id>` group |
| 20 | accepts only hex characters and dashes, OR the literal string `all`: |
| 21 | |
| 22 | (member|agent|squad|issue|all)/([0-9a-fA-F-]+|all) |
| 23 | |
| 24 | So the link target is a real entity UUID (or `all`), never a display name. The |
| 25 | label between the brackets is free text — that is where the human-readable name |
| 26 | goes. |
| 27 | |
| 28 | ## Step 1 — look up the UUID with `--output json` |
| 29 | |
| 30 | A name is not a UUID. Look the UUID up first, from the matching list command: |
| 31 | |
| 32 | - a person → `multica workspace member list --output json` → use `user_id` |
| 33 | - an agent → `multica agent list --output json` → use `id` |
| 34 | - a squad → `multica squad list --output json` → use `id` |
| 35 | |
| 36 | For a person the mention id is the `user_id`, NOT the membership-row id — the |
| 37 | backend's own roster formatter uses `user_id` for member mentions. Match by |
| 38 | display name. If the name is ambiguous or absent, do not guess — say so in your |
| 39 | comment instead of emitting a broken link. |
| 40 | |
| 41 | ## Step 2 — the four types and exactly what each enqueues |
| 42 | |
| 43 | Format: `[@Name](mention://<type>/<uuid>)`. The `<type>` and the id source must |
| 44 | match, or the link resolves to the wrong entity (or to nothing). |
| 45 | |
| 46 | | To… | type | uuid from | What the backend does | |
| 47 | | -------------------- | -------- | --------------- | -------------------------------------------------------- | |
| 48 | | trigger an agent | `agent` | agent.id | enqueues a run for that agent (`EnqueueTaskForMention`) | |
| 49 | | hand work to a squad | `squad` | squad.id | resolves the squad's `leader_id` and enqueues a run for the LEADER agent | |
| 50 | | link a person | `member` | member.user_id | renders a link; enqueues NOTHING — no agent run | |
| 51 | | reference an issue | `issue` | issue.id | renders a link; enqueues NOTHING — always safe | |
| 52 | |
| 53 | The mention trigger set is computed by `computeMentionedAgentCommentTriggers` |
| 54 | (`server/internal/handler/comment.go`); the comment path folds that result into |
| 55 | `computeCommentAgentTriggers` and enqueues it via `enqueueCommentAgentTriggers`. |
| 56 | It acts on two types only: the `squad` branch resolves the squad and adds its |
| 57 | leader to the trigger set; everything that is not `agent` after that is skipped |
| 58 | (`if m.Type != "agent" { continue }`), then the `agent` branch adds that agent. |
| 59 | A `member` or `issue` mention reaches neither branch, so it enqueues no task. |
| 60 | |
| 61 | A `member` mention therefore does NOT make a person "run", and this skill does |
| 62 | NOT claim it delivers a notification through the Go comment handler — there is |
| 63 | no such code path in that handler (see the source map). What is verified is the |
| 64 | contract above: only `agent` and `squad` mentions enqueue work. |
| 65 | |
| 66 | ## Preview and per-comment suppression |
| 67 | |
| 68 | Newer clients can call `POST /api/issues/{id}/comments/trigger-preview` before |
| 69 | creating or editing a comment. The preview endpoint uses the same |
| 70 | `computeCommentAgentTriggers` function as create and edit re-triggering, so the |
| 71 | displayed agent chips come from backend rules, not from a client-side |
| 72 | reimplementation. |
| 73 | |
| 74 | When previewing an edit, clients may send `editing_comment_id`. The server |
| 75 | validates that the comment belongs to the same workspace and issue, derives or |
| 76 | checks the edit's parent comment context, and excludes only pendi |