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