A short follow on for Hermes Agent, here is a copy of my rules for every agent I run. Copy it and feed it to your Hermes Agent, also I reccomend grabbing Jake van Clief's icm-architect skill found here -> https://github.com/RinDig/icm-architect This is how our ICM workspaces are organized on Hermes. Use it as your working standard whenever you build or reshape a workspace.
THE GOAL
A fresh agent with no chat history can find the job, the rules, the current state, the human gate and the next artifact from the files alone.
WHERE THE STANDARD LIVES
The canonical version is Jordan's ICM Workspace-Building Standard, in the LGIOS control plane at references/icm-workspace-standard/icm-workspace-standard.md. LGIOS holds it because LGIOS deploys every Hermes workspace. This prompt carries what you need from it.
WHERE THE FILES LIVE, AND WHY THERE ARE TWO
Each working folder carries a pair:
- AGENTS.md is the router. It says what this folder is and points to CONTEXT.md. About five lines.
- CONTEXT.md is the contract. It says how the work in this folder operates.
The split follows from how Hermes loads context:
- At session start, Hermes loads AGENTS.md from your working directory, /opt/data/workspaces. If the working directory is inside a git repo, it merges every AGENTS.md from the repo root down to that directory.
- When a tool touches a subfolder inside the working directory, Hermes adds that folder's AGENTS.md to the tool result.
- Hermes does not load CONTEXT.md on its own. AGENTS.md is the hook that gets it read.
So the router stays short because it lands in context on first touch, and the detail waits in CONTEXT.md until the work is actually in that folder. The router points to the contract and leaves the detail there, so there is one copy to keep true.
Hermes uses one project-context type, and the first with content wins: .hermes.md, then AGENTS.md, then CLAUDE.md, then .cursorrules. A .hermes.md in the working directory would shadow AGENTS.md, so the ICM pair runs on AGENTS.md.
WHAT LIVES OUTSIDE THE WORKSPACE
- SOUL.md at /opt/data is who the agent is. The workspace is where and how the work happens.
- Hermes memory holds preferences and durable personal facts. Stage state and handoffs live in files.
- Skills live in /opt/data/skills. A workspace skill folder counts only when it is configured as an external skill directory.
WHAT EACH HIGH-LEVEL FOLDER NEEDS
Workspace root
- AGENTS.md: where the work lives.
- CONTEXT.md: how the workspace operates and what each folder is for.
- Only the boot files sit at the root.
Job folder (one per job)
- AGENTS.md and CONTEXT.md, with one job per folder.
- One tree and one naming style. Stages live in one place and templates live in one place.
Numbered stage folders (01_intake, 02_build, and so on)
- AGENTS.md: "Read CONTEXT.md first. Run products go to the active run's output/ path."
- CONTEXT.md with five sections: Inputs (exact files and sources), Process, Outputs (path and format), Done when / human check, Write boundary.
- A stage is done when the declared artifact and its check both exist.
_shared/ and references/
- AGENTS.md and CONTEXT.md saying what is here and which stages use it.
- Stable inputs that every run draws on.
runs/
- AGENTS.md and CONTEXT.md explaining how a run is started.
- _template/ for starting a new run.
- <run-id>/ for each run: RUN.md (identity, scope, advancement mode, decision history), stage outputs, and HANDOFF.md (artifacts, verification, hold or advance, next reader).
- Advancement is gated by a named human. A scheduled job can collect and compare finished work, and a person moves the stage forward.
.agents/skills/
- Only when it is wired as an external skill directory for the profile.
Example shape:
workspace/
AGENTS.md
CONTEXT.md
01_intake/ AGENTS.md CONTEXT.md
02_build/ AGENTS.md CONTEXT.md
_shared/ AGENTS.md CONTEXT.md
runs/ AGENTS.md CONTEXT.md _template/ <run-id>/
Optional Kanban Plugin: If you know you know. It's a graph manager for work. I wouldn't start with it.
WORK ON THE KANBAN BOARD
The task carries assignee, status, comments and review. Its completion summary replaces HANDOFF.md. The task body points to the stage CONTEXT.md, and its workspace is the run folder. Stages are parent-linked tasks, and review is the human gate.
HOW TO KNOW IT WORKS
Run a cold walk from a fresh session: start at the root, follow the routers into one stage, read only the declared inputs, and produce the declared artifact and handoff. Repeat with one required input missing; the right result is a recorded blocker. If the walk fails, fix the files.