Turn a Proven Workflow into a Hermes Skill with /learn

/learn <what to learn from> asks Hermes to gather source material and author a reusable SKILL.md. The source can be a directory, a URL, notes, or the workflow you just completed. This makes hard-won procedure available on demand without permanently stuffing every detail into the system prompt.

Official skills guide: https://hermes-agent.nousresearch.com/docs/user-guide/features/skills

Learn after evidence exists

A skill should capture a procedure that worked, not a speculative plan. Good candidates include a multi-step deployment, a repaired integration, a repeatable QA gate, or a tool-specific workflow with non-obvious failure modes. Stable personal preferences belong in user memory; temporary task progress belongs in the session; project rules often belong in AGENTS.md.

The command works in the CLI, messaging gateway, TUI, and dashboard Skills page. Give it a precise source and desired trigger so the resulting skill can explain when it should load.

Learning checklist

  • Confirm the workflow succeeded at least once.
  • Point /learn at the smallest sufficient source set.
  • Remove secrets, customer data, and temporary identifiers.
  • Define a clear “use when” trigger.
  • Include numbered steps, pitfalls, and verification gates.
  • Prefer durable commands over session-specific paths.
  • Inspect the generated SKILL.md before relying on it.
  • Test the skill in a fresh low-risk task.

Keep the skill maintainable

A useful skill is focused enough to load only when relevant and broad enough to survive the next project. Link supporting references rather than turning the main file into a raw log dump. When a tool or command changes, patch the skill promptly; stale procedural memory is worse than no skill.

Pitfalls

  • Learning from an unsuccessful or half-finished run.
  • Saving credentials, IDs, or customer artifacts in instructional text.
  • Writing a vague trigger that loads the skill for unrelated tasks.
  • Duplicating an existing skill instead of improving it.
  • Treating the generated draft as verified procedure.
  • Using a skill for facts that should be checked live.

Verification steps

  1. Open the generated skill and read its trigger, scope, and commands.
  2. Search it for secrets, private paths, and stale identifiers.
  3. Compare each command with current official documentation.
  4. Run a low-risk example from a fresh session.
  5. Confirm the skill loads for the intended task and stays out of unrelated work.
  6. Patch any missing pitfall or verification step discovered during the test.