What Is an Agent Skill? How to Write Skills That Work

Loading skills into AI agents has become a trend, and the world is now full of hundreds of them. A badly written skill either changes nothing or bloats the context and makes the work worse. In this article I go through the skill patterns that genuinely make a difference, how a good skill is written, and the security check you should run before you install anything.

This article summarizes and expands on Jack Roberts's video This New Hermes Agent Skill is Insane. In it, Roberts says he tested hundreds of skills for Hermes Agent, found most of them useless, and presents thirteen that stood out. The patterns here are picked from that list; the testing method and the skill-versus-rules-file distinction are additions of this post.

If you have never set up Hermes Agent, start with what Hermes Agent is and how to install it.

What is an agent skill?

An agent skill is a package of instructions that teaches an AI agent how to do a particular job. It does not change the model itself; it works as a directive file that kicks in when it is needed. I unpack that split between the model and the tool running it in what an AI harness is and how it differs from the model.

Here is where the benefit comes from: instead of guessing every time, the model follows a written procedure. The first time you get a job done well, you turn that procedure into a skill — and from then on you get the same quality every time.

Think of the agent as a very smart intern who is new to the job. The intelligence is there; what is missing is any knowledge of how you work. A skill fills exactly that gap.

The anatomy of a skill

A good skill has four parts, and each part does a different job:

• Name: short, and it says what the skill does. This is what the agent sees in the list.
• Trigger description: one or two sentences about when the skill should kick in. In practice this is the most decisive part.
• Procedure: the steps of the job. Written as a list of rules, with no explanatory narrative.
• References: long tables, examples, templates. Not embedded in the main file — kept separately and read only when needed.

Let me put extra weight on the second item, because that is where most useless skills fail.

How do you write a trigger description?

The agent decides which skill to invoke by reading the description. However good the procedure is, if the description is vague the skill never fires — or it fires in the wrong place.

Two examples:

• Weak: "Helps with writing."
• Good: "Use when drafting a blog post, a headline or a meta description. Do not use when editing existing text."

The second one states both the scope and what is out of scope. Writing that negative boundary is the cheapest way there is to prevent false triggering.

Before you install: the security check

This part gets skipped, and it should not be. A skill is text that gives instructions to your agent. If you accept a file you downloaded off the internet without reading what it tells your agent to do, you are leaving a serious hole open.

The first skill in the video does exactly this job: before a new skill is installed, it scans it, researches alternatives, and then allows it, asks you, or quarantines it. You can run the same check by hand. At minimum, do this before installing:

• Scan for prompt injection. Does the skill contain any directive that pulls the agent off its actual task, pushes it to leak data, or works around the steps where it should ask permission?
• What is it asking for? File access, network requests, connections to external services — which of these does it want, and why?
• Look at the alternatives. Is there a simpler or better-maintained skill that does the same job?
• Quarantine anything suspicious. Try it in a separate workspace, not straight in your main environment.

In short: treat a skill like a library dependency. If you would not drop a random package into your codebase, do not drop random instructions into your agent.

Skill patterns that genuinely work

Out of the hundreds out there, a handful of patterns hold lasting value. What they all have in common is that they cover a natural weakness of the model. The three patterns below are shown in the video with examples from Matt Pocock's open-source skills collection (grill-me, handoff and teach). The same approach applies to design work; I wrote that up separately in the seven levels of AI design.

Clarifying interrogation

The most expensive mistake an agent makes is doing a half-understood request quickly. This pattern forces the opposite: before the work starts, the agent asks you questions. Who is it for, under what constraints, what counts as success?

Simple, but the effect is large. When you say "I'm thinking about a new business idea, interrogate me about it," the questions that come back usually expose the weak spot in the idea before you have noticed it yourself.

The handover document

Moving from one agent to another, or from one session to the next, you end up explaining everything from scratch. This pattern writes the work into a structured document: current state, decisions made, next steps, recommended tools, and any sensitive information that needs care.

On long-running work the value of this is very high. Instead of squeezing a week of context into two paragraphs, you get a document you can genuinely hand over.

Teaching mode

Most people ask the agent a question, get a single-paragraph answer and stop there. This pattern turns the exchange into a lesson: first it establishes the goal (why are you learning this?), then it covers one topic at a time, and at the end it tests what stuck.

Here is the difference: information that is not tied to a goal gets forgotten. Asking "how do I grow on Instagram" and receiving a lesson built around your actual purpose, rather than a generic list, produces a completely different result.

How do you write a good skill?

