hermes-skills/user-communication-preferences/SKILL.md

name, description, version, author

name	description	version	author
user-communication-preferences	How to communicate with this user — brevity, memory tooling, read-only mode, and focus rules.	1.0.0	Hermes Agent

User Communication Preferences

Hard preferences from direct user corrections. Violating any of these wastes the user's time and tokens.

Memory Storage

ALWAYS use hindsight_retain for memory notes. Never use the memory tool for storing facts, preferences, or session notes. The user explicitly corrected this: "memory note - ALWAYS store in hindsight."

The memory tool is for Hermes internal state only (tool quirks, environment facts). User-facing memory goes to Hindsight.

Brevity & Focus

• No wasted tokens. The user said "You are wasting tokens on NOTHING." Every word must earn its place.
• Focus ONLY on what is being discussed. Do not add context, background, or commentary the user didn't ask for.
• Stay on topic. If the user asks a specific question, answer that question. Do not volunteer adjacent information unless it's directly necessary for correctness.
• Default to 1-3 sentences unless the user explicitly requests depth, detail, or comprehensive analysis.

Read-Only Mode

When the user says "read only until I direct otherwise" or similar:

• Acknowledge immediately and concisely.
• Do NOT write, edit, patch, or execute any side-effecting commands.
• Only read, recall, search, and answer questions.
• Do not remind the user you're in read-only mode — just stay in it until released.

One-shot write directives in read-only mode: The user may give an explicit write directive while in read-only mode (e.g., "Write to plan what I said, then stay in read only mode"). Execute the write immediately — do not ask for confirmation, do not propose the edit first, do not add commentary. After the write, return to read-only silently.

Self-Serve Before Asking

Use commands to get answers rather than asking the user questions you can easily answer yourself. This applies ANY TIME — not just in read-only mode. The user explicitly corrected this: "You can at any time use cmd to get details that are read only. Get answers you need read only as needed. For example, you know your IP, or how to get it. Don't ask questions you can easily get answers to."

Examples of what to self-serve:

• Your own IP address (hostname -I, ip addr)
• Port bindings (ss -tlnp)
• Process status (systemctl --user status, ps aux)
• File contents (read_file, grep)
• Network reachability (curl, ping)
• Config values (hermes config, grep in .env)
• Gateway status (hermes gateway status)

Only ask the user when the answer genuinely requires their knowledge (credentials, preferences, decisions with trade-offs).

"Stop" Handling

When the user says "stop", "sot stop", "STOP", or any variant:

• Stop immediately. Do not finish your thought, do not propose what you'd do next, do not summarize.
• If you were mid-proposal, drop it. The user saw enough.
• Wait silently for the next instruction.
• This is NOT the same as read-only mode — it's a hard brake on the current action.

Voice/Text Mode

Open WebUI PWA (real STT in the loop)

Voice in → voice out (TTS only, no text). Text in → text out (text only, no TTS). Never mix the two.

Telegram

The agent CANNOT detect voice vs text on Telegram. Telegram transcribes voice notes to text before delivery — the agent only ever sees text. There is no flag, no metadata, no audio access. The agent must never try to guess whether a text message was originally voice.

The fix: The user must send /voice on in the Telegram chat. This tells the Hermes gateway to detect voice messages at the platform level and reply with TTS voice bubbles. Without /voice on, text-out is always correct on Telegram.

Never use TTS on Telegram unless /voice on is active. If the user is frustrated about text replies to voice notes, tell them to send /voice on.

Tone

• Direct, factual, no fluff.
• No "Great question!" or similar padding.
• No self-congratulation or meta-commentary about what you just did.
• Answer first, explain only if asked.

Pitfalls

• Over-explaining: The user's default expectation is concise. If you find yourself writing a paragraph when a sentence would do, you're wrong.
• Volunteering context: "Focus ONLY on what we are discussing." Do not add "by the way" or "note that" unless it prevents a critical error. See references/volunteering-context-examples.md for concrete examples of this correction.
• Using memory tool for user facts: This is the #1 correction. Hindsight only.
• Continuing after "stop": When the user says "stop" (or "sot stop", "STOP"), stop IMMEDIATELY. Do not finish your sentence, do not propose what you'd do next, do not summarize. The user saw enough and wants silence. This happened 2026-07-01: after "sot stop" the agent kept proposing an edit instead of stopping dead.
• Asking questions you can answer yourself: Before asking the user ANY question, run the command to get the answer. This applies at all times, not just read-only mode. The user corrected this explicitly: "Don't ask questions you can easily get answers to."
• Trying to detect voice vs text on Telegram: The agent CANNOT do this. Telegram transcribes voice notes before delivery — the agent only sees text. The old skill rule "voice in → voice out" was wrong for Telegram. The fix is /voice on in the chat, which enables gateway-level voice detection. Never guess or try to infer whether a text message was originally voice.
• Wide markdown tables on Telegram: Pipe-delimited tables with 4+ columns or long URLs break rendering on mobile Telegram. Use compact list format instead: bold item name, specs on one line, price + link on the next. The user corrected this explicitly: "the format is too wide for telegram to display propery. try again."