What is an AI skill, and how do you govern one?

What a skill is, and what it is not.

Four things get confused with each other.

A prompt is typed into the chat each time. It changes with whoever types it, and with the day.

A skill is a file. The assistant reads it and follows what it says. The wording stays the same on every run.

A custom assistant is a container: a name, some settings, some files. A skill can sit inside one.

An agent acts. It calls tools and takes steps of its own.

A skill sits between a prompt and an agent. It fixes how a job is described without granting the ability to act.

Inside the file there is a name, a line saying when to use it, the steps to follow, and the limits. The two skills sold on this site are a single Markdown file each, and a buyer can open either one and read the whole thing.

Why a firm builds a base of them.

The gain is consistency rather than speed.

Two people describing the same job to an assistant get different output. The same person gets different output on two days. The same assistant returns different wording on two runs. A skill narrows that spread.

There is a second reason. A prompt sits in one person's chat history and leaves when they do. A skill is held by the firm.

Skills also compound. One that classifies a regulatory change feeds one that drafts the reply to it.

For a firm in a regulated industry, whether that is testing, inspection and certification, medical devices, food or finance, this is the part that matters. What gets examined is whether the work was done the same way each time, and whether there is a record showing it.

Risk, and how to govern it.

Four things to settle before a skill is used.

What is in the file. Some skills are text. Some bundle scripts that run. Those are different risks. Read what you have, and be able to say which kind it is.

Where your material goes. A skill does not change your data position. What you attach goes to the assistant's provider, under their terms and under your own policy. Decide what may be attached before anyone attaches it.

Where the work stops. Write the skill so it produces a draft rather than an action. A draft can be reviewed. A sent email is harder to take back.

Who is answerable. The obligation stays with the firm and with the person who signs. A tool holds no scope and no approval.

One standing rule sits behind these. Plans, menus and limits change often. Check the maker's own page at the time you install, rather than relying on what was true when a guide was written.

Iteration, and institutional memory.

Treat a skill as a controlled document, because that is what it is. A firm in a regulated industry already knows how to run one.

Give it an owner, a version, a stated scope and a review date.

Keep a change log that records why a line changed, not only what changed. The reason is the part that carries forward to whoever holds the skill next.

When a run goes wrong, correct the skill rather than the output. Correcting only the output means the same correction gets made again next month.

Record which version produced which piece of work. Without that, a correction cannot be traced to what it affected.

Review on a trigger as well as on a date. A rule changes, a scheme changes, or a run produces something that had to be fixed by hand.

Practice worth adopting.

Start with one job that is done often and comes out differently each time.

Test the skill on a case where you already know the answer, before trusting it on one where you do not. Use invented material while testing on a free account.

Decide where a skill does not belong. A procedure suits one. A judgement that represents the firm's position does not.

Remember that a skill is text. Where a plan will not load a file, its text can be pasted into the chat instead.

Name and number the versions, so a person can say which one they ran.

A skill is a document. The governance a firm already applies to its documents is the governance it needs here.

Transcript of the video.

What the narration says, word for word.

Let's look at this explainer on AI skills and governance for regulated firms. I will take you through what these skills are, how they function, and the governance required when using them. Section 1 covers what a skill is. To start, an AI skill is a file of written instructions that an assistant loads before doing a job.

It does not give the assistant new powers. Instead, it fixes the wording of a procedure so a job is done the same way. To put this into perspective, consider the boundaries. A prompt changes daily depending on who types it. A custom assistant acts as a container, while an agent acts and calls tools.

A skill sits between a prompt and an agent. It is a file with fixed wording. In practice, a skill is a standard text file. If it is formatted as SKILL.md, a buyer can open and read it. Inside, it contains a name, usage steps, and limits. Section 2 looks at why a firm builds a base of skills.

The gain here is consistency rather than speed. Relying on skills narrows the spread of varying outputs that you might otherwise see from different people or on different days. These skills compound. For instance, one skill can classify a regulatory change and then feed that information into another skill that drafts the reply.

Because skills are held by the firm, they provide a reliable record. For regulated industries like testing, inspection and certification known as TIC, medical devices or finance, the record of consistent work matters. Section 3 addresses risk and governance. I will outline four points to consider here over the next portion of this explainer.

First, know what is in the file. You should state clearly whether it contains standard text or bundled scripts that run. These formats present different risks and require different handling. Second, control where your material goes. Attachments go to the provider under their terms and your firm's policy.

Decide what may be attached beforehand rather than leaving it to individual discretion. Third, define where the work stops. Write the skill to produce a draft rather than a final action. A draft can be reviewed by a person before it moves forward.

Fourth, consider answerability. The obligation stays with the firm and the person who signs. A software tool does not hold a scope, nor does it provide approval. Behind these four points is a standing rule for governance. Provider plans and limits change often. Check the maker's own page at the time of installation to verify the current terms.

Section 4 covers iteration and institutional memory. You should treat a skill as a controlled document. This means giving it an owner, a version, a stated scope, and a review date. Regulated firms already know how to run these processes. Maintain a change log that records why a line changed. Documenting the reason ensures it carries forward to whoever holds the skill next.

When a run goes off track, correct the skill rather than the output. Record the version so corrections can be traced back. Then review these on a specific trigger or date. The final section outlines practice worth adopting. Start with one job that is done often. Test it on a known case using invented material on a free account. Keep in mind that a procedural task suits a skill, whereas a judgement does not.

Remember that versions should be named and numbered, because a skill is just text. If a plan will not load a file, you can paste the text directly into the chat. To summarise, a skill is a document requiring the standard governance a firm already applies to its other documents.