A coach I work with asked me last month to send him the file behind my menu engineering reports. Not the reports. The file. He wanted to hand it to his own AI and see if it produced the same thing.
So I sent it. One markdown file. He read it, ran it, and 2 and a half hours later his reply was 3 words: "This is fantastic."
That file is what I mean when I say AI skill, not prompt. If you have ever wondered how to build AI workflows that hold up past the first run, this is the part nobody shows you. So here it is, redacted.
TLDR
- A skill file is not a long prompt. It is 5 separate parts, and the prompt is the smallest one.
- The part that does the most work is the reference library: examples of what good looks like, and examples of what wrong looks like.
- Rules that a script can check should live in a script, not in the file. The file is for judgment.
- The most useful section in my newest skills is a list of disagreements with no winner.
- If you can write down how you decide a piece of work is good, you can build one of these. If you can't, no tool will save you.
A Skill File Is Not a Long Prompt
Here is the mental model most coaches and consultants arrive with. A prompt is a request. A skill file is a very big request. More words, more instructions, better output.
That is wrong, and I know because I built it that way first. My early skill files were long and kept getting longer. Banned words. Strict rules. Fixed shapes. A checklist for every section. And they produced copy that satisfied every rule and still read flat.
Somewhere around the tenth rebuild I noticed a pattern I did not like. The longer the skill and the more rules it carried, the worse the output got. Rules train checklist thinking. A restaurant page, a coaching email, a LinkedIn post, none of those want checklist thinking. They want taste, applied consistently.
So the file is not a prompt. It is a container for judgment, and it has a shape.
The 5 Parts of a Skill File That Holds Up
Every skill I still run in production has the same 5 sections. The names change. The jobs do not.
- The job. One paragraph. What comes in, what goes out, who reads it. "A recorded coaching call comes in. A 5-email nurture sequence goes out. The reader is a client who bought 3 weeks ago and has gone quiet." That's it.
- The reference library. Real examples of approved work, with the client's comments still on them where I have them. And the anti-patterns: real examples of what got rejected, with why. This section is 60% of the file by weight and it does 80% of the work.
- The rules that need judgment. Not "max 2 sentences per tile." That is a script's job. I mean things like: a hero line earns its energy from a physical detail a first-time visitor could verify in 1 visit. No adjective stacking. No vague identity lines.
- The verification loop. The questions the draft gets read back through before I ever see it. My QA checklists run, I think, 20 to 40 filter points before anything ships. The best ones are 3 questions long.
- The output shape. Fixed counts. Always 3 options for the menu hook. Always 4 use cases, not 3. The counts never move, because a moving count is how drift starts.
Notice what is missing. There is no "you are a world-class copywriter" line. There is no tone description like "warm but professional." The reference library carries the tone. It always did. I have written before about why a tone adjective is not a brand voice, and the skill file is where that argument becomes structure.
Where the Rules Actually Live Now
This is the change that took me longest to make, so I'll be specific about it.
I used to keep every rule in the file. Character limits, section order, the hygiene checks, the banned word list, the 3 ranked options rule. All of it in one document the model read before writing. It got to 285 rows at one point, because every client ruling got appended and nothing ever got reconciled.
Then I split it. Anything a machine can check faster than I can went out of the file and into a template or a script. The page container is a template. Character counts are a script that prints ALL PASS or lists the lines that failed. The banned words are a scan.
What stayed in the file is the part a script cannot do. Does this line mean anything, or is it poetry that means nothing? Is this a resume or a history lesson? Does this make me want to go and eat at the restaurant? Those 3 questions replaced a rulebook, and honestly the output got better the week I made the swap.
The rules did not disappear. They moved to where they could be enforced instead of merely stated. That is the whole idea behind the Verification Loop, and it is the reason my compression numbers went where they went.
The Disagreements File Nobody Expects
Here's a section I did not plan and now cannot work without.
Every time 2 clients went opposite directions on the same kind of line, I used to pick a winner and write the winner into the rules. Client A wanted the hero line short, client B wanted it evocative, so I'd write "keep hero lines short" and then fight client B's skill for a month.
Now those go in a separate file with both sides written down and no winner. "Client A prefers X because their guests are regulars. Client B prefers Y because their guests are tourists." The skill reads it and holds the fork open until it knows which situation it is in.
Copywriting by logic is not a fixed framework you follow every time. Some calls stay calls. Writing that down, rather than pretending every question has a rule, is what stopped the file from growing back to 285 rows.
What I Would Build First If I Were You
If you are a coach or consultant reading this and thinking "I could never write that," I think you are wrong, and I think you are wrong for a boring reason. You already make these calls every week. You look at a draft and you know in 4 seconds whether it sounds like you. The skill file is just that 4 seconds written down.
Start with the reference library. Gather 10 to 20 pieces across the 3 Sources: things you said, things you wrote, things you sell. Pull 5 that you are proud of and 5 that make you wince. Write 1 sentence next to each one saying why. That is a reference library, and it is worth more than any prompt you will ever write.
The verification questions come second. The output shape comes third. The job description you can write in 2 minutes.
And I mean that genuinely. The file I sent that coach took me months to get right. The version that would have helped him 6 months ago would have taken an afternoon.
Look, you already know AI can help your business. You've known that for a while. The part you are stuck on is what the thing that actually works looks like on the inside. Now you have seen one.
If you want to see it run on your own material, send me 1 piece of your work. Something you said, wrote, or sell. You get a finished asset back in your voice within 48 hours, and you'll know whether this is worth building for you.
FAQs about AI skill files
What is an AI skill file?
A structured document an AI model reads before it produces work. It carries the job description, a reference library of approved and rejected examples, the judgment rules a script cannot check, the questions every draft is verified against, and the fixed output shape. It is closer to a handbook than to a prompt.
How long should a skill file be?
Shorter than you think. The best ones I run today hold 3 verification questions and a reference library. Everything that can be checked by a script, like character counts or banned words, should live in a script instead. A file that grows past a few pages of rules usually produces worse output, not better.
Do I need to know how to code to build one?
No. The file is plain text. The scripts that enforce counts and hygiene are optional and small, and I built my first ones without any coding background. What you do need is the ability to say why a piece of work is good or bad in 1 sentence.
Can a skill file be moved to a different AI model?
Yes, and that is one of the main reasons to build one. The file is the asset. I have pointed the same skill at different models as they changed, and the reference library and verification questions carried over intact.