这是Hermes Agent最被低估的能力：它可以通过"技能文档"自我进化——每次你纠正它、教它新工作流、发现最佳实践，都能沉淀为可复用的Skill。本文从零带你创建第一个自定义Skill，含完整模板和避坑指南。
为什么Skill是Hermes Agent的「灵魂」
先说一个你肯定遇到过的场景：
你用Claude Code或Cursor写代码，每次都要重复说"请用pytest写测试、记得加type hints、代码风格用black"。你说了一遍又一遍，Agent每次都像第一次听到。
这不是Agent笨，是它没有「长期记忆」。大多数AI编程工具只有会话级上下文——对话结束，一切归零。
Hermes Agent的Skill系统彻底改变了这一点。
Skill本质上是一份Markdown文档（SKILL.md），放在特定目录下，Agent在每次会话启动时自动加载。它告诉Agent：
- 什么场景下该触发这个技能
- 触发后该执行什么步骤
- 每个步骤的完成标准是什么
- 有哪些常见的坑要避开
更重要的是——Skill是自我进化的。当你发现Agent反复犯同一个错误，不是去修改提示词，而是创建一个Skill来固化正确行为。Agent越用越聪明，不是比喻，是机制。
今天带你从零创建一个自定义Skill，全部代码可复制使用。
前置准备
确认Hermes Agent已安装：
hermes --version
# 应该输出 v0.19.0 或更高版本
第一步：理解Skill的文件结构
每个Skill由以下部分组成：
~/.hermes/skills/<category>/<skill-name>/
├── SKILL.md # 核心：技能定义（必需）
├── references/ # 可选：参考资料
├── scripts/ # 可选：辅助脚本
└── templates/ # 可选：模板文件
唯一必需的文件是 SKILL.md。其他目录按需创建。
第二步：编写SKILL.md（完整模板）
创建一个实战Skill：自动化代码审查清单。这个Skill会在你提交代码前自动检查常见问题。
mkdir -p ~/.hermes/skills/software-development/auto-code-review
创建 SKILL.md：
---
name: auto-code-review
description: "Use when the user asks you to review code, before committing, or when preparing a PR. Runs an automated checklist against Python/TypeScript code and reports findings."
version: 1.0.0
author: Your Name
license: MIT
metadata:
hermes:
tags: [code-review, quality, python, typescript]
related_skills: [test-driven-development, simplify-code]
---
# Auto Code Review
## Overview
Automated pre-commit code review that checks for common issues:
security vulnerabilities, type safety gaps, test coverage, and style violations.
Designed to be fast (< 30 seconds) and non-blocking.
## When to Use
- User says "review this code" or "check my code"
- Before `git commit` or `git push`
- Preparing a pull request
- User mentions "code review" in any context
Don't use for: architecture-level design review (use the `plan` skill instead).
## Review Checklist
Run each check in order. Stop and report after each failed check.
### 1. Security Scan (HIGH priority)
- [ ] No hardcoded API keys, tokens, or passwords
- [ ] No `eval()`, `exec()`, or `os.system()` with user input
- [ ] SQL queries use parameterized statements (no string concatenation)
- [ ] File paths are validated/sanitized (no path traversal)
### 2. Type Safety
- [ ] All function signatures have type hints
- [ ] No `Any` type unless absolutely necessary (must justify)
- [ ] Union types used where appropriate instead of `Optional` only
- [ ] Return types explicitly declared (no implicit `None`)
### 3. Error Handling
- [ ] Try/except blocks catch specific exceptions, not bare `except:`
- [ ] Error messages are user-facing and actionable
- [ ] No silent error swallowing (logging required if suppressed)
- [ ] External API calls have timeout and retry logic
### 4. Testing
- [ ] New functions have corresponding test cases
- [ ] Edge cases covered (empty input, None, large data)
- [ ] Tests are deterministic (no random seeds without setting)
- [ ] Mock external dependencies in unit tests
### 5. Style & Documentation
- [ ] Docstrings follow Google style for public functions
- [ ] No commented-out code (use git history instead)
- [ ] Variable names are descriptive (no single-letter except loops)
- [ ] Complex logic has inline comments explaining "why", not "what"
## Output Format
Report in this structure:
Code Review Report
Files: {count} files reviewed
Score: {passed}/{total} checks passed
🔴 Critical (must fix)
- {item}
🟡 Warning (should fix)
- {item}
🟢 Passed
- {item}
📊 Summary
{one-sentence summary with actionable next step}
## Common Pitfalls
1. **Being too strict on style** — auto-formatters handle style. Focus on logic/safety.
2. **Missing context** — a hardcoded key in a test fixture is fine. Flag it as warning, not critical.
3. **Review fatigue** — if > 10 issues found, report top 5 most critical only.
4. **Not checking the right files** — only review changed files in a PR context, not the entire repo.
## Verification Checklist
- [ ] All 5 review categories checked
- [ ] Output follows the Report format exactly
- [ ] No false positives on test files or config files
- [ ] Critical issues are truly blocking, warnings are truly optional
保存后，运行验证：
import yaml, pathlib
content = pathlib.Path(
"~/.hermes/skills/software-development/auto-code-review/SKILL.md"
).expanduser().read_text()
# 验证frontmatter
assert content.startswith("---")
parts = content.split("---", 2)
fm = yaml.safe_load(parts[1])
assert "name" in fm and "description" in fm
assert len(fm["description"]) <= 1024
assert len(content) <= 100000
print("✅ Skill validation passed!")
第三步：加载Skill到会话
有两种方式加载：
方式一：会话内动态加载
/skill auto-code-review
方式二：启动时预加载
hermes --skills auto-code-review
# 或加载多个
hermes --skills auto-code-review,test-driven-development
方式三：Cron任务自动加载
hermes cron create '0 9 * * *' \
--name "每日代码审查" \
--skills auto-code-review \
--toolsets file,terminal \
--model deepseek-v4-flash --provider deepseek
第四步：测试你的Skill
启动Hermes并加载Skill：
hermes --skills auto-code-review
在会话中测试：
你：帮我检查这段代码
def process(data):
result = eval(data)
conn = sql.connect("db.sqlite")
conn.execute("SELECT * FROM users WHERE id=" + str(result["id"]))
return result
Agent会按照Skill定义的5个检查类别逐一审查，并输出结构化的Review Report。
第五步：Skill的进阶技巧
掌握基础后，这些技巧能让你的Skill更强大：
技巧1：渐进式信息披露
不要在SKILL.md里塞所有内容。用引用文件分离：
## Detailed Checklists
For Python-specific checks, see [references/python-checklist.md](references/python-checklist.md).
For security patterns, load [references/security-patterns.md](references/security-patterns.md).
Agent只在实际需要时才加载详细参考资料，节省上下文。
技巧2：强引导词
与其写三句话解释一个概念，不如用一个强引导词：
❌ "Make sure you check every function one at a time, don't skip any..."
✅ "Tight loop: one function at a time, no skips."
Agent已经理解"tight loop"的含义——节省token，行为更可预测。
技巧3：可检验的完成标准
每个步骤必须能回答"怎么知道我完成了？"：
❌ Step: Review the code
✅ Step: Review the code → Completion: all 5 checklists reported,
no false positives on test files, output matches Report format
技巧4：Skill的分层架构
一个成熟项目的Skill体系应该是分层的：
Layer 1: 通用技能（代码审查、测试驱动、简化代码）
↓
Layer 2: 项目技能（Django规范、React组件模式、API设计约定）
↓
Layer 3: 团队技能（命名约定、分支策略、Review流程）
通用技能可以跨项目共享（Hermes Skills Hub），项目技能沉淀团队知识，团队技能固化流程规范。
避坑指南
坑1：Description写得太泛
❌ description: "Helps with code review"
✅ description: "Use when the user asks you to review code, before committing,
or when preparing a PR."
Description是Agent判断"什么时候该用这个Skill"的唯一依据。必须是触发条件，不是功能描述。
坑2：重复造轮子
创建Skill前，先检查是否已有类似功能：
ls ~/.hermes/skills/software-development/
hermes skills browse # 浏览Skills Hub
能扩展现有Skill就不要新建。Skill应该越用越少、越用越精。
坑3：写"正确的废话"
❌ "Be thorough in your review"
❌ "Follow best practices"
❌ "Pay attention to details"
这些句子不会改变Agent的行为——模型本来就会这样做。每句话都要问自己：删掉这句话，Agent的行为会不同吗？如果不会，删掉。
坑4：忘记文件所有权
创建Skill后，检查文件权限：
# 如果Hermes以hermes用户运行
chown -R hermes:hermes ~/.hermes/skills/software-development/auto-code-review/
权限不正确会导致Skill加载失败（静默失败，很难排查）。
坑5：Skill会过时
Skill描述的是"应该怎么做"，但当实际情况改变时，Skill就成了错误指导。建议每月检查一次：
# 列出所有自定义Skill
ls -la ~/.hermes/skills/*/*/SKILL.md
# 检查最后修改时间
find ~/.hermes/skills -name "SKILL.md" -mtime +30 -exec ls -la {} \;
超过30天未修改的Skill，应该重新验证是否仍然适用。
总结
Skill是Hermes Agent区别于其他AI工具的核心能力。它不是配置项，不是插件，而是一种让Agent自我进化的机制。
三个关键要点：
1. Skill的核心是触发条件×执行标准 — Description决定何时用，完成标准决定怎么做
2. 少即是多 — 与其写10个平庸的Skill，不如打磨3个精良的Skill
3. Skill会腐烂 — 每月检查、持续迭代，删旧比加新更重要
下一步行动：打开终端，用上面的模板创建你的第一个Skill。5分钟后，你的Agent就会比现在聪明一点。