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.

I built a small auditor that checks a marketing email against the CAN-SPAM rules and quotes the regulation for every finding. Every quote was verified, so I thought it was safe. The judges' feedback found the hole in one line: "a citation that resolves but points at the wrong thing is the exact failure this competition is hunting." My checker confirmed each quote existed somewhere in the reference files. It never checked that the quote sat under the section the finding cited. Cite the wrong section, keep the right words, and it still printed "quote verified". The rebuild checks each quote only inside the provision its citation names. Before writing any code, I committed eight questions taken from the feedback, so the test couldn't drift toward the answer. The original passes 2 of 8 and the rebuild passes 8 of 8. Those are questions I wrote myself, so the score isn't independent, and the repo says so. The results file also lists what's still weak. One check is a word list, and it gets "your account number is not needed" wrong because it can't read negation. I'd rather publish that than have someone find it. If you're running any AI step that cites a source (a policy, a contract, a style guide), the same hole is probably there. Checking that the words exist is the easy test. The useful one checks that they're where the citation says. Try it yourself: take one cited output, change only the section number, and run your check again. If it still passes, you're checking existence, not location. Question for the comments: what are you citing in your builds, and how do you check it? Free, MIT, nothing to sign up for: https://github.com/NFTYoginis/can-spam-auditor-rebuild