AI Agent Skills: Reusable Procedures Instead of Long Prompts

AI agent skills are reusable procedures stored as small, named packages that an agent loads only when a task calls for them. Instead of one long prompt that describes every duty, the core instructions stay short and each recurring procedure lives in its own file with a trigger, steps, limits and a check. This makes the agent's behavior easier to test, review and change without breaking unrelated work.

Key takeaways

• A skill is a named procedure with a trigger, inputs, steps, allowed tools, an output format and stop conditions. It is loaded on demand, not always present.
• Long prompts decay because every edit risks side effects on duties that have nothing to do with the change. Skills isolate those edits.
• Write a skill only for work that recurs and has a definition of correct. One-off judgment calls stay in conversation.
• Every skill needs an owner, a small set of test cases and a version, so an update is a reviewed change and not a quiet rewrite.
• Skills are content the agent trusts, so they need the same access control and review as any other instruction source.

What is an agent skill, in practical terms?

Think of a skill as the written procedure you would hand a capable new colleague for one specific job, such as preparing a monthly client summary or checking a supplier invoice against an order. It is narrower than a job description and more concrete than a policy. It says when to use it, what to gather first, what to do in order, what the result should look like, and when to stop and ask a person.

A useful skill has a small number of parts:

• A short description that tells the agent when the skill applies, and when it does not.
• The inputs it needs and where they come from.
• The steps, written as actions with a visible result for each.
• The tools and permissions the procedure may use, and which actions are off limits.
• The output format, including what evidence the agent attaches.
• Stop conditions: the situations where the agent hands the decision to a person.

The key design idea is that the agent sees only the short description until the task matches. The full procedure enters the working context at that moment. That is a form of what the field calls context engineering: giving the model the smallest set of information that lets it do the current step well. If you want the wider picture, our guide to context engineering for business agents covers what else competes for that space.

Why do long prompts stop working as the business grows?

A long prompt usually starts as a sensible page of guidance. Then a customer complaint adds a paragraph about tone, a finance review adds a rule about approvals, and a new tool adds a note about when to call it. After a few months nobody can say which sentence produces which behavior.

Three problems follow.

• Interference. A rule written for refunds quietly changes how the agent handles scheduling, because both sit in the same block of text and the model reads all of it every time.
• No test boundary. When the whole prompt is one unit, you can only test the whole agent. A small edit forces you to recheck everything, so people either skip the check or avoid editing.
• Unclear ownership. The person in finance who knows the approval rule cannot safely change a document that also contains sales tone guidance and support escalation paths.

Anthropic's engineering writing on building effective agents recommends starting simple and adding structure only where it earns its place. Skills are one way to add structure without adding an unreadable monolith. The question to ask is not whether your prompt is long, but whether you can change one duty without fearing for the others. Our piece on prompt engineering versus harness engineering explains why this is a harness concern as much as a wording concern.

What should become a skill, and what should not?

Not every instruction deserves its own package. Packaging has a cost: someone must name it, test it and keep it current. Use this decision guide.

• Make it a skill if the work recurs on a rhythm or trigger, such as weekly reports, intake of a new document type or a standard reply to a common request.
• Make it a skill if there is a clear definition of a correct result that a colleague could check.
• Make it a skill if different people currently explain the procedure differently, and you want one agreed version.
• Keep it in the core instructions if it applies to nearly every task, such as the agent's identity, tone and the rule to stop when unsure.
• Keep it out of both and use a fixed script if the steps never vary and need no judgment. In that case a deterministic workflow is safer, and our decision guide on agents versus deterministic workflows helps you draw that line.
• Leave it as conversation if it is a one-off request that will not repeat.

A good test is to ask whether you could write the first line of the description. If you cannot say in one sentence when the skill applies, the procedure is probably two procedures, or not yet a procedure.

How do you write a skill step by step?

Here is a practical plan you can follow for any recurring task. It works with whatever tooling you use, because it is about the content of the procedure.

• Step one: pick one real example. Take a recent, completed instance of the task and collect the inputs, the output and the decisions a person made along the way.
• Step two: write the trigger. Write a description of one or two sentences that says when to use the skill and one sentence on when not to.
• Step three: list the inputs. Name each one, say where it comes from, and say what the agent does if it is missing (usually: stop and ask).
• Step four: write the steps as actions. Each step should produce something observable, such as a draft, a lookup result or a comparison. Avoid steps like "consider the situation".
• Step five: set the boundaries. List the tools the skill may use and the actions it may not take. Separate reading, drafting and sending, because they carry different risk, as described in our note on read, draft and send permissions.
• Step six: define the output and the evidence. State the format, and require the agent to attach what it checked, so a reviewer can verify without redoing the work.
• Step seven: add stop conditions. Name the cases that go to a person, and say what the handoff must contain.
• Step eight: add two or three examples, including one awkward case, and record the expected result for each.
• Step nine: assign an owner and a version label, and write down what changed whenever the skill is edited.

