Skills — ทักษะที่เขียนตัวเองได้Skills — Procedural Memory That Writes Itself

Here is a question I have been circling since this series began: when an AI agent spends half an hour fighting through a deployment with a dozen hidden steps — two false starts, one error cascade, and finally a path that actually works — what should happen tomorrow, when the same job comes around again? Should it rediscover everything from zero, or should it write the proven procedure down as a skill and simply load it?

Readers of my OpenClaw for Organizations series already know the first half of the answer. In OpenClaw Skills I described skills as folders with a SKILL.md that tells the agent "this is how we do this kind of task" — a large win for consistency. But that model carries one quiet assumption: humans write the skills; the agent merely consumes them.

Hermes Agent from Nous Research — publicly launched on February 25, 2026, and sitting near 240,000 GitHub stars as I write — takes the step I find most interesting in its entire architecture: the agent writes its own skills through a tool called skill_manage, improves them while using them, and a background process called the Curator manages the lifecycle of what it wrote. The docs call this the agent's procedural memory, and the README compresses the philosophy into a single line: "The agent that grows with you." This sixth post in the series walks the whole system, from the anatomy of one skill to the governance question every organization must answer before letting the loop spin: who reviews the work of an agent that writes its own textbook?

1. Anatomy of a Skill: SKILL.md and the agentskills.io Standard

A Hermes skill is a folder whose heart is a SKILL.md file — Markdown with a YAML frontmatter block, following the open Agent Skills standard published at agentskills.io. The standard originated at Anthropic before being released openly, and the standard's site lists roughly forty adopting clients, including Claude Code, Claude, OpenClaw, Codex, Gemini CLI, and Hermes itself. The file format you are about to see is no longer any one vendor's private convention.

The minimum contract is deliberately light: only name and description are required. Everything Hermes-specific is namespaced under metadata.hermes — tags, category, related skills, toolset bindings, all the way up to a blueprint block that turns a skill into a cron-scheduled job:

---
name: server-health-report
description: Summarize daily server health from logs and metrics.
  Use when the user asks for a daily health report.
version: 1.0.0
platforms: [linux, macos]        # hide the skill per-OS
metadata:
  hermes:
    tags: [ops, monitoring]
    category: operations
    requires_toolsets: [shell]   # appear only when the toolset exists
    blueprint:                   # turn the skill into a cron job
      schedule: "0 7 * * 1-5"
      prompt: Run the daily health report and post it to the ops channel
---

# Server Health Report

## When to Use
## Quick Reference
## Procedure
## Pitfalls
## Verification

Note the body skeleton: When to Use → Quick Reference → Procedure → Pitfalls → Verification is the house order the Hermes developer guide prescribes — decision criteria first, the short path next, the detailed procedure in the middle, and a closing check that the work actually succeeded. Anyone who has written a runbook for human operators will feel at home immediately, because that is exactly what this is; only the target reader is an LLM.

The frontmatter does finer-grained conditional activation than it first appears. fallback_for_toolsets surfaces a skill only when a toolset is missing — the documented example is a duckduckgo-search skill that appears only on machines without the web toolset, a plan B that announces itself automatically. required_environment_variables and required_credential_files declare dependencies that can be checked before a run. On size limits, Hermes Atlas — a community project, not official documentation — puts the ceiling around one hundred thousand characters per skill; treat that as a third-party approximation.

2. Where Skills Live and How They Load: Progressive Disclosure

The home directory for skills is ~/.hermes/skills/, which the docs call "the primary directory and source of truth." It is organized by category, and each skill folder can carry a full supporting cast:

~/.hermes/skills/
└── operations/
    └── server-health-report/
        ├── SKILL.md          # the core — loaded only on demand
        ├── references/       # deep docs, loaded file by file
        ├── scripts/          # helper logic kept out of the manual
        ├── templates/
        ├── examples/
        └── assets/

Beyond the home directory there are project-local skills (.hermes/skills/ or .agents/skills/ inside a repo — trust-gated before loading) plus any external directories you declare in config, with precedence running project → local → external:

