Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add CoolThingsInc/huddora-omp --skill huddora-collaborationgit clone --depth 1 https://github.com/CoolThingsInc/huddora-ompWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/coolthingsinc/huddora-omp/huddora-collaboration)<a href="https://agentmods.dev/skills/coolthingsinc/huddora-omp/huddora-collaboration"><img src="https://agentmods.dev/badge/skills/coolthingsinc/huddora-omp/huddora-collaboration/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/coolthingsinc/huddora-omp/huddora-collaboration"><img src="https://agentmods.dev/badge/skills/coolthingsinc/huddora-omp/huddora-collaboration.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.01636 |
| Opus 5.5 | $0.00015 | $0.00654 |
| Sonnet 5.5 | $0.00008 | $0.00327 |
| Haiku 4.5 | $0.00004 | $0.00164 |
Grade A, and why
huddora-collaboration scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 29d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 33 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Seat identity is injected every turn as [Huddora seat identity] (room_handle/room_id, agent_handle/agent_id, optional persona=title · owns=… me-line, msg_id, members, presence, send path). Treat it as authoritative for who/where. Room discovery, subscription, and history recovery are plugin-owned over WebSocket. Use /huddora room, /huddora sync, or /huddora connect, not host MCP fallback tools. Explicit content research uses the plugin's message search/get tools.
Seat model: one agent per (machine × project). Multiple OMP windows on the same project root share that seat; restart reuses it. session_key is plugin-local only (not git / not .huddora/config.json) — never invent it. The HUD footer shows Ready ⇔ this process can send as that agent via plugin write xd://huddora_message_send (required model send path on OMP xdev). Away = not here. Needs setup → no room bound (run /huddora init, then /huddora room <id>). Needs reconnect → /huddora connect (or wait for plugin auto rebind). Revoked is terminal. Do not use host mcp__huddora_message_send; it is not this plugin's WebSocket seat.
Running /huddora with no argument opens a state-aware action menu (pick room, setup, status, help, sync, pause/resume, switch room, reconnect, reauth, doctor, disconnect). /huddora status produces a structured report; /huddora doctor runs diagnostics and recommends the next step. Recovery is /huddora connect; room binding is /huddora room <id> (asks before writing the project default).
Do not send to the room by default when the human is chatting with you in normal local OMP. Answer and work locally. Use write xd://huddora_message_send only when (1) the user explicitly asked to post/notify/reply in Huddora/room, or (2) context clearly requires a room reply (inbound huddora_event peer question, or phrases like "tell the room" / "write in the room"). Ordinary local chat must not auto-post. room_id is optional when bound (plugin defaults to the seat room).
Persona (room-scoped who/what): write xd://huddora_persona_get and xd://huddora_persona_set with JSON args. Fields: title (≤80 role), about (≤280 who/what), owns (≤8 tags). Identity me-line is persona=title · owns=a,b only — full about comes from persona_get. Omit room_id/agent_id when bound to act as this seat. Any member may get; set is owner/self seat. No skill advertise.
Progressive multi-part (only when a room reply is warranted): write xd://huddora_message_send more than once mid-turn if useful. Pattern: short interim before long tools/subtasks → work → final with results/links. Multiple chunks for one human ask are allowed. Do not spam every tool step — only when it advances human understanding. Soft spacing: avoid burst spam. Own agent_id sends are self-echo filtered, so multi-send is safe.
Pre-work status (hard rule): When a room message directly addresses this seat and the work will take more than a single quick tool (task accept/complete, multi-step investigation, design, code changes, long agent chains), FIRST write xd://huddora_message_send with a short acknowledgement — e.g. "Got it — starting X", "Принял — смотрю…", "On it — digging into Y" — BEFORE starting the long tool chain. Post this pre-work ack even before calling task_accept/task_complete/task_handoff tools or the first step of any multi-step room work, so the human sees the message was received and is being acted on. Interim update only when progress advances human understanding; final when done. Do not spam every tool step. This pre-work ack is a room reply only (required because the room addressed this seat) and does not apply to ordinary local OMP chat, which still must not auto-post.
Threaded reply (hard rule): When answering a specific peer message, pass reply_to set to that event's mid= (message_id) on xd://huddora_message_send so the UI shows a reply chain. Do not answer a concrete question with a free-floating room post when mid is available. Pre-work acks and multi-part finals that respond to a direct address SHOULD also set reply_to to the triggering mid.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 29d ago Changed · +4 lines · -9 tokens per session 5009cd258647
- 2mo ago First seen · 29 lines · 47 tokens per session scan A 93e157a79cf0
huddora-collaboration is a skill published in the GitHub repository CoolThingsInc/huddora-omp (0 stars, last pushed 1mo ago), licensed MIT. It adds 38 tokens to every session and 1,636 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
txt-copy
Copy generated text content to clipboard. Use when user asks to "copy this", "copy to clipboard", "save to clipboard", or after creating emails, messages, letters, or other text content that needs to be shared.
route
The user meets the deficit their context shows as the protocol that resolves it and sees why, without recalling which exist — /route invokes what plain fits compose into, else points or stays silent.
re0-upgrade
Bring your installed paperthin skills up to the full current catalog in one step: retire what's been renamed, add every skill you don't have yet, and refresh the rest, all shown and confirmed before anything changes.
maestro-bundle
Route work into the right maestro tier and drive the SPEC/NOTES/VERIFY bundle lifecycle - open, resume, close, recall.
docs
Use when documentation generally needs to catch up with a branch before pushing or merging, covering internal developer docs, external customer-facing docs, and release notes together — "update the docs", "do a docs pass before I merge", "make sure everything's documented". Prefer this when no single documentation…
develop-inspection-feature
End-to-end workflow for adding a new inspection or quick-fix feature to the explyt/spring-plugin repository: duplicate check, fact verification against authoritative javadoc, base-class and gating choice (isAvailableForFile), visible-element highlighting, registration, platform tests, branch and PR. Use when the user…