--- name: Buzz slug: buzz category: Automation description: Buzz connects Hermes to the native Buzz gateway for setup, media delivery, or self-hosted relay diagnostics. Use it when you need verified relay evidence or need to troubleshoot a Buzz connection without inventing delivery proof. github: "https://github.com/rlaope/oh-my-hermes/tree/main/skills/omh-buzz" language: Python stars: 1052 forks: 103 install: "npx degit https://github.com/rlaope/oh-my-hermes/tree/main/skills/omh-buzz ~/.claude/skills/omh-buzz" installs_to: ~/.claude/skills/omh-buzz source_path: skills/omh-buzz/SKILL.md collection_size: 25 category_size: 1523 collection_url: "https://dirskills.com/collections/rlaope/oh-my-hermes" added: 2026-08-21T05:13:48.808Z last_synced: 2026-08-21T05:13:48.808Z canonical_url: "https://dirskills.com/skills/buzz" --- # Buzz Buzz connects Hermes to the native Buzz gateway for setup, media delivery, or self-hosted relay diagnostics. Use it when you need verified relay evidence or need to troubleshoot a Buzz connection without inventing delivery proof. **Install:** ```bash npx degit https://github.com/rlaope/oh-my-hermes/tree/main/skills/omh-buzz ~/.claude/skills/omh-buzz ``` ## README # Buzz This is a Hermes-native `buzz` workflow skill. ## Why This Exists Hermes already owns the Buzz transport, but users need one discoverable OMH entry point that safely selects setup, attachment, or self-host operations and reports only the evidence actually observed. ## Do Not Use When - The user wants a Buzz-managed ACP runtime rather than Hermes' native Buzz gateway. - The request is general media editing with no Buzz delivery target. - The request is generic Docker or Nostr advice unrelated to a Buzz relay. - The user is only asking whether OMH supports Buzz, with no request to run the workflow. ## Examples Good example: - Prompt: Connect this Hermes gateway to my Buzz community and verify one inbound and outbound message. - Expected behavior: Load the setup reference, collect the relay and membership inputs without exposing the private key, use Hermes' guided gateway setup, then report each observed verification stage. - Why: The request names the native gateway task and an observable end-to-end stop condition. Bad example: - Prompt: Write a generic Nostr relay from scratch for OMH. - Expected behavior: Route to planning or coding rather than presenting that transport as part of omh-buzz. - Why: OMH reuses Hermes' native Buzz adapter and does not own a second Nostr transport. ## Completion Checklist - Exactly one of setup, media, or self-host is selected from request meaning; no internal lane is public. - Secrets remain out of argv, logs, rendered output, and workflow artifacts. - Configuration, process, relay, event acceptance, subscription, and client rendering are separate claims. - Any state-changing self-host command remains user-driven and has an explicit rollback or backup boundary. - The final answer names what was observed, what remains unobserved, and the next smallest proof action. ## Recovery Notes - If the Buzz CLI is missing, stop at installation guidance and do not claim gateway readiness. - If relay authentication fails, separate membership, identity, and NIP-42 evidence before changing config. - If a send receipt is malformed or lacks an event id, report ambiguous delivery and do not auto-retry. - If self-host readiness is green but media fails, inspect MinIO and disk separately from relay readiness. ## Workflow Lane - Current lane: **Automation and status** (`achievements`, `workspace-audit`, `production-audit`, `automation-blueprint`, `github-event-ops`, `buzz`, `agent-board`, `gateway-intent-card`, `+34 more`) - schedules, status, health, and ops review. - If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow. - Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`. ## Choose One Internal Lane `omh-buzz` is the only public skill. Choose exactly one reference from the request's meaning after this skill is selected: - Load `references/setup.md` to connect or repair Hermes' native Buzz gateway. - Load `references/media.md` to deliver a local attachment to the active Buzz conversation and report staged delivery evidence. - Load `references/self-host.md` to inspect or guide a self-hosted Buzz relay. Do not expose these references as separate skills and do not select them with a hard-coded keyword branch. If the request genuinely spans lanes, start with setup/readiness, then load only the next reference required by observed state. ## Ownership Boundary Hermes owns the native Buzz transport, authentication, inbound subscriptions, and outbound CLI invocation. OMH owns this operator workflow, the `buzz` platform identity layered over source `hermes`, safe evidence boundaries, and progressive guidance. Block's Buzz relay and CLI own their runtime semantics. ## Use When Use when the user wants to configure or troubleshoot Hermes' native Buzz gateway, attach local media to the active Buzz conversation, or inspect a self-hosted Buzz relay. Select the setup, media, or self-host reference from the request's meaning after this single public skill is selected. Strong routing signals: `connect Hermes to Buzz`, `Buzz community agent`, `Buzz gateway setup`, `Buzz media attachment`, `Buzz relay self-hosting`, `Buzz connection diagnostics`, `버즈 커뮤니티 연결`, `Buzz 메시지 첨부` ## Catalog Metadata Category: `operator` Phase: `messaging-integration` Hermes role: `tracker` Quality tier: `evidence-gated` Reasoning demand: `light` Quality bar: - Name the workflow target, constraints, validation evidence, and stop condition. - Separate Hermes guidance from executor or wrapper behavior unless evidence proves the step happened. Handoff policy: Operate through Hermes' native Buzz adapter and official Buzz surfaces. Keep state-changing self-host commands user-driven and delegate repository code changes only when the user explicitly asks for them. Required inputs: - Buzz task: gateway setup, media delivery, or self-host diagnosis - target Hermes home or active Buzz conversation - observable stop condition Expected outputs: - selected Buzz workflow lane - bounded setup or diagnostic evidence - observed delivery stage or explicit unobserved boundary Artifact expectations: - redacted Buzz readiness summary when setup is inspected - delivery receipt with accepted event id when media is sent - self-host failure-tree evidence when relay health is diagnosed Safety rules: - Reuse Hermes' native Buzz transport; do not implement or imply an OMH-owned Nostr transport. - Never print, persist in workflow artifacts, or place the Buzz private key in argv or shell history. - Do not treat CLI presence, configuration presence, or a prepared command as live relay readiness. - Do not claim message delivery without accepted=true and a non-empty event id from the send receipt. - Guide, don't drive state-changing self-host operations unless the user explicitly approves each action. ## Runtime Evidence Preferred harness for this skill: `coding-handling`. ```sh omh runtime record --skill buzz --harness coding-handling --status started ``` Record observed delegation results; otherwise return `not_available` or `not_observed`. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence. - Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes. Preserve workflow intent and stop conditions; verify before claiming completion. Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes. Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.