Content Style

Content Style: r/hermesagent & Community Posts

Overview

Writing Reddit-native content that sounds human, avoids AI tells, and delivers value through structure and specificity. Applies to workshop posts, definitive model guides, research megathreads, and community FYI/update posts.

Hook Patterns

Lead with one of these:

1. Contradiction — "Everyone says X but Y is actually true"
2. Specific number — "The 3 tools I use daily"
3. Pain point — "If you're doing X, stop"
4. Before/after — "Before: Y. After: Z"
5. Question — "Why does X still suck?"

Writing Principles

• Hook first, details second
• Lead with what people actually care about
• Concrete over abstract: specific examples beat general advice
• One idea per paragraph
• End on a clear takeaway

Product-name disambiguation before drafting

For “How would you describe X on Reddit?” requests, lock the exact product identity before importing features or architecture:

1. Treat likely voice-dictation homophones (box/Vox, Voz/Vox) as ambiguous names, not permission to substitute the nearest familiar project.
2. Search for the exact spelling and check whether it is an external product, a renamed product, or one of the user’s similarly named apps.
3. Describe only features supported by that product’s source material. Do not transfer one voice-learning product's capabilities to another merely because they share a category.
4. If the user corrects the name, acknowledge it briefly and rewrite from the corrected identity; do not preserve assumptions from the earlier draft.

Plain-language Reddit product explainer

Use this compact order for a comment-sized explanation:

1. What it is — one sentence in ordinary language.
2. What the user does — the concrete interaction.
3. How it works — only the essential mechanism, without architecture dumping.
4. Why it is different — one comparison readers immediately understand.

Keep a short Reddit comment short unless the user asks for a full post. Avoid marketing copy such as “revolutionary,” unsupported privacy claims, or a polished feature list that has not been verified.

What to Avoid

• Long intros that bury the lead
• Bullet-point dumps without through-line
• Writing for peers instead of audience
• Ending with "any questions?"
• Self-deprecation as escape hatch

Tone

• Direct, not performative
• Confident but not arrogant
• One clear sentence beats three hedged ones
• No "I think" / "I believe" filler
• No trailing questions

Anti-AI Sounding Replies

For social media replies that should sound human:

• Use contractions freely
• Keep sentence length uneven
• Include minor colloquialisms or fragments
• Avoid perfectly balanced paragraphs
• Skip transition words like "additionally", "furthermore"
• Use lowercase for emphasis instead of formatting
• One genuine opinion > five hedged observations
• Natural "honestly" or "look" is fine

Answering Beginner Hermes Reliability Questions

When a Reddit user asks whether Hermes can be forced to obey instructions, whether gates can be ignored, or how memory avoids degradation:

1. Lead with the honest limit: natural-language instructions to a probabilistic model are soft controls and cannot guarantee perfect compliance.
2. Separate instructions from enforcement: prompt rules can be missed; deterministic runtime controls can block a specific action path. Never imply a gate protects routes it does not cover.
3. Use the correct confidence gradient: prompt/SOUL/skill guidance → verifier or judge → tool restrictions and approvals → OS/container/filesystem boundaries. Only the last category can make some violations mechanically impossible.
4. Treat claims of completion as unverified: recommend observable evidence such as tool output, file readback, screenshots, tests, or independent review.
5. Explain memory by storage role: bounded built-in memory for durable facts, skills for procedures, and session_search for on-demand historical detail.
6. Preserve key nuances: memory overflow errors rather than silently evicting entries; exact duplicates are deduplicated as a successful no-op; writes persist immediately while the system-prompt snapshot remains frozen until the next session.
7. Keep it novice-readable: explain the model first, then the Hermes mechanisms. Avoid dumping config commands unless the reader asks how to enable them.
8. Separate storage roles explicitly: user preferences belong in USER.md; compact stable environment facts belong in MEMORY.md; procedures belong in skills; project or machine operating rules belong in HERMES.md / .hermes.md / AGENTS.md; actual transport belongs in SSH config or a deterministic integration.
9. Do not describe memory as the source of truth for live machine identity: recommend live verification (hostname, pwd, and, when relevant, uname or an explicit remote-host check) before remote work.
10. When explaining a reliable remote-agent setup, describe the layered pattern: durable memory points to the canonical runbook; the runbook holds detailed scope, routes, and recovery; a connector performs the transport; returned tool output proves success. Do not imply that a model should reconstruct a complete SSH/API recipe from remembered prose.

Machine identity and remote-execution reliability

When a beginner reports that Hermes forgets which computer it is on, chooses the wrong SSH route, or keeps rediscovering an installed tool, treat this as a configuration-and-verification question first, not simply an external-memory question.

