New documentation for features that existed in code but had no docs:
New page:
- context-references.md: Full docs for @-syntax inline context
injection (@file:, @folder:, @diff, @staged, @git:, @url:) with
line ranges, CLI autocomplete, size limits, sensitive path blocking,
and error handling
configuration.md additions:
- Environment variable substitution: ${VAR_NAME} syntax in config.yaml
with expansion, fallback, and multi-reference support
- Gateway streaming: Progressive token delivery on messaging platforms
via message editing (StreamingConfig: enabled, transport, edit_interval,
buffer_threshold, cursor) with platform support matrix
- Web search backends: Three providers (Firecrawl, Parallel, Tavily)
with web.backend config key, capability matrix, auto-detection from
API keys, self-hosted Firecrawl, and Parallel search modes
security.md additions:
- SSRF protection: Always-on URL validation blocking private networks,
loopback, link-local, CGNAT, cloud metadata hostnames, with
fail-closed DNS and redirect chain re-validation
- Tirith pre-exec security scanning: Content-level command scanning
for homograph URLs, pipe-to-interpreter, terminal injection with
auto-install, SHA-256/cosign verification, config options, and
fail-open/fail-closed modes
sessions.md addition:
- Auto-generated session titles: Background LLM-powered title
generation after first exchange
creating-skills.md additions:
- Conditional skill activation: requires_toolsets, requires_tools,
fallback_for_toolsets, fallback_for_tools frontmatter fields with
matching logic and use cases
- Environment variable requirements: required_environment_variables
frontmatter for automatic env passthrough to sandboxed execution,
plus terminal.env_passthrough user config
9.7 KiB
sidebar_position, title, description
| sidebar_position | title | description |
|---|---|---|
| 3 | Creating Skills | How to create skills for Hermes Agent — SKILL.md format, guidelines, and publishing |
Creating Skills
Skills are the preferred way to add new capabilities to Hermes Agent. They're easier to create than tools, require no code changes to the agent, and can be shared with the community.
Should it be a Skill or a Tool?
Make it a Skill when:
- The capability can be expressed as instructions + shell commands + existing tools
- It wraps an external CLI or API that the agent can call via
terminalorweb_extract - It doesn't need custom Python integration or API key management baked into the agent
- Examples: arXiv search, git workflows, Docker management, PDF processing, email via CLI tools
Make it a Tool when:
- It requires end-to-end integration with API keys, auth flows, or multi-component configuration
- It needs custom processing logic that must execute precisely every time
- It handles binary data, streaming, or real-time events
- Examples: browser automation, TTS, vision analysis
Skill Directory Structure
Bundled skills live in skills/ organized by category. Official optional skills use the same structure in optional-skills/:
skills/
├── research/
│ └── arxiv/
│ ├── SKILL.md # Required: main instructions
│ └── scripts/ # Optional: helper scripts
│ └── search_arxiv.py
├── productivity/
│ └── ocr-and-documents/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── ...
SKILL.md Format
---
name: my-skill
description: Brief description (shown in skill search results)
version: 1.0.0
author: Your Name
license: MIT
platforms: [macos, linux] # Optional — restrict to specific OS platforms
# Valid: macos, linux, windows
# Omit to load on all platforms (default)
metadata:
hermes:
tags: [Category, Subcategory, Keywords]
related_skills: [other-skill-name]
requires_toolsets: [web] # Optional — only show when these toolsets are active
requires_tools: [web_search] # Optional — only show when these tools are available
fallback_for_toolsets: [browser] # Optional — hide when these toolsets are active
fallback_for_tools: [browser_navigate] # Optional — hide when these tools exist
required_environment_variables: # Optional — env vars the skill needs
- name: MY_API_KEY
prompt: "Enter your API key"
help: "Get one at https://example.com"
required_for: "API access"
---
# Skill Title
Brief intro.
## When to Use
Trigger conditions — when should the agent load this skill?
## Quick Reference
Table of common commands or API calls.
## Procedure
Step-by-step instructions the agent follows.
## Pitfalls
Known failure modes and how to handle them.
## Verification
How the agent confirms it worked.
Platform-Specific Skills
Skills can restrict themselves to specific operating systems using the platforms field:
platforms: [macos] # macOS only (e.g., iMessage, Apple Reminders)
platforms: [macos, linux] # macOS and Linux
platforms: [windows] # Windows only
When set, the skill is automatically hidden from the system prompt, skills_list(), and slash commands on incompatible platforms. If omitted or empty, the skill loads on all platforms (backward compatible).
Conditional Skill Activation
Skills can declare dependencies on specific tools or toolsets. This controls whether the skill appears in the system prompt for a given session.
metadata:
hermes:
requires_toolsets: [web] # Hide if the web toolset is NOT active
requires_tools: [web_search] # Hide if web_search tool is NOT available
fallback_for_toolsets: [browser] # Hide if the browser toolset IS active
fallback_for_tools: [browser_navigate] # Hide if browser_navigate IS available
| Field | Behavior |
|---|---|
requires_toolsets |
Skill is hidden when ANY listed toolset is not available |
requires_tools |
Skill is hidden when ANY listed tool is not available |
fallback_for_toolsets |
Skill is hidden when ANY listed toolset is available |
fallback_for_tools |
Skill is hidden when ANY listed tool is available |
Use case for fallback_for_*: Create a skill that serves as a workaround when a primary tool isn't available. For example, a duckduckgo-search skill with fallback_for_tools: [web_search] only shows when the web search tool (which requires an API key) is not configured.
Use case for requires_*: Create a skill that only makes sense when certain tools are present. For example, a web scraping workflow skill with requires_toolsets: [web] won't clutter the prompt when web tools are disabled.
Environment Variable Requirements
Skills can declare environment variables they need. When a skill is loaded via skill_view, its required vars are automatically registered for passthrough into sandboxed execution environments (terminal, execute_code).
required_environment_variables:
- name: TENOR_API_KEY
prompt: "Tenor API key" # Shown when prompting user
help: "Get your key at https://tenor.com" # Help text or URL
required_for: "GIF search functionality" # What needs this var
Each entry supports:
name(required) — the environment variable nameprompt(optional) — prompt text when asking the user for the valuehelp(optional) — help text or URL for obtaining the valuerequired_for(optional) — describes which feature needs this variable
Users can also manually configure passthrough variables in config.yaml:
terminal:
env_passthrough:
- MY_CUSTOM_VAR
- ANOTHER_VAR
See skills/apple/ for examples of macOS-only skills.
Secure Setup on Load
Use required_environment_variables when a skill needs an API key or token. Missing values do not hide the skill from discovery. Instead, Hermes prompts for them securely when the skill is loaded in the local CLI.
required_environment_variables:
- name: TENOR_API_KEY
prompt: Tenor API key
help: Get a key from https://developers.google.com/tenor
required_for: full functionality
The user can skip setup and keep loading the skill. Hermes never exposes the raw secret value to the model. Gateway and messaging sessions show local setup guidance instead of collecting secrets in-band.
:::tip Sandbox Passthrough
When your skill is loaded, any declared required_environment_variables that are set are automatically passed through to execute_code and terminal sandboxes. Your skill's scripts can access $TENOR_API_KEY (or os.environ["TENOR_API_KEY"] in Python) without the user needing to configure anything extra. See Environment Variable Passthrough for details.
:::
Legacy prerequisites.env_vars remains supported as a backward-compatible alias.
Skill Guidelines
No External Dependencies
Prefer stdlib Python, curl, and existing Hermes tools (web_extract, terminal, read_file). If a dependency is needed, document installation steps in the skill.
Progressive Disclosure
Put the most common workflow first. Edge cases and advanced usage go at the bottom. This keeps token usage low for common tasks.
Include Helper Scripts
For XML/JSON parsing or complex logic, include helper scripts in scripts/ — don't expect the LLM to write parsers inline every time.
Test It
Run the skill and verify the agent follows the instructions correctly:
hermes chat --toolsets skills -q "Use the X skill to do Y"
Where Should the Skill Live?
Bundled skills (in skills/) ship with every Hermes install. They should be broadly useful to most users:
- Document handling, web research, common dev workflows, system administration
- Used regularly by a wide range of people
If your skill is official and useful but not universally needed (e.g., a paid service integration, a heavyweight dependency), put it in optional-skills/ — it ships with the repo, is discoverable via hermes skills browse (labeled "official"), and installs with builtin trust.
If your skill is specialized, community-contributed, or niche, it's better suited for a Skills Hub — upload it to a registry and share it via hermes skills install.
Publishing Skills
To the Skills Hub
hermes skills publish skills/my-skill --to github --repo owner/repo
To a Custom Repository
Add your repo as a tap:
hermes skills tap add owner/repo
Users can then search and install from your repository.
Security Scanning
All hub-installed skills go through a security scanner that checks for:
- Data exfiltration patterns
- Prompt injection attempts
- Destructive commands
- Shell injection
Trust levels:
builtin— ships with Hermes (always trusted)official— fromoptional-skills/in the repo (builtin trust, no third-party warning)trusted— from openai/skills, anthropics/skillscommunity— non-dangerous findings can be overridden with--force;dangerousverdicts remain blocked
Hermes can now consume third-party skills from multiple external discovery models:
- direct GitHub identifiers (for example
openai/skills/k8s) skills.shidentifiers (for exampleskills-sh/vercel-labs/json-render/json-render-react)- well-known endpoints served from
/.well-known/skills/index.json
If you want your skills to be discoverable without a GitHub-specific installer, consider serving them from a well-known endpoint in addition to publishing them in a repo or marketplace.