Hermes Starter Onboarding

Hermes Starter Onboarding

Overview

Use this skill to turn a blank or lightly configured Hermes profile into a setup chosen by its owner. The workflow is conversational and consent-gated: learn the user's identity and priorities, recommend a small capability bundle, show the proposed changes, apply only what the user approves, and verify the result.

This is a capability planner, not a blind installer. A Hermes toolset exposes a capability, a skill provides operating instructions, a plugin or MCP server provides an integration, and a desktop application such as Obsidian is a separate dependency. Explain that distinction in plain language when it matters.

The setup must work for a public starter profile. Never assume the user's name, location, timezone, businesses, accounts, vault paths, tickers, health history, credentials, or preferred assistant name. Ask instead.

When to Use

• A new user starts a Donna or other Hermes starter profile.
• The user says "set me up," "configure my assistant," "what tools should I enable," or asks what Hermes can connect to.
• The user wants to choose memory, notes, browser, terminal, voice, calendar, reminders, email, or other integrations.
• The user asks to add or change a daily briefing, daily wellness check-in, recurring health reminder, or stock-quote schedule.
• The user asks to review or change an existing starter setup.

Don't use for:

• Installing Hermes itself or repairing the Hermes runtime; use hermes-agent.
• Diagnosing an already configured integration; load the matching integration or troubleshooting skill.
• Making medical decisions, diagnosing symptoms, or monitoring an emergency.
• Placing trades, giving personalized investment advice, or treating a quote as a trading signal.
• Creating a cron job from an incomplete request when the delivery destination, schedule, or content would be ambiguous.

Operating Rules

1. Ask one small group of related questions at a time. Do not present a forty-item questionnaire.
2. Start with the user's goals, then recommend capabilities. Do not ask users to choose toolset names they have never seen.
3. Explain what will happen before it happens. No installation, account connection, credential request, or persistent cron creation without explicit approval.
4. Never ask the user to paste a password, API key, OAuth code, payment information, or private token into chat. Use the provider's official setup flow and pause at the credential gate.
5. Read-only discovery is allowed before approval when it does not access private account content. Do not silently read connected accounts, note vaults, calendars, mailboxes, or health records.
6. Keep setup choices local to the active profile. Do not edit another Hermes profile or global configuration unless the user explicitly requests that scope.
7. After a persistent toolset or provider change, tell the user whether a new session or gateway restart is required. Do not claim a new tool is available until a fresh-process check confirms it.
8. A cron job runs in a fresh session with no current-chat context. Every LLM-driven cron prompt must be self-contained.
9. Run the orientation in the live session — do not delegate it to a sub-agent. Onboarding is a conversation: each answer shapes the next question, and the setup actions (a config set, a toolset toggle) are instant. Spawning a sub-agent to "set things up in the background" would sever that loop and add indirection, not reduce derailment. Keep it single-threaded and interactive.
10. Do not put memory writes in cron prompts. Mnemosyne is provider-injected, not a toolset, and cron contexts intentionally skip Mnemosyne tools. Health responses must not be stored automatically.
11. Never use enabled_toolsets: ["mnemosyne"]; that is not a valid configuration. Use the memory provider setup for memory and the cronjob tool for schedules.

Phase 0 — Inspect Before Changing Anything

Before proposing changes, inspect only the active profile:

1. Use hermes config get onboarding if the CLI supports the key. If it is absent, do not treat that as an error; the profile can still use this skill.
2. Use hermes memory status to identify the active memory provider and whether it is installed.
3. Use hermes tools to view the current toolset selection. This is the supported interactive toolset configuration surface; do not hand-edit a nested toolset list merely to avoid the selector.
4. Call cronjob(action="list") before creating any recurring job. Look for existing jobs with the same purpose, schedule, or name.
5. If the user mentions a specific integration, inspect the installed skill inventory with skills_list() or search the active profile's skills/ directory. Do not assume that a desktop application or account is installed because a skill exists.

Report the starting state briefly. Do not dump credentials, full environment files, private account data, or the entire skill library.

Phase 1 — Ask the Human Questions

Use this order, adapting to answers already given.

Do not stop after the identity answers. Work through every group below in one continuous pass — Identity → Main jobs → Memory → Notes → Capability boundaries → Toolset walkthrough — feeding each answer into the next. Do not pause to ask "should I continue?" and do not wrap up after the first couple of answers. The setup plan comes at the end (Phase 2), not after the first question group. Completing only the identity questions is an abandoned onboarding, not a finished one.

Identity

Ask:

• "What should I call you?"
• "What would you like to call me?"
• "Do you prefer concise, conversational, formal, or highly detailed replies?"

If the user skips a question, use a neutral default and say what was assumed. Store identity and style only in the active profile after approval; do not write them into the public package.

Main jobs

Ask what the assistant is mainly for. Offer plain-language choices:

• Research and current web answers
• Writing and documents
• Personal organization and reminders
• Notes and knowledge management
• Coding and technical work
• Local files and computer tasks
• Voice conversations
• Business or professional workflows