Explain the practical split:

• USER.md is for identity and preferences, not infrastructure topology.
• MEMORY.md may hold a short stable pointer such as the machine role and the location of the authoritative runbook, but it is bounded and session-snapshotted.
• HERMES.md, .hermes.md, or AGENTS.md should contain the readable machine map and operating rules for the relevant working directory.
• ~/.ssh/config should contain host aliases, ports, usernames, and key selection; never put private keys or secrets in memory/context files.
• A dedicated skill should define the procedure: verify the current host, use the named alias, verify the remote host after connecting, avoid improvised multi-hop routing, and stop on ambiguity.
• When a native connector exists, prefer it over asking the model to assemble transport details manually.

Use a plain-language example when useful: > Memory tells Hermes where the runbook is. The runbook explains the machines. SSH config or a native connector performs the connection. hostname and the returned tool output prove which machine was actually reached.

Current sourced details and reusable wording checks are in references/hermes-instruction-compliance-memory.md. Re-check the live Hermes docs before publishing version-sensitive defaults.

Post Templates

Workshop Post (copy-paste prompt)

[HOOK — one sentence that makes someone stop scrolling]

[SETUP — 2-3 sentences max, get to the point fast]

[CONTENT — concrete details, specific numbers, real examples]

[TAKEAWAY — clear takeaway or next step]

Audit/Diagnostic Post (pain-point → framework → runnable prompt)

[IDENTIFY PROBLEM — quote top community complaints]

