HAHermes Lessons

The Testing Academy · Masterclass · Hermes Agent

Hermes Agent Masterclass for QA.

Every module from the Hermes Agent overview, expanded into a full lesson: why it matters for QA, numbered instructions, the exact commands, and a drill to run right now.

Part 1 · 7 lessons Part 2 · 7 lessons Part 3 · 8 lessons Format · steps + drill

01 ~ part one ~

The Always-On QA Operator

Concepts first, commands as proof. Back to the Part 1 overview.

1.1

Agent vs Chatbot vs CLI

A ten-second test to classify any AI tool as chatbot, coding CLI, or agent.

  1. Start with the chatbot. Note it waits, answers, forgets, and cannot run tools or tests.
  2. Add the coding CLI. Use Claude Code or Codex for one repo, one session, no persistence.
  3. Now the agent. Run Hermes always-on: it schedules jobs, remembers, and messages you on any platform.
  4. Apply the 2 a.m. test. Ask which tool flags a red nightly build while you sleep: only the agent.

QA drill: List your three most repetitive QA chores and mark which fail the 2 a.m. test.

1.2

What Hermes Actually Is

Hermes is Nous Research's open-source, always-on, self-improving agent; this lesson installs and verifies it.

  1. Install with one line. Run the curl installer below; on Windows PowerShell use iex (irm https://hermes-agent.nousresearch.com/install.ps1).
  2. Start chatting. Run source ~/.bashrc, then hermes.
  3. Run the wizard. Use hermes setup (or hermes setup --portal), then pick a model with hermes model.
  4. Health-check like a tester. Run hermes doctor, check hermes status, upgrade with hermes update.
install and verify
# Linux / macOS / WSL2 / Termux
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes            # start chatting
hermes doctor     # diagnose the install
hermes status     # component status

QA drill: Install Hermes, run hermes doctor, and screenshot the output as environment-ready evidence.

1.3

Why QA Needs One

Maps your repetitive QA checks onto the four leverage patterns Hermes gives a tester.

  1. Pattern one: the always-on operator. Run Hermes on a VPS to send morning triage summaries to Slack or Telegram.
  2. Pattern two: the watchdog. Schedule zero-token scripts that deliver stdout verbatim and stay silent when empty.
  3. Pattern three: the second brain. Let Hermes remember suites and failures, then search its history for repeat bugs.
  4. Pattern four: the dispatcher. Message Hermes to run claude-code or opencode fixes and report back.
a taste of the operator pattern
# morning triage, scheduled (full build comes later in the course)
hermes cron create "0 7 * * *" "Read the newest Playwright report in ~/reports, group failures by suite, flag known flaky tests, send a 5-line summary"
# each run is a fresh session: the prompt must carry all context

QA drill: List one day's repeated checks and tag each as operator, watchdog, second brain, or dispatcher.

1.4

One Brain, Every Interface

One agent, one memory, reachable from terminal, Telegram, Slack, Discord, WhatsApp, Signal, or Email.

  1. Configure the gateway. Run hermes gateway setup and connect the platforms you want.
  2. Start it. Run hermes gateway start (on WSL, Docker, Termux: hermes gateway run), confirm with hermes gateway status.
  3. Prove it is the same brain. Run /status, /platforms, /skills, /model provider:model, or /new from any platform: same memory.
  4. Push from CI without an LLM. Use hermes send to push messages from scripts with no LLM call.
gateway + CI alerts
hermes gateway setup           # connect Telegram / Slack / Discord...
hermes gateway start
hermes gateway status
# from a CI step, no LLM involved:
hermes send "Nightly smoke suite is RED on staging" -t slack:#qa
hermes send "Build passed, 0 flaky" -t telegram

QA drill: Connect one platform and send Hermes a fake bug report from your phone.

1.5

Your Second QA Brain

Hermes stores its identity, memory, and skills under ~/.hermes; shape and back it up.

  1. Tour the brain. Run ls ~/.hermes: config.yaml, SOUL.md, skills/, sessions, memories, cron, logs.
  2. Shape SOUL.md. Edit ~/.hermes/SOUL.md to make Hermes a reproducibility-first QA operator.
  3. Feed it product knowledge. Tell Hermes your suites and flaky specs, then check /insights for what stuck.
  4. Back up the brain. Run hermes backup to zip ~/.hermes; restore with hermes import.
inspect and protect the brain
ls ~/.hermes                 # config.yaml SOUL.md skills/ sessions memories cron logs
cat ~/.hermes/SOUL.md        # the agent's identity, edit it for QA
hermes backup                # zip of ~/.hermes
hermes import                # restore on a new box

QA drill: Tell Hermes about one flaky test today, then ask about it in a fresh session tomorrow.

1.6

Runs Anywhere You Want

Hermes runs on six backends; a cheap VPS keeps your QA operator always on.

  1. Know the six backends. Run local, Docker, SSH, Singularity, Modal, or Daytona; a Dockerfile ships in the repo.
  2. Make the VPS move. Put Hermes on a cheap VPS so CI watching survives your laptop lid.
  3. Migrate with backup/import. Run hermes backup on the laptop, copy the zip, then hermes import on the VPS.
  4. Survive reboots. Run hermes gateway install for user level, hermes gateway install --system to survive reboot.
laptop -> VPS migration
# on the laptop
hermes backup                          # produces a zip of ~/.hermes
# on the VPS
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes import                          # restore the brain
hermes gateway install --system        # survives reboot
hermes gateway status

QA drill: Run hermes backup now and confirm the zip exists.

1.7

Operator + Coding Workers

Hermes drives Claude Code, Codex, or OpenCode as workers you dispatch from any platform.

  1. See the roster. Run hermes skills list or type /skills: find claude-code, codex, opencode, hermes-agent.
  2. Inspect a worker. Run hermes skills inspect claude-code, then hermes skills audit for a supply-chain check.
  3. Dispatch a QA job. From any platform, invoke /<skill-name> or ask for a fix, rerun, and summary.
  4. Add your own workers. Drop SKILL.md skills into ~/.hermes/skills/; hermes curator maintains them.
find and manage coding workers
hermes skills list                    # roster, note autonomous-ai-agents
hermes skills search opencode         # search registries (skills.sh, GitHub, ClawHub...)
hermes skills inspect claude-code     # read before you run
hermes skills audit                   # supply-chain check
# in chat, on any platform:
/skills                               # list
# then dispatch: "use claude-code to fix the flaky checkout spec and rerun it"

QA drill: Inspect the claude-code skill and draft the dispatch message you would send during an incident.

02 ~ part two ~

Install It: Laptop to VPS

Every command, in order. Back to the Part 2 overview.

2.1

One Line, Full Toolchain

One curl command installs Hermes plus uv, Python, Node.js, ripgrep, and ffmpeg.

  1. Run the installer. Paste curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash into any Linux, macOS, WSL2, or Termux shell.
  2. Reload your shell. Run source ~/.bashrc so the PATH change takes effect.
  3. Launch. Type hermes to drop straight into chat.
  4. Verify the tools. Check that rg --version and ffmpeg -version respond.
install and first contact
# one line, whole toolchain (Linux / macOS / WSL2 / Termux)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

# reload the shell so PATH picks it up
source ~/.bashrc

# start chatting
hermes

# spot-check the bundled tools
rg --version
ffmpeg -version

QA drill: On a clean VM, time the path from paste to first reply and record the reported tool versions.

2.2

Windows Without Admin Rights

Installs Hermes, plus a portable MinGit, entirely in your user profile without elevation.

  1. Open plain PowerShell. Use a normal window, not "Run as administrator".
  2. Run the one-liner. Execute iex (irm https://hermes-agent.nousresearch.com/install.ps1), user space only.
  3. Start Hermes. Open a fresh terminal and run hermes.
  4. Or use WSL2. Run the bash installer from 2.1 inside your distro instead.
windows, user space only
# PowerShell, normal user, no elevation
iex (irm https://hermes-agent.nousresearch.com/install.ps1)

# alternative: inside WSL2, use the bash installer instead
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

QA drill: Install with zero elevation prompts, then list what landed in %LOCALAPPDATA%\hermes, including MinGit.

2.3

First Run and Wizard

hermes starts chat instantly; hermes setup runs the guided configuration wizard.

  1. Enter chat. Type hermes and ask one question to confirm a round trip.
  2. Run the wizard. Exit and run hermes setup for guided model and provider configuration.
  3. Inspect the output. Open ~/.hermes/config.yaml to read what the wizard wrote.
  4. Learn chat commands. Use /status, /model provider:model, and /new inside any session.
two front doors
hermes          # front door 1: straight into chat
hermes setup    # front door 2: full interactive wizard

# then, inside a chat session:
#   /status                 current state
#   /model provider:model   switch models
#   /new                    fresh conversation

QA drill: Trace each wizard answer to the line it produced in ~/.hermes/config.yaml.

2.4

Models, Keys, or Portal

Supplies a model via your own provider key or one Nous Portal subscription.

  1. Pick a model. Run hermes model to choose provider and model.
  2. Authenticate. Run hermes login for the bring-your-own-key route.
  3. Or use Portal. Run hermes setup --portal for 300+ models plus the Tool Gateway.
  4. Verify and switch. Check hermes portal info, then swap models mid-chat with /model provider:model.
two routes to a brain
# route 1: your own provider and key
hermes model            # pick provider and model
hermes login            # authenticate that provider

# route 2: one subscription, 300+ models plus the Tool Gateway
hermes setup --portal   # Nous Portal OAuth flow
hermes portal info      # confirm what the Portal unlocks

QA drill: Feed one failing-test stack trace to two models via /model provider:model and compare the root-cause hypotheses.

2.5

Health and Home Directory

Three maintenance commands plus ~/.hermes, the one directory holding all agent state.

  1. Diagnose. Run hermes doctor whenever anything feels off.
  2. Check and update. Use hermes status for a pulse check and hermes update to upgrade.
  3. Tour ~/.hermes. Find config.yaml, SOUL.md, skills/, plus sessions, memories, cron, and logs.
  4. Read SOUL.md. Open the file that defines the agent's personality and identity.
health checks and the brain on disk
hermes doctor    # diagnose the install
hermes status    # component status at a glance
hermes update    # upgrade in place

ls ~/.hermes     # config.yaml  SOUL.md  skills/  sessions  memories  cron  logs

QA drill: After one short chat, match the log entries under ~/.hermes to what you saw in the session.

2.6

The Cheap VPS Move

Runs Hermes always-on on a server, reachable from Telegram or Slack.

  1. Install on the server. SSH in, run the 2.1 one-liner, then source ~/.bashrc.
  2. Wire up messaging. Run hermes gateway setup to connect Telegram, Discord, Slack, WhatsApp, Signal, or Email.
  3. Run it. Use hermes gateway run in the foreground or hermes gateway start in the background.
  4. Survive reboots. Install a service with hermes gateway install --system, then check hermes gateway status.
on the VPS
# same installer, new machine
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc

hermes gateway setup             # connect Telegram, Slack, Discord...
hermes gateway run               # foreground: watch it connect (WSL/Docker/Termux)
hermes gateway start             # background: shell stays yours
hermes gateway install --system  # system service, survives reboot
hermes gateway status            # confirm it is alive

QA drill: Reboot the VPS and confirm Hermes answers a Telegram message without you touching SSH.

2.7

Backup, Import, Docker

Migrates the agent by zipping ~/.hermes and restoring it on the new machine.

  1. Back up. Run hermes backup to zip ~/.hermes into one file.
  2. Restore in order. Copy the zip over, run the installer, then hermes import.
  3. Verify. Run hermes doctor and hermes status, then redo the 2.6 gateway steps.
  4. Pick a backend. Choose Docker, local, SSH, Singularity, Modal, or Daytona as the terminal backend.
laptop -> VPS migration order
# 1. on the laptop
hermes backup                       # zip of ~/.hermes

# 2. ship it
scp your-backup.zip user@vps:~/     # use the path hermes backup printed

# 3. on the VPS: install, then restore
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes import                       # restore the brain
hermes doctor                       # verify before going live

QA drill: Migrate to a second environment, then ask the restored Hermes about a pre-backup memory.

03 ~ part three ~

Run Your QA Day on It

Schedules, skills, and dispatch. Back to the Part 3 overview.

3.1

The Scheduled QA Morning

Hermes cron runs scheduled agent jobs in fresh isolated sessions and delivers results to chat.

  1. Pick a schedule form. Use '30m' once, 'every 2h' for intervals, or cron like '0 7 * * 1-5'.
  2. Write a self-contained prompt. Include the report path, suites, and what counts as a new failure.
  3. Create the job. Add --name, --deliver telegram, and --workdir for project context.
  4. Manage the fleet. Use hermes cron list, pause, or run to inspect, silence, or fire jobs.
the qa morning brief
# weekday morning triage, delivered to Telegram
hermes cron create "0 7 * * 1-5" \
  "Read the newest Playwright report in ./reports. List new failures vs known flaky, then end with a 3-line summary." \
  --name qa-morning --deliver telegram --workdir /home/qa/web-suite

# interval and one-shot forms
hermes cron create "every 2h" "Check ./reports for fresh failures and summarize" --name suite-watch
hermes cron create "30m" "Re-check the PROJ-142 repro after the deploy finishes"

# manage
hermes cron list
hermes cron run qa-morning      # fire now instead of waiting for 7am
hermes cron pause qa-morning

QA drill: Create a '30m' one-shot with --deliver telegram, then fire it early with hermes cron run.

3.2

Zero-Token Watchdogs

Scheduled scripts run without an LLM: stdout delivers verbatim, empty stdout means silence.

  1. Write the script. Put check-ci.sh under ~/.hermes/scripts/, printing only when something is wrong.
  2. Honor the silence contract. Print nothing on green, print an alert line on red.
  3. Wire it in. Schedule it with --script check-ci.sh --no-agent so stdout delivers verbatim.
  4. Test both paths. Run it by hand for the alert case, confirm silence on green.
the ci watchdog
# ~/.hermes/scripts/check-ci.sh : print ONLY when something is wrong
#!/usr/bin/env bash
fails=$(grep -c "FAILED" /var/log/ci/latest.log)
flaky=$(grep -c "Retry #2" /var/log/ci/latest.log)
if [ "$fails" -gt 0 ]; then echo "CI red: $fails failed specs"; fi
if [ "$flaky" -gt 3 ]; then echo "Flaky spike: $flaky second retries"; fi
# empty stdout = Hermes stays silent, and no LLM tokens are spent

hermes cron create "every 10m" --script check-ci.sh --no-agent \
  --name ci-watch --deliver telegram

QA drill: Schedule flaky-watch.sh with --no-agent to alert past a retry threshold, and verify silence on green.

3.3

Chained Triage Pipelines

Default --script mode injects script stdout into the agent prompt for automated triage.

  1. Script the suite run. Make run-smoke.sh print the result tail, failures first.
  2. Write the triage prompt. Tell the agent to group failures, flag flaky, propose next actions.
  3. Create the chained job. Schedule it before standup and route with --deliver slack:#qa-triage.
  4. Chain and push. Pipe job output onward with context_from, or push ad hoc with hermes send.
suite output -> triage prompt
# default --script mode: stdout is injected into the agent prompt
hermes cron create "0 6 * * 1-5" \
  "You are triaging smoke suite output. Group failures by feature area, flag new vs known flaky, propose one next action per failure, keep it under 15 lines." \
  --script run-smoke.sh --name smoke-triage \
  --workdir /home/qa/web-suite --deliver slack:#qa-triage

# manual push from any script or CI step, no LLM call
hermes send "Smoke triage posted, 2 new failures in checkout" -t slack:#qa-triage

QA drill: Chain your smoke script into a triage prompt that must name the worst failing spec file.

3.4

Drive It From Chat

The same slash commands work identically in the CLI and every messaging platform.

  1. Keep sessions clean. Use /new between unrelated bug hunts.
  2. Manage long threads. Shrink with /compress and check token spend with /usage.
  3. Switch models and skills. Use /model provider:model to swap models and /<skill-name> to invoke skills.
  4. Recover and reflect. Re-run the last answer with /retry and review learnings with /insights.
same commands, terminal or Telegram
# these behave identically in the CLI and in messaging chats
/model               # pick provider:model for this session
/skills              # list installed skills
/test-plan-generator PROJ-142    # invoke a skill by name
/usage               # token spend for the current thread
/compress            # shrink a long triage thread, keep the facts
/retry               # take another run at the last answer
/insights            # what Hermes has learned across sessions
/new                 # clean slate before the next bug

QA drill: From your phone, run /usage, /compress, then one installed QA skill in the same thread.

3.5

Kanban for QA Work

hermes kanban gives a durable SQLite board shared across profiles with atomic task claims.

  1. Initialize the board. Run hermes kanban init so every profile sees the same tasks.
  2. Feed the intake. Add one card per finding with hermes kanban create, prefixing titles by lane.
  3. Claim, comment, complete. Claim atomically, record repro notes with comment, then complete the card.
  4. Watch the flow. Use list, show, watch, and stats to monitor the queue.
a shared qa queue
hermes kanban init                    # durable SQLite board, shared across profiles
hermes kanban create "intake: checkout suite red on Chrome"
hermes kanban create "retest: PROJ-198 after the hotfix"
hermes kanban create "triage: login flake, 3 retries this week"
hermes kanban list                    # the whole queue at a glance
hermes kanban claim 2                 # atomic claim, no double-work
hermes kanban comment 2 "Repro confirmed on staging, trace attached"
hermes kanban complete 2

QA drill: Init a board, create a card per failed spec, then claim, comment, and complete one.

3.6

Install the QA Skill Suite

Skills are SKILL.md packages in ~/.hermes/skills/ that add QA powers to every device.

  1. Search the registries. Run hermes skills search bug-report across skills.sh, GitHub, and ClawHub.
  2. Inspect, install, audit. Read with hermes skills inspect, then install, then audit for supply-chain hygiene.
  3. Drop in the TTA suite. Unzip the 36-skill QA suite into ~/.hermes/skills/.
  4. Let the curator work. Run hermes curator for background skill maintenance.
stocking the toolbox
hermes skills search bug-report      # registries: skills.sh, GitHub, ClawHub
hermes skills inspect bug-reporter   # read the SKILL.md before trusting it
hermes skills install bug-reporter
hermes skills audit                  # supply-chain check on what you installed
hermes skills list

# drop the TTA 36-skill QA suite in one move
unzip tta-qa-skills.zip -d ~/.hermes/skills/
hermes skills list                   # test-plan-generator, bug-reporter, ...
hermes curator                       # background maintenance improves skills over time

QA drill: Search, inspect, and install a bug-report skill, then trigger it from chat with /<skill-name>.

3.7

Dispatch a Coding Agent

Built-in skills dispatch claude-code, codex, or opencode as workers, reporting back to your chat.

  1. Confirm the built-ins. Check /skills for claude-code, codex, and opencode.
  2. Write the task like a bug report. Give repo path, failing spec, error, and definition of done.
  3. Dispatch from anywhere. Message /opencode with the task from any connected platform.
  4. Demand verification. Require a suite run after the fix with the exact pass count.
phone -> coding agent -> report
# from Telegram on your phone, gateway running on the VPS
/opencode In /home/qa/web-suite, tests/checkout.spec.ts fails on
  page.locator('#pay-btn'). Find the current selector, fix the locator,
  run "npx playwright test tests/checkout.spec.ts", then reply with
  the pass count and the diff.

# same pattern with the other built-in workers
/claude-code Run the smoke suite in /home/qa/web-suite and summarize failures
/codex Add a data-testid to the coupon input and update the page object

QA drill: Dispatch /opencode to fix one broken locator and require the exact pass count in the reply.

3.8

The Wider Surface

Integration commands connect Hermes to your editor, CI, security audits, and MCP tools.

  1. Plug in tools with MCP. Manage external tool servers with hermes mcp.
  2. Reach it from your editor. Connect ACP clients like Zed via hermes acp.
  3. Ping from CI. Push messages or piped stdin with hermes send, no LLM needed.
  4. Audit and accept events. Run hermes security for OSV.dev audits and hermes webhook for inbound hooks.
the integration doors
hermes mcp                       # manage MCP servers (external tool surfaces)
hermes acp                       # ACP adapter: clients like the Zed editor

# CI failure path: instant ping, no LLM call
hermes send "suite red: 7 failed on main" -t telegram
npx playwright test | tail -20 | hermes send -t slack:#qa-alerts

hermes security                  # OSV.dev supply-chain audit
hermes webhook                   # inbound hooks from external systems

QA drill: Add hermes send "suite red" -t telegram to your CI failure path and confirm the ping.