The user may choose more than one. All toolsets are already enabled by default in this profile, so the goal is to confirm what they'll use and peel back the rest — not to build up from nothing.

Memory

Ask whether the user already has a memory provider set up:

"Do you already have a memory provider configured — Mnemosyne, Honcho, Mem0, or something else — or should I set one up?"

• If they have one (or want to pick their own): run hermes memory setup and let them authenticate through the provider's own flow. Do not switch providers silently.
• If they don't (or are unsure): recommend Mnemosyne — it is the provider this profile's skills are written around (hermes-mnemosyne, mnemosyne-maintenance), it is profile-scoped and local-first, and it needs no external account. Offer to set it up:
  • enable profile memory with hermes config set memory.memory_enabled true and hermes config set memory.provider mnemosyne,
  • verify with hermes memory status.
  • Keep Mnemosyne data profile-scoped; do not expose it as a cron toolset.
• If they prefer no persistent memory: disable it with hermes config set memory.memory_enabled false.

If Mnemosyne is unavailable on their install, report that exact status and offer the supported setup path (hermes plugins install mnemosyne or hermes setup plugins); do not invent a package name or installation command.

Notes and Obsidian

Ask:

"Do you already use Obsidian or another notes system?"

If yes, ask which system and, for Obsidian, which vault the user wants to connect. Do not read the vault before the user identifies and approves it. Check whether the corresponding skill is already present with skills_list().

• If the skill is bundled, enable/use it; do not reinstall a copy.
• If it is missing, show the exact skill name and ask before running hermes skills install <name>.
• Installing or enabling a skill does not install the Obsidian desktop application.
• Treat the vault path as private profile configuration, never as a package default.

Capability boundaries

Ask only about capabilities relevant to the user's goals:

• Web research: web search and source retrieval.
• Browser automation: website interaction; explain that browser access is broader than web search.
• Local files: read and write files in approved locations.
• Terminal: run local commands; explain that this is a higher-trust capability.
• Voice: speech recognition and/or text-to-speech, subject to provider setup.
• Calendar, reminders, email, or other accounts: connect only the specific service requested, with the user completing authentication.

For persistent toolset changes, use hermes tools rather than guessing a configuration key. For a one-off session, use the documented hermes chat --toolsets "web,terminal" form when appropriate instead of changing the profile.

Toolset walkthrough — confirm what's on, peel back what they don't need

Every CLI toolset is already enabled by default in this profile, so the profile works out of the box the way a fully configured reference setup does. The walkthrough is not an install step — it is a review: tell the user everything is already on, then walk each toolset in plain language and ask whether they want to keep it or turn it off. Peel back only what they decline; leave the rest enabled.

First, show the current state so the user sees that everything is on:

hermes tools

Then walk the enabled set. For each, say what it's for and ask: "Keep <name> on, or turn it off?" Default to keeping it on if they're unsure.

Apply the approved adjustments through hermes tools — since everything starts enabled, this usually means turning off only the toolsets the user declined. Some toolsets only appear there when their dependency is present (an API key, a backend, a driver) — if a toolset the user wants is missing from the list, say so and move to its setup step rather than pretending it is enabled.

Web search backend (required for web to return results)

web needs a search provider. This is a global Hermes setting, not profile config — set it once and every profile uses it. Ask the user which they have:

• Self-hosted SearXNG — private, free, no key. Ask for their instance URL, then configure the web-search backend to use it. Never hardcode or assume an instance address.
• A hosted search API (Brave, Tavily, Exa, etc.) — ask them to complete the provider's own key flow; never take the key in chat.
• Not sure — point them to hermes setup, which walks the search-backend choice interactively.

Verify with a real query afterward (e.g. web_search("Hermes Agent")) and confirm results come back before calling it working.

Provider / model

Confirm the model provider works end-to-end. The profile defaults to deepseek; if the user uses another provider, set it and run one real chat turn to confirm the key is valid. Do not ship or assume any specific API key.

Reusing providers the user already configured. Many newcomers ran hermes setup once before cloning this profile, so a working provider and API key may already exist in their default profile or global config. Ask first — "Do you already have a model provider working in another Hermes profile?" — and offer to bring it over instead of making them re-enter a key:

• API keys live in .env, not config.yaml. A profile reads its own ~/.hermes/profiles/<name>/.env first, then falls back to the global ~/.hermes/.env. If the key is already in the global .env, this profile picks it up automatically — nothing to copy. Only add a profile-local .env when the user wants a different key for this profile than the global one.
• Never ask them to paste the key into chat. Point them to where it already is, or have them run hermes setup / edit .env themselves. Read-only confirmation that a key is present (e.g. hermes auth list) is fine; do not print the value.
• Provider/model selection is config, not a secret. Set hermes --profile donna config set model.provider <provider> and model.default <model> to match whatever already works, then verify with one real chat turn.
• Copying provider settings between profiles is fine; copying credentials is not something the agent does for them. If they want the same custom-provider block (base_url, etc.) that exists in their default profile, walk them through re-adding it here with hermes config set rather than editing another profile's files — keeping with the rule that setup stays local to the active profile.