# ~/.hermes/config.yaml
skills:
  external_dirs:
    - /srv/shared-skills      # the team's shared skill library

The question every engineer asks next: with a library of hundreds of skills, why doesn't the context window explode? Hermes answers with three-level progressive disclosure:

• Level 1 — skills_list(): the agent sees only metadata (name plus description) for every skill, around 3,000 tokens total regardless of library size
• Level 2 — skill_view(name): the full SKILL.md loads for just the skill relevant to the task at hand
• Level 3 — skill_view(name, path): individual files under references/ load one at a time, exactly when a step needs the detail

On the human side, every skill is directly invocable as a slash command (/server-health-report), several skills can be stacked in one instruction, and skills group into bundles stored at ~/.hermes/skill-bundles/<slug>.yaml via hermes bundles create.

3. The Learning Loop: skill_manage, Triggers, and Telemetry

Now the heart of the post — the thing that separates Hermes's skills from every other system I have written about. The agent holds a tool called skill_manage: six operations for writing and revising its own skill library:

The docs name three triggers: (1) completing a complex task — the written threshold is a task involving five or more tool calls (I have found no documentation saying that threshold is configurable); (2) hitting errors or dead ends and eventually finding the path that works — the surviving path being the valuable artifact; and (3) being corrected by the user. After a large multi-step task, Hermes will often offer to save the approach as a skill — putting a human decision point exactly where it belongs.

Every use is logged as telemetry in ~/.hermes/skills/.usage.json — the field names below follow the docs; the values are illustrative:

{
  "operations/server-health-report": {
    "use_count": 14,          // times loaded into the prompt
    "view_count": 3,          // times the agent called skill_view
    "patch_count": 2,         // times modified via skill_manage
    "last_used_at": "2026-08-30T07:02:11Z",
    "created_at": "2026-06-14T09:41:00Z",
    "created_by": "agent"     // provenance marker — the Curator's key
  }
}

The created_by: agent marker is not set by skill_manage directly but by a background self-improvement review fork — a separate process that reviews work after the fact. That marker is the system's most important boundary: the Curator in the next section manages only skills carrying it. Skills you wrote by hand are never touched by the automation.

4. The Curator: A Lifecycle for Skills the Agent Wrote

Let an agent accumulate skills with nobody sweeping up and the endgame is a pile of files nobody dares delete — the same disease as the append-forever daily logs I criticized on the memory side of my OpenClaw series. Hermes's answer is the Curator: background maintenance that runs when the machine is quiet (defaults: check every 168 hours, after at least 2 hours of idle) and touches only skills marked created_by: agent.

Pinned skills and skills referenced by a blueprint/cron schedule are always skipped. The step beyond housekeeping — having an LLM consolidate near-duplicate skills — is opt-in and off by default, running on a separate model slot named auxiliary.curator:

# ~/.hermes/config.yaml
curator:
  interval_hours: 168      # weekly check
  min_idle_hours: 2        # only when the machine is truly quiet
  stale_after_days: 30
  archive_after_days: 90
  consolidate: false       # LLM merging — leave off until you trust it

The Curator's safety net is more complete than I expected. Before every run it snapshots the whole directory to ~/.hermes/skills/.curator_backups/<utc-iso>/skills.tar.gz (keeping the latest five), every mutation is recorded in an append-only ledger (.curator_ledger.jsonl), and a full set of manual controls exists:

hermes curator status            # last run's state
hermes curator run --dry-run     # rehearse — see what it would touch
hermes curator pin my-skill      # hands off this one, always
hermes curator restore my-skill  # bring back from the archive
hermes curator rollback          # revert to a prior snapshot
hermes curator ledger            # read the full mutation history

💡 My reading: the "never delete + ledger + dry-run + rollback" design says Nous understands its users' entirely legitimate fear — automation that touches an organization's knowledge store must always be auditable and reversible. That is the same bar we hold backup systems to, and I would like every agent framework to meet it.

5. /learn and Offline Evolution: Distilling Knowledge into Skills