The most valuable skill is the set of rules that lets you write other skills well. The video also presents a skill that writes skills (a skill creator); the principles behind it can be summarized like this:

• One job, one skill. The wider a skill's scope gets, the vaguer its trigger becomes, and the model starts invoking it in the wrong places.
• Keep the description short. A skill's definition is carried in the context on every turn. Every unnecessary word has a recurring cost.
• Load detail on demand. Instead of burying long references in the main file, put them in separate files and have them read only when needed.
• Write rules, not stories. A list of "do this" beats paragraphs of reasoning.
• Be directive. Models are probabilistic; sometimes they will not reach for the right skill on their own. On critical work, say explicitly which skill to use.

That last point is often misread. The agent does find the right skill most of the time — but "most of the time" is not a good enough guarantee for production work.

How do you test a skill?

Installing the skill you wrote and saying "seems to work" is not enough. It has to pass three tests:

1. The trigger test. Ask for the job by describing it, without naming the skill. Does it fire? If not, the description is weak.
2. The false-trigger test. Ask for a job that is outside the skill's scope but looks similar. It should not fire. If it does, the scope is too broad.
3. The repeat test. Run the same request three times, in three separate sessions. Are the three results close to each other? If not, the procedure is not specific enough.

The third test is the most informative. The whole reason a skill exists is repeatability; if it gives you three different results, it is not doing its job. I covered the design-side version of this same consistency problem in the critic loop.

While you test, watch not what the model does but what it does and why. A skill that reaches the right answer by the wrong route breaks as soon as the input shifts a little.

Skill bloat: the real danger

Over time you accumulate dozens of skills, and past a certain point the system slows down and the agent starts invoking the wrong one. This is called skill bloat.

Two rules to prevent it:

1. Before writing a new skill, ask: would extending an existing one be more correct than writing a new one? In most cases, extending is the better call.
2. Prune regularly. Delete any skill that has not fired once in three months. Deleting is reversible; clutter is not.

Skill, rules file, or plain prompt?

These three get mixed up, and picking the wrong one wastes time. Here is where the line runs:

• A plain prompt — when the job happens once. If writing the procedure takes longer than doing the work, stop there.
• A rules file (the directives that sit at the root of the project and apply in every session) — when the constraint applies all the time. Your code style, your preferences about language, directories that must not be touched. These are never triggered; they are always on.
• A skill — when the job repeats but does not apply all the time. Procedures that should kick in only when that particular job comes up.

The most common mistake is turning a rule that should always apply into a skill. As long as that skill is not triggered, the rule is simply ignored, and you are left wondering why it was not followed.

The reverse happens too: a long procedure that would only occasionally be needed gets put in the rules file, where it eats context on every turn that never uses it.

Keeping the agent running continuously

An agent's most powerful capabilities come from its being able to work while you are not watching: replying to an incoming message, running a scheduled job, finishing a long task in the background.

The moment you close your laptop, all of that stops. So if you want a setup that genuinely runs continuously, you need to run the agent on a server that stays on rather than on your own machine. In the video this setup runs on a small virtual private server (VPS), and a server of that size is said to be enough.

One warning: a continuously running agent is one you have given an API key and service access to. Set a spending limit, keep its permissions narrow, and keep a log you can actually inspect.

In short

Installing skills is not a collecting hobby. The value is not in the number; it is in turning your repeating work into written procedure, in having read every skill you install, and in deleting the ones that do not earn their place. For a concrete example of turning repetitive production work into a procedure, see automating data visuals and icons. A small number of well-written skills genuinely moves your agent to another level.

Frequently Asked Questions

What is the difference between a skill and a prompt?

A prompt is a one-off request; a skill is the written procedure for a job that repeats. If you are typing the same prompt for the third time, that is the place to turn it into a skill.

How many skills should I install?

The count is not the goal. As a general rule, a few well-defined skills work better than many fuzzy ones; prune the ones you don't use on a regular basis.

Should I write skills myself or install ready-made ones?

Start with ready-made ones and adapt them to your own work. But never install one without reading what is inside it — that is a matter of both security and quality.

Do I need to know how to code to write skills?

Usually no. Most skills are nothing but plain-text instructions. Knowing how to code lets you verify the steps a skill runs; that is an advantage, but not a prerequisite.

Source

• Jack Roberts, This New Hermes Agent Skill is Insane (YouTube, August 2026). The security-scanning skill, clarifying interrogation, the handoff document, teaching mode, the skill-writing principles and running the agent on a server are based on this video.
• Matt Pocock, mattpocock/skills (GitHub): the source of the grill-me, handoff and teach skills.