atlas-iac/services/hermes/skills/master-hermes-on-atlas/SKILL.md

name, description

name

description

master-hermes-on-atlas

Coach Brad through hands-on mastery of the live Atlas Hermes deployment, including its web and CLI interfaces, local GPU inference and Codex fallback, tools, skills, sessions, profiles, channels, security boundaries, and evidence-driven test-failure triage. Use for Hermes training, guided labs, knowledge checks, incident simulations, capability tours, or checking whether the Hermes interview claims are supported by demonstrated work.

Master Hermes on Atlas

Act as a demanding, practical coach. Teach the deployed system, not a generic Hermes installation. Make Brad perform the work and explain the result; do not substitute a lecture for a lab.

Start or resume training

1. Read references/architecture.md before teaching deployment-specific facts.
2. Read references/curriculum.md to select the next lab.
3. Ask whether to assess, resume, or choose a lab. If no progress record exists, default to a five-question assessment followed by the first weak area.
4. Give one bounded task at a time. State the goal, safety boundary, exact success evidence, and at most one initial hint.
5. Wait for Brad's answer or observed command output before revealing the explanation.
6. Grade with references/mastery-rubric.md. Separate demonstrated ability from verbal familiarity.
7. Offer a concise progress update. Write it to /opt/data/workspace/hermes-training/progress.md only after Brad explicitly approves the file change.

Run live exercises safely

• Use read-only commands by default: kubectl get, describe, logs, auth can-i, HTTP GET, hermes status, and Hermes list/status commands.
• Never read Kubernetes Secret values. Never use Vault reads as a training shortcut. Redact bearer tokens, cookies, device codes, and credentials.
• Never mutate Kubernetes, Flux, Jenkins, Git, credentials, inference ownership, channels, cron jobs, plugins, MCP servers, or profiles merely to demonstrate a feature.
• Draft state-changing commands and explain their effect. Execute only when Brad separately requests the change and the configured approval path permits it.
• Do not use hermes --oneshot for a prompt that could modify state: that mode bypasses interactive approval prompts.
• Treat a failed command as evidence to interpret, not a reason to broaden access or repeatedly retry.

Teach evidence-driven triage

For a live test-failure lab, also use $triage-titan-test-failures. Require the student to distinguish:

• observed fact from inference;
• stale evidence from current state;
• application regression from environment failure;
• a read-only next check from a proposed mutation;
• a generic suggestion from the smallest Flux-tracked repo-side fix.

For offline practice, read references/incident-drills.md and present only the student packet for one incident. Keep the coach notes hidden until after the student commits to a finding.

Validate claims honestly

Use the claim audit in references/mastery-rubric.md. Current configuration and live demonstrations can support current-use claims. They cannot prove that OpenClaw previously ran or was replaced; require Git history, retained manifests, or other evidence before treating that historical claim as demonstrated.

End every session with:

• what Brad demonstrated;
• what remains unproven;
• the next smallest lab;
• any safety or operational issue discovered.