Turn a Team Procedure Into an AI Agent Skill

A skill starts as something your team already does the same way every time. The craft is in the framing: one procedure per skill, a body an agent can follow, and a Trigger that says when it applies. Agents load skills on demand by relevance, so a vague Trigger is a skill that stays asleep. Here is the worksheet.

---

Your renewals desk follows the same seven steps for every quote, and they live in a document three people know the link to. That document is the raw material for a skill. What it is not yet is a skill an agent can use well, because a runbook written for a colleague assumes a colleague’s judgement about when to open it.

This post is about that gap. It does not re-explain how to get a skill into Insulin — the upload, Generate and import mechanics have their own guide, linked below where they belong — and the difference between an agent and a skill covers why a procedure is a skill rather than a new agent in the first place. This is the authoring craft in between: taking one procedure your team already follows and shaping it into something an agent picks up at the right moment and follows to the end.

What makes a procedure a good agent skill?

An agent skill is “a markdown-based instruction package containing procedures or domain knowledge” that agents load while working. A procedure becomes a good one when it is a single, repeatable job with a clear start and finish — “draft a renewal quote,” “triage an inbound security questionnaire,” “format the weekly numbers” — rather than a whole role.

Scope is the first decision, and the reason is mechanical. Agents load only what is relevant to the conversation in front of them, so a skill that bundles renewals and new-business pricing and discount policy forces the agent to carry all three whenever any one applies. Split them. One procedure per skill keeps each Trigger sharp and each body short enough to read in one sitting — which is also how you keep it maintainable, because the person editing it later is reading the same short document you wrote.

If you catch yourself writing “and then, unless it’s a renewal, do this other thing,” that “unless” is usually the seam between two skills.

How do you write the Trigger?

The Trigger is “a short description of when the skill applies,” and agents use it to decide whether a skill is relevant to the current conversation. It is the most important field and the one most often left wrong, because when you upload a file its Trigger defaults to the skill’s description — and a description says what a skill is, not when to use it.

Rewrite it to name the situation. Compare:

Field	Weak	Strong
Description	Renewal pricing helper	Renewal pricing helper
Trigger	Renewal pricing helper	When drafting a renewal quote for an existing enterprise customer

The strong Trigger names a moment an agent can recognise in a conversation (“drafting,” “renewal,” “existing customer”). The weak one just repeats the title, which tells the agent nothing about when to reach for it. Because agents load skills by relevance, the Trigger is doing the selection work — treat it as the most load-bearing sentence in the whole skill, and edit it whether you authored the skill or uploaded it.

What goes in the body of a skill?

A well-structured skill body has a clear title, ordered steps, examples, and constraints — the same things you would want if you handed the procedure to someone on their first day. The doc’s own example, a “Creating AWS Private Offers” skill, is exactly this shape: numbered steps with a Rules section for the limits that must hold.

Write the body as instructions an agent will follow literally, not as prose about the topic:

• A title that states the job. “Draft a renewal quote,” not “Renewals.”
• Ordered steps. Each one an action, in the sequence they happen. If step four depends on step two, say so.
• Examples. One worked case pins down the format. Use fictional stand-ins — draft the quote for Northwind at renewals@northwind.example, never a real customer — because a skill’s body is read by whoever opens the skill later.
• Constraints. The rules that must hold: the discount ceiling, the approval that is required above a threshold, the thing never to do without a human. State these as hard limits, because an agent will treat a vague “try to” as optional.

Keep the body to the one procedure the Trigger names. Everything the agent needs to do the job belongs here; everything about when belongs in the Trigger.

How do you author the skill in Insulin?

Two ways, and both end at a skill you review before it saves. Pick by where your procedure currently lives.

• Build with Agents, in your Personal store, opens a chat seeded with /skill-creator and you draft the skill collaboratively — good when the procedure is in your head or spread across a few conversations. It is a Personal-store method only.
• Upload → Generate → review → Save is the path when the procedure is already a document. Upload the file, Generate normalises it into a draft, you edit the prefilled fields, and Save stores it. This is the moment to fix the Trigger and read the body back as instructions.

Either way, name, description and prompt are required, and either way you get a review before the skill is live. For the file limits and the other import routes (a .zip, a GitHub URL, SkillsMP), see how to import an agent skill; this post assumes you are authoring your own procedure rather than bringing one in from outside.

How do you test a skill before the team relies on it?

In two passes: call it explicitly, then see whether agents reach for it on their own. Do both in your Personal store, on real work, before the skill goes anywhere near the organisation.