Everything so far grows from the agent's own experience — but most organizational knowledge does not live in an agent's experience. It lives in documents, repositories, and conversations. Hermes fills that gap with /learn (covered by MarkTechPost on June 24, 2026): the live agent distills a knowledge source into a standards-compliant SKILL.md on the spot. Four source types are supported — a local directory, a URL, the conversation history, and pasted notes:

/learn ./docs/deploy-runbook     # distill a local directory
/learn https://example.com/guide # distill a web page
/learn                           # distill the current conversation
# or paste long notes, then issue /learn

Under the hood, /learn uses the agent's ordinary tools (read_file, search_files, web_extract), and when a source is too large for one SKILL.md it produces a knowledge-base skill: a lean SKILL.md acting as an index, plus reference files catalogued under references/ for progressive disclosure to load piece by piece as they are actually needed.

A second mechanism operates on an entirely different clock. The separate official repo hermes-agent-self-evolution does offline evolutionary optimization with DSPy + GEPA — reading execution traces to understand why tasks fail, generating eval datasets, then evolving candidate skill variants through mandatory gates: full test suites, a 15KB size cap, semantic preservation, and human review as a pull request, always. A run costs roughly $2–10 and needs no GPU (Phase 1, the current one, optimizes skill files only).

The two mechanisms differ philosophically, and the difference matters to organizations: /learn is the live agent writing immediately inside a conversation; self-evolution is a slow pipeline that ends with a human clicking merge. For any environment that must survive an audit, I consider the latter shape far easier for governance to accept.

6. Governance: write_approval, Security Scanning, and Trust Tiers

Hermes's default is that the agent writes skills freely, with no approval step — and this is where the community complains loudest. Users on Reddit and X report the agent effectively "approving its own errors," committing a wrong approach as a permanent skill, or patching over skills a human had carefully hand-tuned. (These are user reports, not official statistics — but they are consistent with the fact that Nous ships a complete set of countermeasures.)

# ~/.hermes/config.yaml
skills:
  write_approval: true     # every agent write goes through a person

With approval on, the agent's writes queue up like small pull requests you work through with four commands:

/skills pending          # the review queue
/skills diff a1b2        # open one diff — exactly like reviewing a PR
/skills approve a1b2     # accept into the library
/skills reject a1b2      # send it back

For an organization adopting this for real, I recommend a staircase rollout — do not switch everything on at once:

1. Observe: enable write_approval from day one, then let the agent propose skills into the queue without approving anything — you will see clearly what it "wants to write down," and how good its writing actually is
2. Review as routine: make working through /skills pending the same team discipline as your ordinary pull-request review rounds
3. Turn on the Curator: let the stale → archive cycle run, keeping consolidate off at its default
4. Only then consider consolidation: switch it on once you have enough ledger history to audit — and trust — the system's behavior

On the inbound side, every install through the Skills Hub passes a mandatory security scan — checking for prompt injection, data exfiltration, and destructive commands. A dangerous verdict is hard-blocked with no --force override. Project-local skills arriving with a repo are likewise scanned and quarantined at load time. Trust is tiered four ways — builtin / official / trusted / community — and NVIDIA's SkillEvaluator v0.1.0 can be layered on as an optional extra check.

I read this whole package as lessons extracted from OpenClaw's marketplace era — readers of that series will remember the malicious-skill headlines from that ecosystem. Hermes designed its inbound path fail-closed from the start (the full threat model gets its own treatment in #4 Security).

One last governance point that is easy to overlook: what happens to bundled skills at upgrade time? Hermes tracks origin hashes in ~/.hermes/skills/.bundled_manifest — if you have edited a bundled skill, your hand wins: updates skip user-edited files rather than silently overwriting them, and dedicated commands manage divergence or opting out entirely:

hermes skills reset my-skill --restore   # return to the upstream version
hermes skills opt-out --remove           # stop using bundled skills at all

7. Hand-Authoring and Sharing: Templates, Taps, and the Skills Hub

The autonomous loop may be the headline, but most real organizational work still starts with skills a person writes — and Hermes makes that path a disciplined craft. Per the developer guide:

