Make a Skill

You ask a model to draft an email. It comes back too long, too formal, opening with "I hope this finds you well." You fix it. Tomorrow you ask for another email, on a different topic, and it opens with "I hope this finds you well" again.

Nothing was learned between the two requests. A model has no memory of yesterday's correction unless you put it back in front of the model, as text, again, from scratch. Most people do exactly that, forever, and call it the cost of using AI.

There is a feature built for this. It is not complicated, and almost nobody uses it.

What a skill actually is

A skill is a text file. It states, in plain language, a set of standing facts or rules the model should apply whenever a request touches that territory. You give it a name and the model reads it automatically whenever a request matches that name or topic. It works the same way a template loads when you open the right kind of document.

That is the mechanism. There is no training step. You are not adjusting the model's weights or its underlying behavior. You are handing it a reference document at the start of the conversation instead of a stream of corrections partway through it. The document persists across conversations. The corrections you used to give live inside it, and don't need repeating.

Writing is the easy example, and worth walking through once, but it undersells what the feature is for. A skill is any standing fact about your situation that a model would otherwise have to be told fresh, every time, forever:

• Voice and format for a kind of writing you do often: the length, the tone, the phrases that are off-limits, a worked example or two.
• Constraints on your life the model should never ignore: a food allergy, a diet you follow, a medication interaction to flag before suggesting a recipe.
• A default tech stack, if you write code: the language, the framework, the testing library, the formatting rules, so the model stops proposing a stack you rejected six months ago.
• A repeatable process: the exact steps and even the small script you use to clean up a spreadsheet export, reconcile two file formats, or turn a folder of receipts into a summary.

The common thread is not "writing." It's repetition. Anything you would otherwise explain more than once belongs in a file instead of in your head.

How to actually build one

You do not write the skill yourself, in the sense of drafting the instructions from a blank page. You describe the outcome, and you ask the model to turn the description into a set of rules.

A working version of the request looks like this:

I keep having to tell you the same thing about [the task or the constraint]. Here's what I actually want you to know or do: [describe it]. Write this up as something I can reuse every time this topic comes up, including a short checklist to catch mistakes before you hand anything back.

The model already knows the shape a good instruction set takes: specific rules, a few contrastive examples, an explicit list of things to avoid or always include. What it doesn't know is what you personally want, which is the part only you can supply. Producing the first version takes about ten minutes between the two of you, not because the task is trivial but because most of the material already exists in your head. It has just never been written down in one place.

Check whether someone already built it

Before you write one from scratch, ask whether it already exists. Popular AI tools now ship a library, or a marketplace, of skills other people have already built and shared: coding conventions for common frameworks, document formats, research workflows, whole professional playbooks. If the thing you want is common enough that someone else needed it first, search there before you write a word. You can still open the file afterward and adjust it to your own preferences; starting from a working draft is faster than starting from nothing, and it's the same shortcut you'd take with any other reusable template.

What actually goes in one

The skills that hold up under repeated use share a shape:

• A stated scope. What situation triggers this, specifically, so the model knows when to load it.
• The rules or facts themselves, stated plainly: length targets, banned phrases, dietary restrictions, preferred libraries, exact steps.
• A concrete example or two. A before-and-after, or a case that shows the rule applied correctly.
• A short checklist at the end, for the model to run against its own output before handing it back.

None of this requires special vocabulary. If you can explain the rule to a new employee in a sentence, you can put that sentence in the file.

Where the saving actually shows up

The saving is not in any single conversation. The first attempt with a skill loaded and the first attempt without one take about the same time to review. It shows up in the twentieth conversation, and the fortieth, where the correction you used to give by hand simply isn't necessary anymore, because it already happened, once, and got kept.

It also compounds in a way a one-off correction cannot. Every time a skill produces output you have to fix, that fix is itself information about what the skill is missing: a rule that wasn't specific enough, a case it hadn't accounted for. Add that back to the file and the next attempt is closer. The document gets better the same way a checklist gets better, by catching a real failure and being amended so that failure doesn't happen twice.

Start with the thing you repeat most often

Pick whichever fact or task you find yourself restating most: a writing style, a dietary rule, a coding preference, a manual cleanup step. Search for an existing skill first. If nothing fits, ask the model to write one using the prompt above. Use it for a week, and when it gets something wrong, add the fix to the file instead of just fixing the output.

That file is now doing the job you were doing by hand, and it does not forget.