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.