First, call it by hand. In Chat, typing / lists the current agent’s built-in skills plus the skills you have enabled, each slugified from its name, so you can pick yours deliberately. Run it against a real case and read what the agent produces against what your desk would have produced. This tests the body — the steps, the format, the constraints.

Second, stop calling it and just do the work the Trigger describes. Start the kind of conversation the skill is for and watch whether the agent picks it up unprompted. This tests the Trigger. If the agent does not reach for the skill on an obviously matching task, the Trigger is too vague or too narrow — tighten it and try again. Between these two passes you can tell a body problem from a Trigger problem, which is the whole point of testing before you publish.

A caution worth stating plainly: agents load relevant enabled skills on demand, by relevance, so no skill is guaranteed to load every time. A good Trigger makes a match far more likely; it does not make it certain. When a skill absolutely must run for a given task, call it explicitly with / rather than assuming it will surface on its own.

How do you publish a skill to the whole organization?

An org admin authors or imports the reviewed skill in the Organization store, which creates a copy visible to everyone. Personal and Organization are separate stores: a skill you proved in your Personal store does not appear for the team until someone recreates or imports it at the Organization store. Creating, importing, editing and deleting skills there all require org admin access.

That separation is a feature, not a hurdle. It means the version everyone gets is one that already survived a personal trial, which is the same eval-first order behind rolling an agent out org-wide. Prove the skill on your own work, fix the Trigger and body, then hand a known-good source to an admin to publish.

How do you maintain a skill once it is live?

Edit its fields as the procedure changes, and when a skill is wrong or retired, Disable it rather than Delete it. A skill is only as current as the procedure it encodes, and procedures drift — a discount ceiling moves, an approval step is added, a system is renamed.

• Edit updates the name, description, prompt, Trigger, category and tags. When the procedure changes, change the body; when the situations it applies to change, change the Trigger.
• Disable takes a skill out of use without losing it. A disabled skill stays in your library but is excluded from agent use, so you can correct it and switch it back on. Its detail view still shows the Trigger and body for you to read first.
• Delete is permanent, and deleting a skill in the Organization store removes it for everyone in your organization. Reach for Disable first; keep Delete for skills you are certain no one needs.

The habit that keeps a library healthy is small: when a procedure changes, edit the skill in the same sitting, the way you would update the runbook. A skill nobody maintains quietly starts giving last quarter’s answer.

Frequently asked questions

How do I turn a procedure into an agent skill?

Scope one procedure per skill, write its body as a clear title, ordered steps, examples and constraints, and write a Trigger that names when it applies. Author it with Build with Agents in your Personal store, or upload a file, Generate, review and Save.

What should a skill’s Trigger say?

A Trigger is a short description of when the skill applies, and agents use it to decide relevance. Name the situation, not the topic: “When drafting a renewal quote for an existing customer” beats “Renewal pricing helper.” An uploaded file’s Trigger defaults to its description, so rewrite it.

Will my agents always use a skill I publish?

No. Agents discover and load enabled skills automatically based on relevance to the current conversation, on demand, so no skill is guaranteed to load every time. Write a precise Trigger, and in Chat type / to call a skill explicitly when you need it.

How do I test a skill before the team relies on it?

Try it in your Personal store on real work. In Chat, type / to list your enabled skills and call it explicitly, then watch whether agents pick it up unprompted on the right task. Refine the Trigger and body until both behaviours look right.

How do I publish a skill to my whole organization?

An org admin authors or imports it in the Organization store, which creates a copy visible to everyone. In that store, creating, editing and deleting skills all require org admin access, so prove the skill in your Personal store first.

Should I delete a skill that is out of date?

Disable it instead. A disabled skill stays in your library but is excluded from agent use, so you can edit its fields and switch it back on. Deleting cannot be undone, and deleting an org skill removes it for everyone.

Takeaways

• One procedure per skill. Agents load only what is relevant, so a skill that bundles several jobs makes each one harder to reach and harder to maintain.
• The Trigger is the load-bearing field: it says when the skill applies, and agents use it to decide relevance. On an uploaded file it defaults to the description — always rewrite it to name the situation.
• The body is instructions, not prose: a clear title, ordered steps, fictional examples, and constraints stated as hard limits.
• Author with Build with Agents or by upload → Generate → review → Save, then test twice — call it with /, then watch whether agents reach for it unprompted.
• No skill is guaranteed to load. A precise Trigger makes a match likely; / makes it certain.
• Publish org-wide only after a Personal-store trial, and maintain with Edit. Disable rather than Delete.

The skill you just wrote is one capability your agents share. The Insulin Agent Marketplace is where ready-made agents and skills come from when you would rather install than author, and the Marketplace documentation is the full reference for every field, store rule and limit named here.