On June 24, 2026, Nous Research shipped /learn, a new command in Hermes Agent that captures a workflow as a reusable skill without anyone hand-writing the SKILL.md. You point it at a folder, a URL, a past conversation, or pasted notes, and the agent does the reading, the structuring, and the saving. The result lands in ~/.hermes/skills/ and shows up as a slash command the next time you open the CLI, the dashboard, or the mobile gateway. For teams shipping mobile apps and AI agent automation, like the ones we build at Halmob, this is the piece that turns institutional knowledge into something an agent can run on its own.
The story in the June 2026 smol.ai newsletter cycle has been about orchestration layers — Sakana Fugu picked routing as the high-value layer, Vercel folded Fugu Ultra into its AI Gateway, and Nous kept pushing on the skills side of the same problem. Routing decides which model answers. Skills decide what the agent already knows how to do before any model is called. /learn closes the gap between "our team has a runbook" and "the agent has a skill."
The 30-Second Version
What /learn Actually Does
Hermes Agent is the open agent stack from Nous Research. Each skill is a folder with a SKILL.md file: YAML frontmatter on top, then a fixed section order — When to Use, Quick Reference, Procedure, Pitfalls, Verification. The format follows the agentskills.io open standard and uses progressive disclosure so the agent only loads the heavy sections when the skill is actually invoked. Before /learn, you wrote that file by hand.
/learn removes the hand-writing step without inventing a new ingestion engine. It builds a standards-guided prompt and hands it to the agent as a normal turn. The agent then reads local directories with read_file and search_files, fetches docs with web_extract, and saves the result with skill_manage. Because it is a normal turn, the same approval gates, audit logs, and tool permissions apply. The skill that comes out has a description under 60 characters, the standard section order, and Hermes-tool framing — it does not invent commands that do not exist.
The Four Sources It Reads From
| Source | What you give /learn | What the agent does |
|---|---|---|
| Directory | A path to a folder of code, docs, or PDFs | Walks the tree, extracts the procedure, writes SKILL.md |
| URL | A link to vendor docs or an API reference | Fetches with web_extract, distils the steps, writes SKILL.md |
| Past conversation | A reference to a prior agent turn | Replays the working steps, removes dead ends, writes SKILL.md |
| Pasted notes | Free text from a runbook or a Slack thread | Parses the intent, structures it to the house format, writes SKILL.md |
The four sources cover the four shapes team knowledge actually shows up in. Engineers write Markdown in repos. Vendor docs live on the web. Working procedures get discovered live in a chat with the agent. And the messy thirty percent that nobody has documented lives in Slack threads and pasted notes. /learn meets each of them where they are.
Why This Matters for Mobile Teams
Mobile teams pay a tax that web teams do not. A skill that needs to work on a phone has to handle flaky networks, foreground/background transitions, push delivery, and an OS that pauses your process at any moment. Writing that into a SKILL.md by hand means the senior engineer on the team writes it once, and then maintains it forever. /learn flips the cost: the engineer drives the agent through the procedure once in chat, calls /learn on that conversation, and the agent saves the skill in a shape any other engineer or any other Hermes session can run.
The mobile development work we ship at Halmob lives in this loop. A typical engagement has thirty to fifty repeatable procedures — release pipelines, store review workflows, SDK upgrades, crash-symbolication runs. Most of those used to live in a Notion page that drifted out of date the week after it was written. With /learn the same procedure becomes an executable skill that ships with the agent, runs across CLI and mobile gateway, and is versioned in the same place as the codebase.
Routing decides which model answers. Skills decide what the agent already knows how to do.
Where /learn Fits in an n8n Automation Stack
The other side of the Halmob stack is n8n automation. n8n already speaks to AI models over HTTP, and the bottleneck most teams run into is not the model — it is the per-customer procedure that lives outside the workflow. A finance customer wants the invoice node to call their vendor API in a specific order. A retail customer wants the inventory node to retry with backoff against a flaky SAP endpoint. Each of those is a skill, not a model swap.
With /learn that per-customer procedure is no longer a wiki page that an engineer reads before debugging a failed run. It is a SKILL.md the agent can invoke from inside an n8n step, and the skill itself was authored by the agent from the customer's own docs. The hard part of the integration moves from "write the runbook" to "point /learn at the runbook source." The production shape of this pattern, with queues and retries, is the same one we documented in our n8n on AWS ECS Fargate load test.
How /learn Compares to Writing SKILL.md by Hand
| Step | Hand-written SKILL.md | /learn-authored SKILL.md |
|---|---|---|
| Author | Senior engineer who knows the procedure | Agent, prompted by anyone on the team |
| Source material | Engineer remembers, then types | Folder, URL, chat, or notes you point at |
| Tool framing | Engineer reads the docs and gets it right | Agent uses only tools it actually has |
| Description budget | Easy to overshoot 60 chars and not notice | Enforced by the house authoring standard |
| Maintenance | Drifts when the procedure changes | Re-run /learn on the new source |
| Distribution | Copy-paste between engineers | Lands in ~/.hermes/skills/ for every Hermes surface |
The third row is the one that matters most in practice. Hand-written skills tend to invent commands that look reasonable but do not exist — an LLM problem the engineer often inherits because they were reading docs the same way the agent does. /learn closes that loop: the agent can only write skills that call tools it actually has, because the authoring run uses those tools and would notice if a command were wrong.
The Workflow We Recommend for a New Team
- 1Pick a procedure that already has a doc. The first /learn run should target a procedure with a written source. That gives the agent a clear extraction target and gives you a clean baseline to evaluate against.
- 2Drive the procedure once in chat. Walk the agent through it manually, with tool calls. This is the conversation /learn will replay later, so let the agent see the real steps and the real tool outputs.
- 3Call /learn on that conversation. The agent writes the SKILL.md and saves it via skill_manage. If you have the write-approval gate on, this is the moment you read what was written.
- 4Verify the skill from a fresh session. Open a new Hermes session, invoke the slash command, watch it run. A skill that does not survive a fresh session is a skill that captured the wrong context.
- 5Version the skills folder. Put ~/.hermes/skills/ under git for the team that owns it. Treat skill edits like code reviews — the same way you treat the prompts in your CI/CD pipelines.
- 6Re-run /learn when the source changes. If the vendor doc is updated or the runbook is rewritten, point /learn at the new version and let the agent re-author the skill. Diff the output against the previous version before merging.
- 7Audit the tool list quarterly. Hermes-tool framing assumes a stable tool set. When you add or remove a tool, scan the skills folder for references and re-author the affected skills.
Risks and Pitfalls Worth Designing Around
- Over-trusting first-pass output. /learn writes a SKILL.md that looks polished even when the procedure was wrong. The first read is on you, not on the agent. Keep the write-approval gate on for the first month.
- Skill sprawl. Every conversation can become a skill; that does not mean it should. A folder of 200 single-use skills is harder to search than a folder of 30 well-named ones. Curate.
- Source rot. A SKILL.md authored from a URL today will quietly drift when the URL is updated tomorrow. Capture the source URL and a timestamp in the frontmatter so re-runs are tractable.
- Tool-set drift. If your Hermes tool list changes, a skill authored against the old list will silently call a missing tool. The agent does not know yet that a tool went away.
- Permissions assumptions. A skill authored on a dev workstation runs as the engineer; the same skill on a CI machine runs as a service account. Read the Procedure section with that switch in mind before promoting the skill.
- PII in pasted notes. When the source is a Slack thread or a customer email, /learn sees whatever you paste. Strip PII before the paste; the agent will not strip it for you.
Where /learn Sits in the 2026 Agent Stack
| Layer | Recent 2026 example | Where /learn plugs in |
|---|---|---|
| Model | Claude Opus 4.8, Gemini 3.5 Flash | Untouched — the skill calls the model the agent already uses |
| Orchestration | Sakana Fugu, Vercel AI Gateway | Skills are the level above routing — pick which procedure runs |
| Skills | Hermes /learn, agentskills.io standard | The new authoring shortcut sits here |
| Runtime | Cloudflare Project Think, NVIDIA Project Arc | Hosts the durable execution that the skill triggers |
| Mobile surface | Hermes Workspace Mobile, Apple Messages for Business | Receives the skill as a slash command, runs it remotely |
We covered the mobile surface side of Hermes in the Hermes Workspace mobile orchestration write-up, the routing layer in the Sakana Fugu API piece, and the broader shift in the orchestration-era write-up.
When to Use /learn and When Not To
A Simple Decision Rule
How /learn Fits the Halmob Stack
Most of what we ship at Halmob lives at the meeting point of mobile apps, n8n automation, and AI agent orchestration. /learn lands inside the skills layer of the third column, and it changes how we onboard a new client. The old path was a two-week discovery: shadow the team, write the runbooks, wire them into the agent. The new path is one week: shadow the team, drive the agent through each procedure once, call /learn, review the skills with the customer. The second week becomes a buffer instead of a deadline.
For teams already running the OpenClaw stack or the executor-advisor pattern, /learn is the bridge between a working agent loop and a portable skill library. The loop stays where it is. The skills folder becomes the shared artefact the team actually edits.
The Bottom Line
Hermes Agent /learn is a small command with a large second-order effect. The small part is the convenience of not writing SKILL.md by hand. The large part is what changes once you stop: the skills folder starts to grow at the rate the team learns, not the rate the senior engineer has time to document. That is the shape of an agent stack that compounds.
The right question for the next sprint is not "should we hand- write a skill for this procedure." It is "what is the source of truth for this procedure today, and can we point /learn at it." At Halmob we pair mobile development with n8n automation and AI agent orchestration so teams that want that answer cleanly get a shorter one.
For sources, see the smol.ai AINews newsletter coverage of the June 2026 Hermes Agent updates, the MarkTechPost write-up on the /learn release, and the official Hermes Agent Skills System documentation.