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.

Most tests of a folder compare it to nothing: a fresh chat with no folder and no document. The folder wins, and we call that proof. I ran the case that usually gets skipped. Same model, same nine questions, three arms: - No document, no folder: 1/9 and 0/9. - The document pasted in, no folder: 9/9 and 9/9. - The full folder in a Claude Project: 9/9 and 9/9. On three held-out questions graded by hand, the document alone and the folder both scored 3/3. The folder's only measurable differences were its section tags and one safety sentence. The accuracy came from the document. That changed how I build. The folder earns its place when there is routing to do: several stages, several files, a reader who has to find the right one. For one reference document and a question, paste the document. The repo keeps everything, including three discarded runs and why they were thrown out. The commit order is the proof: the questions and the scorer were committed before any arm ran, so nothing was tuned to the result. Try it yourself: pick one folder you're proud of. Before you claim it helps, run the arm with just its main document pasted into a clean chat. If that ties, your folder's job is routing, and you can judge it on that. Question for the comments: has anyone run the document-only control on their own setup? I'd like to know whether mine was the odd one out. Free and open: github.com/NFTYoginis/jdm-the-control

I'm trying to figure out how to get more people to my website. It's not techy or an agency that builds for others. It provides encouragement and helpful information (products too) for women who are going through difficult seasons in life as well as some faith based content (gratitude, trusting God, etc.). I don't want to pitch to the folks who would use the material right now. I actually want to pitch to the people who know people who would benefit from the material. Does that make sense? Think: ministers, family counselors, support groups, hospice workers, etc. How do I do it in a way that doesn't seem salesy?

1 Chat, 1 Task: Reduce usage with clean context I guess most of you know that every message you send re-sends the whole conversation to your AI. Knowing it and seeing it are two different things, so I ran a test. One Claude Code session. I set a subagent to reply "ok" 200 times. One word in, one word back, every turn. Then Claude logged the tokens each turn actually sent. What came out: - 54,533 tokens before I typed anything. System prompt, my CLAUDE.md, rules, tool list. That block rides along on every single turn. - Each "ok" added about 54 tokens. After 200 turns the context was at 65,294. - 12.1 million tokens processed in total. For 200 "ok"s. The growth per turn is tiny here because the replies were one word. In real work, every file it reads, every tool output and every long answer stays in the history. Each turn adds thousands of tokens, not 54, and all of it gets sent again with your next message. Most of it comes from cache, but it still counts against your usage. So the rule I follow, and the one I teach: 1 task, 1 chat. When the task is done, close it. New task, new chat. If you need to carry something over, ask for a short summary and start the next chat with it. Full test page with the charts (you can hover every turn): https://claude.ai/artifact/4sFX5n6LANUnWDPRNonifM How long do your chats usually run before you start a new one?