[EXPLAIN ROOT CAUSE — what's actually going wrong]

[THE FRAMEWORK — grading criteria or dimensions that matter]

[RUNNABLE PROMPT — copy-paste prompt anyone can use immediately]

[REAL EXAMPLES — before/after showing bad vs. fixed]

[TAKEAWAY — one-sentence summary]

Community Update / FYI Post

For infrastructure, moderation tooling, process changes, community operations.

[HOOK — what you did. No preamble]

[CONTEXT — one paragraph on scope and independence]

[WHAT CHANGED — bullet list, one fact per bullet]

[THE SYSTEM — how it works, numbered steps if workflow]

[GUARDRAIL — what it CAN'T do — this matters more than what it does]

[WHY THIS MATTERS — the pattern, not the pipeline, one concrete example]

[FEEDBACK LOOP — how readers can report issues, specific]

FYI Post rules:

• Lead with action, not greeting (no "Quick update" or "Hey everyone")
• Headers are blunt: "What changed" not "Here's what I updated"
• The guardrail matters more than the workflow
• One concrete example beats three paragraphs of philosophy
• End with specific ask, not vague invitation

Non-Technical Explainer Post (translate a technical release for a general audience)

For "explain this announcement/release/feature for non-technical people" requests — most commonly translating a terse technical tweet or changelog line into a Reddit-native post.

[TITLE — plain-language benefit or removed pain point, not the feature name]

[HOOK — one line, no preamble]

[THE PROBLEM THIS SOLVES — plain-language grounding of why this mattered BEFORE the change.
 Define any load-bearing term inline the first time it appears (parenthetical gloss), never after.]

[WHAT CHANGED — 2-4 bullets, one fact per bullet, attribute claims to the source
 ("Nous says...", "the announcement claims...") rather than inventing an evidence
 framing the source didn't use]

[HOW IT WORKS, IN PLAIN TERMS — one analogy, see selection rules below]

[WHAT IT CAN'T DO — the guardrail. This deflates hype and is often the most
 trustworthy section; don't skip it]

[WHY IT MATTERS — the new idea only. If this repeats the "what changed" bullets,
 cut the repeat and lead with the angle that's actually new (e.g. a "hidden tax"
 framing) ]

[CLOSING — a takeaway or a specific ask ("if you run X, curious whether you
 notice Y"), never just a bare source link]

Source: [link]

Analogy selection — test every candidate against two independent criteria, not just "does this feel clever":

1. Audience accessibility. Does understanding the analogy require background the stated audience doesn't have? An analogy that name-drops an internals feature of a tool (e.g. git notes, a specific API's internal cache eviction policy) fails this even when the underlying subject is a dev-heavy subreddit — plenty of working practitioners have never touched the specific internal feature you're citing. If you have to write "if you've ever used X, you already understand this," that sentence is a tell the analogy just excluded everyone who hasn't used X. Prefer universal, everyday analogies (a librarian who knows which section to search instead of shelving everything up front, a restaurant menu vs. asking the waiter what's off-menu, phone contacts you look up instead of memorizing) — they carry zero technical prerequisite.
2. Mechanism fidelity. The analogy must actually map the mechanism being explained, not just the vague shape of it. Check specifically for: threshold/adaptive behavior (does the analogy have a "still fine below X, changes above X" property if the real system does?), active vs. passive retrieval (does the analogy's information get actively searched-for on demand, or does it just passively sit there waiting to be noticed — these are different mechanisms and picking the wrong one misleads the reader), and discovery direction (does the analogy's "something advertises its own existence" direction match the real system, or is it backwards?). An analogy can pass the accessibility test and still fail this one — verify both before finalizing, don't stop at "sounds clean."

When you catch an analogy problem via self-review or a critic pass, treat the fix as a stylistic/subjective decision and bring the tradeoff back to the user (e.g. via clarify) rather than silently swapping it — the user may want the technical analogy anyway for a dev-heavy audience, or may want it demoted to a secondary aside rather than dropped.

Jargon-grounding pass (run before calling a draft done): scan for every technical noun introduced without a plain-language gloss on first use — common misses: "tokens," "context window" (fine once, redundant if defined twice — keep the first, cut the second), protocol/product names the source assumes familiarity with (e.g. "MCP"), and engineering shorthand like "out-of-band" when a plain-English equivalent ("off to the side") already exists elsewhere in the draft. Either define inline in a parenthetical or cut the term entirely if it's not load-bearing.

Critic-verification pitfall (do not skip): an independent critic pass (Fable, cross-model audit, etc.) can flag a claim as "invented" or "not in the source" when it actually IS in the source — always re-read the exact primary-source text yourself before applying a critic's factual-accuracy fix. A critic pass once claimed a draft’s "internal test" language was fabricated when it was quoted from the source; re-reading the primary text resolved it." Applying that fix blind would have introduced an inaccuracy the critic invented while trying to catch one. Treat every critic finding as a hypothesis to verify against the primary source, not a fact to apply — this applies to ALL critic passes in this skill (the chosen critic model, OpenRouter, delegate_task audits), not just explainer posts.

Security-incident sticky / mod note

When a credible security report initially looks like spam or implies Hermes itself caused an attack, keep the sticky short and separate the layers:

1. Source status: say the source was vetted and whether it is a legitimate company/publication.
2. Mechanism: explain that Hermes was used as an agent harness when that is the evidence; do not call Hermes the malware, exploit, or attacker.
3. Guardrail: state what the report does not show—no Hermes vulnerability, no evidence ordinary users were compromised, or no proof of initial access—only when verified.
4. Evidence limit: distinguish independently corroborated infrastructure/sample behavior from private vendor captures and unconfirmed victim attribution.
5. Analogy: one plain comparison such as “someone used Python or Metasploit” is enough.

Preferred wording is “parts of the technical evidence independently check out,” not “the story is confirmed,” when the victim or government has not publicly acknowledged it. YOLO/approval bypass proves commands could run without approval; it does not prove no human supplied objectives or watched the session. Avoid repeating the sensational headline in the clarification.

Use either a 2–4 paragraph sticky post or a single compact mod comment. The goal is to reassure readers the link is not spam while preventing the clarification from becoming brand defense.

Content Planning: Audit Before You Write

Before drafting, verify demand signal:

Demand signals:

• Comment count on related threads (25+ = hot, 7-15 = viable, ~/Desktop/critique-output.txt 2>&1

This avoids API keys entirely — OAuth is handled by `hermes auth status nous`.

See `references/nous-portal-critic-workflow.md` for the full workflow.

**When to use OpenRouter instead:** If you need Claude Sonnet 4/4.5/4.6/5 specifically (not Fable), use OpenRouter. See `references/openrouter-critic-workflow.md`.

**Fable is available on both providers (verified):** The model-catalog.json now lists `anthropic/claude-fable-5` under BOTH the `openrouter` and `nous` providers. Earlier sessions hit a 404 using a stale ID (`anthropic/claude-3.5-sonnet`) — Sonnet 3.5 is no longer on OpenRouter. Before retrying a critic call that 404'd, verify the model ID against the live catalog:

```bash
curl -s https://hermes-agent.nousresearch.com/docs/api/model-catalog.json | python3 -c "
import json,sys
cat = json.load(sys.stdin)
for provider in ('openrouter','nous'):
 print(f'--- {provider} ---')
 for m in cat['providers'][provider]['models']:
 if 'fable' in m['id'].lower():
 print(' ', m['id'])
"

Then use the exact listed ID. Both Nous Portal (OAuth, no key needed) and OpenRouter work for Fable 5. For the Sonnet family, continue using OpenRouter.

**Recommended sequence for model-variant megat

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: AtlasOmnia
• Source: AtlasOmnia/donna-starter
• License: MIT

Install and usage instructions live in the source repository linked above.