ONBOARDING — Team Hermes

Welcome! This guide gets you from zero to chatting with the shared team Hermes in ~10 minutes. It answers: what this is, how to connect, what to try first, and the house rules. Deeper connect details (screenshots of each step, troubleshooting) live in cli-desktop-onboarding.html.

What this is

A shared Hermes agent on a team VM (hermes.dev.360.gloo.com, AWS) with:

• Chat + full agent tools — terminal, files, web search/extract — running gloo-z-ai-glm-5.3 via the employer Gloo AI platform. You do NOT need your own API key.
• One shared brain — persistent memory for the whole team. Anything anyone teaches it (preferences, project context, conventions) is remembered for everyone. Tell it once, everyone benefits.
• GitHub access — a GitHub App bot identity (360-acceleration-hermes) can create issues, review PRs, and work with repos on your behalf.
• Skills — 8 seeded skill packs (github, code review, debugging, TDD, spike, planning, web search/scrape, containerized dev environments).
• Screenshots — headless Chromium on the VM: "run this app and show me what it looks like" works.

Built for: work-repo coding assistance, research, docs, and automation. (See PLAN.md for the project's constitution if you're curious.)

How to reach it (pick one)

Prerequisite for every path: your SSH public key must be on the VM. Send it to Chad once; he adds it. Then:

• Path A — Desktop app (recommended): install the Hermes desktop app, Settings → Gateways → Add connection → kind SSH → ubuntu@hermes.dev.360.gloo.com. The app tunnels over your SSH key, starts the backend on demand, and adopts the session automatically. Chats, sessions, memory all live on the VM.
• Path B — CLI over SSH (zero install): ssh -t ubuntu@hermes.dev.360.gloo.com hermes (tip: add an ssh alias hermes-team to your ~/.ssh/config). One-shot: ssh ubuntu@hermes.dev.360.gloo.com 'hermes chat -Q --query="..."'.
• Path C — manual tunnel (debugging only): ssh -N -L 19119:127.0.0.1:9119 ubuntu@hermes.dev.360.gloo.com then curl http://127.0.0.1:19119/api/status.
• Slack — coming (we hope): DMs to a bot in the GLOO workspace are planned but blocked on workspace-admin approval. Desktop/CLI work today.

Full step-by-step with troubleshooting for each path: cli-desktop-onboarding.html.

First commands to try (5 minutes)

Connect, then paste these one at a time and watch it work:

1. Memory — teach it something: Remember that our API review checklist requires a CHANGELOG entry. Then in a NEW chat: What does our API review checklist require? → it remembers. That's the shared brain.
2. Web — Search the web for the latest stable Node.js LTS version and summarize what changed.
3. GitHub — Look at the open issues in chad-russell/hermes-team-infra and summarize them. (uses the bot's GitHub identity)
4. Terminal — Show me disk and memory usage of this VM.
5. Screenshot wow-moment — Run scripts/screenshot-demo.sh on this VM and describe what the page looks like.

The shared brain — read this part

• Anything you tell it persists for everyone on the team, across sessions, on a company VM. That's the feature (organizational memory!) and the risk.
• ⚠️ Never paste secrets into chat: no passwords, API tokens, private keys, personal credentials, or anything you wouldn't put in a shared team doc. They land in the shared brain and session logs on the VM. Secrets for automation go through Chad (VM .secrets/, never chat).
• It's a shared resource — 3–5 concurrent users is the design size. Don't kick off hour-long background jobs without checking with the team, and close long-running sessions when you're done.
• Model + tools are work-funded (Gloo). Work use is the point; personal experiments are fine in moderation but don't make it a habit.

What to use it for (day-1 ideas)

• "Explain what PR #N in <repo> actually changes" (code-review skill).
• "Draft a test plan for this function: …" (TDD skill).
• "Spike: what would it take to X? Timebox 30 min, report back." (spike).
• "Summarize this article/thread/doc" (web-search-scrape).
• "Set up a containerized dev environment for <repo>" (containerized skill).
• Teach it team conventions once ("we always X") — next person gets them for free.

Requesting a new skill / capability

Skills are curated centrally (they're shared, so additions affect everyone):

1. Ask in chat: Is there a skill for X? (it knows what it has).
2. If missing, ping Chad with: what you want it to do + an example prompt you'd use. He'll write/port a SKILL.md and drop it in the VM's ~/.hermes/skills/ (no restart needed for the next session).
3. Same route for MCP servers / other integrations — never self-install on the VM as a member; config changes are admin ops (see RUNBOOK).

House rules (tl;dr)

1. No secrets in chat — shared brain, company VM.
2. Work stuff first; it's employer-funded.
3. SSH key = your access; don't share accounts.
4. Attribution: if you commit via the GitHub bot, have it note "on behalf of @you" so history stays sane (per-user gh auth belongs on your own machine).
5. Something broken? Ping Chad (see RUNBOOK "Escalation") — don't debug-ssh into the VM unless you're an admin.

Where to ask for help

• Can't connect: cli-desktop-onboarding.html troubleshooting section first (90% is SSH key issues), then Chad.
• Agent behaving oddly: Chad (admin) — RUNBOOK "Logs & diagnostics".
• Feature/capability requests: Chad (skill request flow above).