The 21 Latest AI Agent Skills, Part 1: What Skills Are and How to Extend Them

These days, AI agents have something called skills. Precisely speaking, it is a single markdown file. Write a name and a description in a file called SKILL.md, and when a request comes in, the agent reads that description and finds and invokes the skill it needs on its own. In programming terms, it is like a function. The difference is that you do not call the function directly — the agent reads the description and calls it by itself.

Hermes Agent has 98 of these. They are scattered across 24 categories. Reading all of them takes a full day. So I kept 21 — the ones I use myself plus the ones that underpin delegating other work — and split them into 7 parts. This is Part 1.

First I need to lay out why skills matter. A skill is not syntax exclusive to a particular model. I scanned all 98, and every one is pure markdown with YAML frontmatter, and the only executable files are Python or shell. There is no code inside that calls a model. A field that specifies a model does not exist at all.

---
name: skill-name
description: One line on when to use this skill
version: 1.0.0
platforms: [linux, macos, windows]
---

Once you understand this structure, you can move it as-is to Claude, GPT, or any other agent. Of the ones I counted earlier, only 2 were Hermes-specific. The other 19 are used as-is on other agents.

1. hermes-agent-skill-authoring (v2.0.0)

The software-development category. The description says exactly what this skill is about.

Author in-repo SKILL.md files: frontmatter and structure.

This one falls in the camp of handling skills one at a time. It is the one that creates SKILL.md files directly. The version was bumped to 2.0.0, and validation got stricter so that a mistake means the skill does not load at all.

Why this matters

When you instruct an agent, the description field is effectively the trigger. You have to write down which requests should use this skill there, or the agent will not find it. Conversely, if the description is vague, the skill is never invoked even though it exists. This is why you can work hard to create a skill that nobody ever calls.

---
name: data-preprocessing
description: Use when reading CSV or Excel files and cleaning missing values
version: 1.0.0
platforms: [linux, macos]
---

The description has to include "use when…" to become a trigger. If you write it without knowing this rule, the name and description are off and the agent cannot find it. That is why this skill does a lot. If the format does not fit, it pinpoints which field is the problem.

The two places you put it

~/.hermes/skills/<category>/<name>/SKILL.md     personal, not shared
skills/<category>/<name>/SKILL.md              committed to the repo and distributed

Personal skills go in the personal folder, skills to distribute go in the repo. Mixing up the two means a rewrite. This skill pins down that distinction first.

2. plan (v2.0.0)

The software-development category. The description is short and clear.

Write a markdown plan to .hermes/plans/; no execution.

It is a mode that only makes a plan and does not execute it. It prevents the situation where a document you gave clear instructions for differs from what you intended, but you only find out after the agent has already modified the code.

The rules that actually matter

This skill enforces three rules.

- Do not implement code
- Do not touch project files other than the plan markdown file
- Do not run change commands such as commit or push

Read-only commands are fine. In the end, the deliverable is a single markdown page placed inside .hermes/plans/.

When to use it

You make the agent do this before writing code. There really are cases where the agent locks onto a wrong premise while making the plan. It is cheaper to get stuck at the planning stage than to trust a "here is how I will do it" and have it flip later.

3. computer-use (v2.1.0)

The autonomous-ai-agents category. The description is short, but the implications are big.

Drive the desktop background-first; escalate on signal.

This is a skill for controlling the desktop. It looks at the screen, clicks, and types. "background-first" in the description is the design philosophy of this skill. Before touching a window visible on screen, it first tries background-side means, and only escalates to the screen when those do not work.

Why this is special

The approach that most agent screen control takes is the pyautogui family. That actually moves the user's mouse cursor and steals keyboard focus. If the agent touches the browser while you are editing Excel, keys jump into Excel and cause an accident.

This skill is the opposite. It manipulates windows behind me. The user keeps typing in their own editor, and the agent works in a different window. In other words, a person does not have to give up their seat to the agent.

One practical pitfall

If you judge screenshots by numbers alone, you click the wrong thing. This skill tells you to read the accessibility tree (button names, labels, roles) along with them. You judge by seeing names. If you eyeball the screen alone, you press the wrong button.

Part 1 Summary

The three form a single axis. Create a skill, block before execution, and as a last resort handle the screen. This order matters — if the order is reversed, a person cannot keep up.

In the next part, we move on to delegating code and handing off verification.