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, github-issue-intake, buzz, agent-board, +35 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.
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.
1---
2name: "omh-buzz"
3description: "[omh] Connect and operate Hermes as a native Buzz community agent, deliver local media with verified relay receipts, or diagnose a self-hosted Buzz relay without inventing transport evidence. Aliases: omh-buzz. Use when the user says: connect Hermes to Buzz, Buzz community agent, Buzz gateway setup, Buzz media attachment, Buzz relay self-hosting, Buzz connection diagnostics, 버즈 커뮤니티 연결, Buzz 메시지 첨부."
4metadata:
5 hermes:
6 tags: [workflow, oh-my-hermes, operator]
7 category: operator
8 phase: messaging-integration
9 role: tracker
10 quality_tier: evidence-gated
11---
12
13# Buzz
14
15This is a Hermes-native `buzz` workflow skill.
16
17## Why This Exists
18
19Hermes 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.
20
21## Do Not Use When
22
23- The user wants a Buzz-managed ACP runtime rather than Hermes' native Buzz gateway.
24- The request is general media editing with no Buzz delivery target.
25- The request is generic Docker or Nostr advice unrelated to a Buzz relay.
26- The user is only asking whether OMH supports Buzz, with no request to run the workflow.
27
28## Examples
29
30Good example:
31
32- Prompt: Connect this Hermes gateway to my Buzz community and verify one inbound and outbound message.
33- 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.
34- Why: The request names the native gateway task and an observable end-to-end stop condition.
35
36Bad example:
37
38- Prompt: Write a generic Nostr relay from scratch for OMH.
39- Expected behavior: Route to planning or coding rather than presenting that transport as part of omh-buzz.
40- Why: OMH reuses Hermes' native Buzz adapter and does not own a second Nostr transport.
41
42## Completion Checklist
43
44- Exactly one of setup, media, or self-host is selected from request meaning; no internal lane is public.
45- Secrets remain out of argv, logs, rendered output, and workflow artifacts.
46- Configuration, process, relay, event acceptance, subscription, and client rendering are separate claims.
47- Any state-changing self-host command remains user-driven and has an explicit rollback or backup boundary.
48- The final answer names what was observed, what remains unobserved, and the next smallest proof action.
49
50## Recovery Notes
51
52- If the Buzz CLI is missing, stop at installation guidance and do not claim gateway readiness.
53- If relay authentication fails, separate membership, identity, and NIP-42 evidence before changing config.
54- If a send receipt is malformed or lacks an event id, report ambiguous delivery and do not auto-retry.
55- If self-host readiness is green but media fails, inspect MinIO and disk separately from relay readiness.
56
57## Workflow Lane
58
59- Current lane: **Automation and status** (`achievements`, `workspace-audit`, `production-audit`, `automation-blueprint`, `github-event-ops`, `github-issue-intake`, `buzz`, `agent-board`, `+35 more`) - schedules, status, health, and ops review.
60- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
61- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.
62
63## Choose One Internal Lane
64
65`omh-buzz` is the only public skill. Choose exactly one reference from the
66request's meaning after this skill is selected:
67
68- Load `references/setup.md` to connect or repair Hermes' native Buzz gateway.
69- Load `references/media.md` to deliver a local attachment to the active Buzz
70 conversation and report staged delivery evidence.
71- Load `references/self-host.md` to inspect or guide a self-hosted Buzz relay.
72
73Do not expose these references as separate skills and do not select them with
74a hard-coded keyword branch. If the request genuinely spans lanes, start with
75setup/readiness, then load only the next reference required by observed state.
76
77## Ownership Boundary
78
79Hermes owns the native Buzz transport, authentication, inbound subscriptions,
80and outbound CLI invocation. OMH owns this operator workflow, the `buzz`
81platform identity layered over source `hermes`, safe evidence boundaries, and
82progressive guidance. Block's Buzz relay and CLI own their runtime semantics.
83
84## Use When
85
86Use 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.
87
88 Strong routing signals: `connect Hermes to Buzz`, `Buzz community agent`, `Buzz gateway setup`, `Buzz media attachment`, `Buzz relay self-hosting`, `Buzz connection diagnostics`, `버즈 커뮤니티 연결`, `Buzz 메시지 첨부`
89
90## Catalog Metadata
91
92Category: `operator`
93Phase: `messaging-integration`
94Hermes role: `tracker`
95Quality tier: `evidence-gated`
96Reasoning demand: `light`
97
98Quality bar:
99
100- Name the workflow target, constraints, validation evidence, and stop condition.
101- Separate Hermes guidance from executor or wrapper behavior unless evidence proves the step happened.
102
103Handoff policy:
104
105Operate 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.
106
107Required inputs:
108
109- Buzz task: gateway setup, media delivery, or self-host diagnosis
110- target Hermes home or active Buzz conversation
111- observable stop condition
112
113Expected outputs:
114
115- selected Buzz workflow lane
116- bounded setup or diagnostic evidence
117- observed delivery stage or explicit unobserved boundary
118
119Artifact expectations:
120
121- redacted Buzz readiness summary when setup is inspected
122- delivery receipt with accepted event id when media is sent
123- self-host failure-tree evidence when relay health is diagnosed
124
125Safety rules:
126
127- Reuse Hermes' native Buzz transport; do not implement or imply an OMH-owned Nostr transport.
128- Never print, persist in workflow artifacts, or place the Buzz private key in argv or shell history.
129- Do not treat CLI presence, configuration presence, or a prepared command as live relay readiness.
130- Do not claim message delivery without accepted=true and a non-empty event id from the send receipt.
131- Guide, don't drive state-changing self-host operations unless the user explicitly approves each action.
132
133## Runtime Evidence
134
135Preferred harness for this skill: `coding-handling`.
136
137```sh
138omh runtime record --skill buzz --harness coding-handling --status started
139```
140
141Record observed delegation results; otherwise return `not_available` or `not_observed`.
142Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
143- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
144Preserve workflow intent and stop conditions; verify before claiming completion.
145
146Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
147
148Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.