Why I want Hermes sessions to publish themselves

The worst documentation task is the one you only remember after the work is already done.

A Hermes session can contain the whole story: the goal, the tools used, the dead ends, the decisions, the files changed, and the final result. But if that history stays trapped inside a chat transcript, it is hard to reuse. I wanted the session itself to leave a trail.

That is the reason for the Hermes auto-publish hook.

The project page focuses on the implementation details: Hermes session auto-publish hook. This post is about why the hook exists.

The quick skim

• The session is already a work log. The hook turns it into a durable project artifact.
• Publishing should be automatic. Otherwise the best notes die as "I'll write this up later."
• The goal is a trail, not polish. A rough project page is better than invisible work.
• Knowledge compounds when the system captures work by default.

The pain

Agent sessions create useful operational memory, but most of it disappears.

You might solve a setup bug, choose an architecture, fix a deployment issue, or build a small tool. The transcript contains all the context. Then the session ends, and the next time you need that knowledge, you are back to searching memory, asking the agent, or reconstructing what happened from git diffs.

The loss is not just documentation. It is feedback. If sessions become visible project artifacts, patterns start to emerge: which tools keep appearing, which decisions repeat, which bugs recur, and which workflows are worth turning into durable skills. Invisible work cannot compound because the system has nothing to point at.

That is silly. The work already happened in a structured environment. The agent knows the goal, commands, outputs, and result. It should be able to emit a small project note automatically.

What the hook does

At the end of a Hermes session, the hook formats the session summary into Markdown and drops it into content/projects/.

The schema is intentionally small:

Field	Purpose
Goal	What the session tried to do
Decisions	The choices that changed the project
Outcome	What actually happened
Tools	The systems used to get there
Session ID	A trace back to the original work

If the session has no clear goal, the slug can fall back to a session-derived ID. That is fine. The point is not to produce a perfect case study every time. The point is to leave a searchable trail.

Why this belongs in Knowledge OS

Knowledge OS is not just a blog. It is a public memory system.

That means project pages should not only be polished launches. They should also capture infrastructure, experiments, and workflow improvements. The auto-publish hook makes that cheap enough to happen by default.

The subtle win is behavioral. If the system creates a first draft automatically, I can improve the artifact when it matters instead of starting from a blank page. That lowers the activation energy for documenting small but important work: a deployment fix, a pipeline decision, a new content convention, or an agent workflow that should be reused.

Over time, the project section becomes a build log: what was made, why it exists, how it works, and what changed.

Mental model

If a workflow depends on remembering to document later, it will fail.

The Hermes hook makes documentation the exhaust of doing the work. That is the important shift: capture first, polish later.