Keep the file short enough that its owner reads it fully each time they edit it. If it grows past what one person can hold in mind, split it by outcome, not by topic.

What does a skill look like in a real scenario?

This is an illustrative scenario, not a description of a real client.

Imagine a small operations team that asks its agent every Monday for a supplier delivery summary. The original prompt mixes the summary format, rules about which delays to flag, instructions for drafting supplier emails and a note on never contacting suppliers directly. Each time someone adjusts the flagging rule, the email tone shifts as well, and nobody knows why.

The team splits the work into two skills. The first, a delivery summary skill, reads the order data, groups late items, applies the flagging rule and produces a table with a note on which records it checked. The second, a supplier follow-up skill, drafts an email for each flagged delay, but its boundary says drafts only, with a person approving every message. The core instructions keep only the agent's identity, its tone and the rule to stop when data is missing.

Now the operations lead can change the flagging rule by editing one short file, run the three saved examples, and see whether the output still matches. The email skill is untouched, so it needs no retest. The change is small, reviewed and reversible.

How do you test a skill before you trust it?

A skill is only easier to maintain if you can tell when it breaks. Testing does not need heavy tooling at the start. It needs a small, honest set of cases and a rule for what counts as a pass.

• Collect real examples from past work: a typical case, a case with missing input, a case that should trigger a handoff and a case that tempts the agent to overstep its boundary.
• Write the expected result for each in plain language, including what the agent must not do.
• Run the skill against the set whenever the skill, the model or a connected tool changes.
• Review failures by reading what the agent actually did, not only the final answer. Anthropic's writing on evaluating agents makes the same point: examine the steps the agent took, not just the outcome.
• Add every real failure as a new test case, so the same mistake cannot return unnoticed.

This is the same discipline described in our guide to building a golden test set for your AI workflow. The skill file defines the procedure, and the test set defines what correct looks like. Together they let a non-engineer approve a change with confidence.

How do you load skills without adding risk or clutter?

Skills solve a clutter problem, but they introduce two design questions: which skill gets loaded, and what the loaded text is allowed to do.

On selection, keep descriptions distinct. If two skills have overlapping triggers, the agent will pick inconsistently. Review the descriptions together, the way you would review a menu, and remove overlap. Also keep the number of skills available to a single agent role manageable, because a crowded menu makes selection harder.

On authority, remember that a skill is trusted instruction. Anyone who can edit it can change what the agent does, so editing rights deserve the same care as access to the systems the agent uses. Review changes before they go live, and keep a record of who changed what. Do not let skills be assembled from content the agent fetched from outside sources, because untrusted text that is promoted into instructions is exactly how prompt injection succeeds. The OWASP guidance on preventing prompt injection is a good reference for separating trusted instructions from untrusted input.

Also keep approvals outside the skill text. A line saying "ask before sending" is a request to the model. A permission setting that blocks sending until a person approves is a control. Use both, and rely on the second. Where your skills include approval points, our guide on where an AI agent should stop and ask can help you place them.

How does Be Human handle skills in a managed setup?

Be Human treats skills as part of the agent's harness, alongside identity, memory, tools and permissions. In a first engagement we define one useful role, then package its recurring procedures as skills with a named owner on the company side, a saved set of test cases and approval boundaries enforced in the tooling, not only in the text. During managed operations we run the test cases again after changes to a skill, a model or an integration, review who can edit skills, and make improvements as controlled, versioned updates. The company keeps the final say over what each skill is allowed to do.

Frequently asked questions

How is a skill different from a prompt template? A template fills in blanks in a message, while a skill is a full procedure with a trigger, tool limits, evidence requirements and stop conditions. The agent decides when to load a skill, and the harness enforces its boundaries. A template does neither.

How many skills should one agent have? Enough to cover its recurring duties, and few enough that the descriptions stay clearly distinct from one another. If you find yourself writing near-duplicate skills, merge them or tighten the triggers. A narrow role with a handful of well-tested skills is usually easier to trust than a broad one.

Who should own a skill? The person who owns the underlying business process should own the skill, because they know when the rule is wrong. A technical colleague can help with tools and testing, but should not be the only one who understands the procedure. Ownership also means that person approves each change.

Can skills replace a fixed workflow? Not when the steps never vary and need no judgment, because a deterministic workflow is cheaper to run and easier to guarantee. Skills fit work where the agent must read varied inputs and decide, within limits you have written down. Many good systems combine both: a fixed workflow for the predictable parts and a skill for the judgment inside them.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.