1. Structure the body in the house order — When to Use → Quick Reference → Procedure → Pitfalls → Verification — with the most common workflow first
2. Reach for the lightest tool available: stdlib Python, curl, or tools Hermes already has — long helper logic goes into scripts/
3. Use the template tokens the system substitutes for you: ${HERMES_SKILL_DIR} resolves to the skill's own folder, ${HERMES_SESSION_ID} to the current session
4. Test in isolation before shipping it to real work:

hermes chat --toolsets skills -q "Use the server-health-report skill on this machine"

To make "good writing" concrete, here are the Quick Reference and Pitfalls sections I want to see in every skill — short, direct, and runnable as-is:

## Quick Reference
# full health sweep in one pass
./scripts/health.sh --all

# check a single service
./scripts/health.sh --service nginx

## Pitfalls
# - rotated logs move under /var/log/archive — sweep those too
# - never run --all during the backup window; the I/O numbers will lie

Sharing within a team runs two main ways — publishing straight to a repo, or a Homebrew-style "tap" that a teammate points at once and can install from ever after:

# author's side: publish the skill to GitHub
hermes skills publish skills/my-skill --to github --repo myorg/hermes-skills

# teammate's side: add the tap, install anything in that repo
hermes skills tap add myorg/hermes-skills

Inbound, the Skills Hub gathers several install source types under one command set (hermes skills browse / search / inspect / install / check / update):

My recommended workflow for anything external: inspect before install, always — read the details and the scan verdict before letting it onto the machine:

hermes skills browse              # explore the catalog
hermes skills search <keyword>    # find candidates
hermes skills inspect <name>      # read details + scan verdict first
hermes skills install <name>
hermes skills check               # any updates pending?
hermes skills update

On ecosystem scale: Hermes ships with well over a hundred built-in and optional catalog skills combined (the precise numbers shift with every release — I am deliberately not printing fixed counts), and community directories track many more, including meta-tooling built around the loop itself: hermes-skill-factory (a meta-skill that generates skills from workflows), SkillClaw (which evolves skill libraries from session data — around 2.5 thousand stars, per the community directory), and oh-my-hermes. All of it is community work, subject to the same scanning and the same judgment as any external skill.

💡 An observation from a teacher's chair: a well-written SKILL.md is excellent onboarding documentation for people too — the When to Use / Pitfalls / Verification skeleton forces a team's tacit knowledge onto the page. Even if no agent ever reads it, the organization walks away with a good runbook.

8. Portability: From OpenClaw In — and the Claude Code Gap

The question I have been asked most since this series opened: "can the skills we invested in on OpenClaw come along?" The good news is that this path is official — an optional skill named openclaw-migration provides a ready-made command:

hermes claw migrate --dry-run               # preview what would move
hermes claw migrate --execute --preset user-data
# skills are copied into ~/.hermes/skills/openclaw-imports/
# alongside conversion of SOUL.md, memory files, allowlists,
# and messaging settings

Note the word copied — the OpenClaw originals are untouched, which makes this ideal for a parallel trial while you are still deciding where to settle. (OpenClaw, for its part, publishes a reverse-migration guide in its own docs — this user base is genuinely being contested in both directions.)

Claude Code is the opposite story: there is no official import path. Open issue #35587 (filed May 30, 2026, priority P3, with no maintainer response as of this writing) requests a similar migration skill. The issue itself observes that SKILL.md is "mostly portable" but that hooks, commands, and plugin-level integration points differ between the two hosts.

The principle worth keeping: the agentskills.io standard makes the SKILL.md core — name, description, body, bundled files — portable across hosts, but each vendor's private extension namespace does not travel: Claude Code's execution-control frontmatter, OpenClaw's metadata.openclaw, and Hermes's metadata.hermes each stay home (a receiving host ignores metadata it does not recognize rather than erroring). The practical rule: skills move, but always test and re-add the destination's metadata — never believe "it just works" until you have watched it work.

The next post in the series — #7 Production — takes everything we have discussed onto real machines: hosting, upgrades, monitoring, and the operational lessons in between.