feat(skills): /learn — distill a reusable skill from anything you describe (#51506)
Open-ended skill learning across every surface. /learn <free text> takes a description of any source — a directory, a URL, the workflow you just walked the agent through, or pasted notes — and the live agent gathers it with the tools it already has (read_file/search_files, web_extract, the conversation, the pasted text), then authors a SKILL.md via skill_manage following the house authoring standards (<=60-char description, the standard section order, Hermes-tool framing, no invented commands). No engine, no model-tool footprint, works on any terminal backend (local, Docker, remote): /learn builds a standards-guided prompt and hands it to the agent as a normal turn. - agent/learn_prompt.py: shared standards-guided prompt builder - /learn registry entry (both surfaces) + CLI handler (inject onto input queue) + gateway handler (rewrite turn, fall through, /blueprint pattern) - tui_gateway command.dispatch returns a send directive -> TUI + dashboard chat - dashboard Skills page 'Learn a skill' panel (dir + URL + open-ended text) composes a /learn request and runs it in chat - docs (slash-commands ref + skills feature page), 11 targeted tests Inspired by OpenAI Codex's Record & Replay and the /learn concept from #47234 (dir-distillation engine); reworked to be open-ended and engine-free per review.
This commit is contained in:
parent
aaa2e2cb88
commit
e32ebc6aa2
11 changed files with 404 additions and 1 deletions
|
|
@ -89,6 +89,7 @@ Type `/` in the CLI to open the autocomplete menu. Built-in commands are case-in
|
|||
| `/skills` | Search, install, inspect, or manage skills from online registries. Also the review surface for the skill write-approval gate: `/skills pending`, `/skills diff <id>`, `/skills approve <id>`, `/skills reject <id>`, `/skills approval on\|off`. See [Gating agent skill writes](/user-guide/features/skills#gating-agent-skill-writes-skillswrite_approval). |
|
||||
| `/memory [pending\|approve\|reject\|approval]` | Review pending memory writes staged by the write-approval gate (`memory.write_approval`) and toggle the gate. See [Controlling memory writes](/user-guide/features/memory#controlling-memory-writes-write_approval). |
|
||||
| `/bundles` | List configured skill bundles — `/<name>` slash aliases that preload several skills at once. Configure under `bundles:` in `~/.hermes/config.yaml`. See [Skill Bundles](/user-guide/features/skills#skill-bundles). |
|
||||
| `/learn <what to learn from>` | Distill a reusable skill from anything you describe — a directory, a URL, the workflow you just walked the agent through, or pasted notes. Open-ended: the agent gathers the sources with its own tools and authors a `SKILL.md` following the house authoring standards. Works in the CLI, the messaging gateway, the TUI, and the dashboard Skills page. |
|
||||
| `/cron` | Manage scheduled tasks (list, add/create, edit, pause, resume, run, remove) |
|
||||
| `/suggestions [accept\|dismiss N\|catalog\|clear]` (alias: `/suggest`) | Review suggested automations. Use `/suggestions` to list pending suggestions, `/suggestions accept <id>` to create the proposed automation, `/suggestions dismiss <id>` to reject one, `/suggestions catalog` to add curated starter automations, and `/suggestions clear` to clear resolved suggestion records. Accepted jobs preserve the current surface as the delivery origin. |
|
||||
| `/blueprint [name] [slot=value ...]` (alias: `/bp`) | Set up an automation from a blueprint template. Bare `/blueprint` lists the catalog; `/blueprint <name>` starts a guided slot-filling flow on the next agent turn; `/blueprint <name> slot=value ...` creates the job directly. |
|
||||
|
|
@ -249,7 +250,7 @@ The messaging gateway supports the following built-in commands inside Telegram,
|
|||
- `/skills` is **CLI-only for search/browse/install**; its write-approval review subcommands (`pending`, `approve`, `reject`, `diff`, `approval`) also work on messaging platforms when `skills.write_approval` is on. `/memory` works on **both** surfaces.
|
||||
- `/verbose` is **CLI-only by default**, but can be enabled for messaging platforms by setting `display.tool_progress_command: true` in `config.yaml`. When enabled, it cycles the `display.tool_progress` mode and saves to config.
|
||||
- `/sethome`, `/update`, `/restart`, `/approve`, `/deny`, `/topic`, `/platform`, and `/commands` are **messaging-only** commands.
|
||||
- `/status`, `/version`, `/background`, `/queue`, `/steer`, `/voice`, `/reload-mcp`, `/reload-skills`, `/rollback`, `/debug`, `/fast`, `/footer`, `/curator`, `/kanban`, `/credits`, `/suggestions`, `/blueprint`, `/sessions`, and `/yolo` work in **both** the CLI and the messaging gateway.
|
||||
- `/status`, `/version`, `/background`, `/queue`, `/steer`, `/voice`, `/reload-mcp`, `/reload-skills`, `/rollback`, `/debug`, `/fast`, `/footer`, `/curator`, `/kanban`, `/credits`, `/suggestions`, `/blueprint`, `/learn`, `/sessions`, and `/yolo` work in **both** the CLI and the messaging gateway.
|
||||
- `/voice join`, `/voice channel`, and `/voice leave` are only meaningful on Discord.
|
||||
- In the TUI, `/sessions` shows live sessions in the current TUI process. Use `/resume [name]` or `hermes --tui --resume <id-or-title>` for saved or closed transcripts.
|
||||
|
||||
|
|
|
|||
|
|
@ -71,6 +71,42 @@ hermes chat --toolsets skills -q "What skills do you have?"
|
|||
hermes chat --toolsets skills -q "Show me the axolotl skill"
|
||||
```
|
||||
|
||||
## Learning a skill from sources (`/learn`)
|
||||
|
||||
`/learn` is the fast way to turn something you already know — or a pile of
|
||||
reference material — into a reusable skill, without hand-writing the
|
||||
`SKILL.md`. It is open-ended: point it at *anything you can describe* and the
|
||||
agent gathers the material with the tools it already has, then authors a skill
|
||||
that follows the [house authoring standards](#skillmd-format) (≤60-char
|
||||
description, the standard section order, Hermes-tool framing, no invented
|
||||
commands).
|
||||
|
||||
```bash
|
||||
# A local SDK or doc directory — read with read_file / search_files
|
||||
/learn the REST client in ~/projects/acme-sdk, focus on auth + pagination
|
||||
|
||||
# An online doc page — fetched with web_extract
|
||||
/learn https://docs.example.com/api/quickstart
|
||||
|
||||
# The workflow you just walked the agent through in this conversation
|
||||
/learn how I just deployed the staging server
|
||||
|
||||
# Pasted notes / a described procedure
|
||||
/learn filing an expense: open the portal, New > Expense, attach the receipt, submit
|
||||
```
|
||||
|
||||
Because the live agent does the sourcing, `/learn` works the same in the CLI,
|
||||
the messaging gateway, the TUI, and the dashboard — and on any terminal backend
|
||||
(local, Docker, remote), since there is no separate ingestion engine. In the
|
||||
**dashboard**, the Skills page has a **Learn a skill** button that opens a panel
|
||||
with a directory field, a URL field, and an open-ended text box; it composes a
|
||||
`/learn` request and runs it in chat.
|
||||
|
||||
There is no model-tool footprint: `/learn` builds a standards-guided prompt and
|
||||
hands it to the agent as a normal turn. The agent saves the result with the
|
||||
`skill_manage` tool, so the [write-approval gate](#gating-agent-skill-writes-skillswrite_approval)
|
||||
applies if you have it on.
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
Skills use a token-efficient loading pattern:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue