How to Make Hermes Understand How You Work

The reason most people never see Hermes learn anything is not a configuration problem. It's a repetition problem. The learning loop needs the same kind of task done two or three times before it has anything to extract - and most people do each task once, in a different way, and wonder why nothing stuck.

There is also a second reason, which is less obvious: Hermes has nowhere to store context about you unless you give it somewhere. Three files hold the learning. Most people never fill them in.

Both of these are fixable in an afternoon.

Before you touch any task, open these three files:

~/.hermes/memories/MEMORY.md - the stable facts about your work. What you produce, who you produce it for, what context any task assumes. Without this, every session starts from scratch regardless of how many times you've done the work.

~/.hermes/memories/USER.md - the stable facts about you. Timezone, working patterns, preferred output formats, recurring projects. This is where corrections you make in real conversations get refined over time.

~/.hermes/SOUL.md - voice and personality. Tone, length, what to avoid, how to open responses. You set this deliberately.

Sessions are stored in SQLite and are full-text searchable across conversations. Skills live at ~/.hermes/skills/ as plain markdown files. Hermes ships with 123 of them before it writes one custom skill - GitHub workflows, Obsidian, Google Workspace, Linear, Notion, Typefully, browser control, and more. You are building on top of an existing library, not starting from scratch.

Fill in MEMORY.md and USER.md before doing anything else. An agent with no context about who it is working for produces generic skills. The time investment is maybe 20 minutes, and it affects every session afterward.

A skill is a markdown file. Name, description, procedure, quality standard, common mistakes. When Hermes recognizes a task matches one, it pulls the file into context and follows the procedure instead of reasoning through the task from scratch.

A real one looks like this:

Because it is a plain file, you can read it, edit it, delete it, or write one yourself if you want to skip the automatic version. Nothing about it is opaque once you look at one.

Pick something you already do more than once. A weekly summary in a specific format. A document you review the same way each time. A research brief you pull together before writing something longer.

Do not pick something you have only done once as a test. The whole method depends on Hermes seeing a real pattern across real sessions, not a single invented example you staged.

Open a session and run the task in full detail, as if this were the only time you would ever ask.

Do not mention you are planning to build a skill. Do not compress the request to save tokens. The first pass is the raw material — whatever you skip here will be missing from the eventual skill file.

Come back a few days later, when the task naturally comes up again, and run it in a new session. If anything about how you wanted it done differs from the first time, say so directly.

Corrections here matter more than the original request. "Keep this part shorter" or "don't include the section on X unless I ask" tells Hermes exactly where its first read of the task was wrong. Run it a third time if you can. Three instances gives it a defensible pattern. Two is usually enough.

Once you have done the task two or three times, ask directly:

Hermes pulls from your actual conversation history - not a fresh description you type out - and drafts a markdown file describing the procedure as it understood it from watching you correct and refine the task across real sessions. The resulting file is usually more accurate than anything you would write from memory, because it includes the corrections you made in the moment rather than the idealized version you would reconstruct afterward.

The first draft is rarely exactly right. Check whether it captured the actual order of steps, included your corrections, and whether the common mistakes section reflects something real rather than generic filler.

If something is off, tell Hermes what specifically:

One or two rounds of this usually produces a file that is genuinely accurate. And one practical detail worth knowing: changes to skill files take effect on new sessions only. After correcting a skill, type /new before testing whether the update landed.

The skill lives at ~/.hermes/skills/ on Mac and Linux, or C:\Users\[YourUsername]\.hermes\skills\ on Windows. Confirm it is there.

To use it:

That request is shorter than the one in Step 2. The procedure is stored. You are not re-explaining anything you already worked out.

The same pattern works for how you write, not just what you do. A skill that knows the right procedure but produces output in the wrong voice still needs editing — and that is a different problem from an inaccurate procedure.

The method that actually works: feed examples first, not rules.

Before writing any SOUL.md, send Hermes 10 to 15 of your strongest pieces of content. Tell it:

Then ask for a sample in your style, correct what is wrong, and repeat three or four times. After that:

The SOUL.md it produces from real examples is more accurate than one you write from scratch. You know what you think you do. The file knows what you actually do. These are not always the same thing, and the gap is where the editing time goes.

Not every skill should run on a schedule immediately. Some need to prove themselves first.

Run the task two or three times in real sessions, correcting drift each time. Let Hermes draft the skill from those sessions. Correct the draft. Run it a few more times with the skill active and see whether it holds. Only then decide what should run automatically and what should stay manually triggered.

The principle behind this is simple: you cannot write a production-ready skill from scratch because you do not know what you will need to correct until you have corrected it. The automatic version is not better because it is easier - it is better because it is built from the friction points you actually encountered, not the ones you predicted.

If you do meaningfully different kinds of work - content creation, client communication, code review - you probably do not want all of those skills in one context. A skill written for structuring newsletter guides will not behave correctly in a client proposal session.

Profiles give each kind of work its own memory, skills, and SOUL.md on a single install:

The newsletter profile learns how you structure guides. The client-work profile learns how you structure proposals. They do not share a skill library, so they do not contaminate each other. Same underlying model, different learned behaviors per context.

Skills come back too generic. Usually means not enough real corrections were given during the task sessions. Run the task once more, correct whatever still feels off, then:

Hermes is not using the skill when you ask for the task. Reference it explicitly by name rather than assuming it will recognize the pattern. If it still does not pull the file in, check that the skill saved correctly in the skills folder.

The skill worked for a while and then started to drift. Workflows change, files do not update themselves. Every few weeks:

If MEMORY.md and USER.md are empty: fill those in today before doing anything else. The steps above produce better results when the agent already knows who it is working for.

If you already do a task often but have never asked Hermes to turn it into a skill: skip to Step 4. You likely have enough conversation history for it to draw from.

If you tried writing a skill by hand and it felt wrong: that is because it was wrong. You cannot describe a procedure accurately before you have watched yourself correct it three times. Let this replace that attempt.

If this saves you from re-explaining the same task for the tenth time, send it to one person still typing the same instructions into a fresh chat every week.

That's all I'm asking.

Become a paying subscriber to get access to this post and all other premium content.