AI Skills for Non Developers: How to Use SKILL.md Without Writing Code

An AI skill is a plain text file that teaches ChatGPT, Claude or Gemini how to do one specific job the way you want it done, and then fires automatically whenever that job comes up. You do not need to code. You do not need a terminal. If you can write instructions for a new colleague, you can write a skill.

Here is the problem with every guide on this subject, including the official one.

They are all written for developers. Open any article about Agent Skills and within two paragraphs you are looking at a terminal window, a folder called .claude/skills/, and an instruction to run npx something. The examples are about code review and pull requests and debugging deploy pipelines. Which is fine, if you are a developer.

Most people are not. Most people using AI at work are writing proposals, chasing clients, preparing for reviews, summarising meetings, and trying to make the same thing sound right for the fourth time this month. And the single most useful feature in the entire AI toolkit has been sitting there for a year, buried under documentation that assumes you know what a shell is.

So this guide has no terminal in it. Not one command.

What is an AI skill?

An AI skill is a folder containing a text file called SKILL.md that holds a set of instructions for one specific task, plus a short description telling the model when to use them. The model reads the description, decides the task matches, loads the instructions, and follows them. You upload the skill once and it works from then on, in every conversation, without you mentioning it.

The comparison that made it click for me: a skill is a process binder you hand a new hire on day one. The front page is a short note saying what this binder is for. The next few pages are the actual steps. The back is full of appendices, templates and reference material they only flip to if the steps tell them to.

Your AI reads it exactly like that. Front page first, steps second, appendices only if needed. Which is why a skill can contain a 200 page playbook and still cost you almost nothing until the moment page 47 becomes relevant.

The file itself is not intimidating. It looks like this:

---
name: weekly-update
description: Writes my weekly team update. Use when I paste raw notes, bullet points, or a list of things that happened this week and ask for an update, summary, or status report.
---

# Weekly update

## Steps
1. Open with the single most important thing that happened. One sentence, no preamble.
2. Three sections maximum: Shipped, Blocked, Next.
3. Under Blocked, always name who is needed to unblock it.
4. End with next steps as bullets, each starting with a verb.
5. Never exceed 250 words.

## Tone
Direct. No filler. Assume the reader is skimming on a phone.
Do not write "I hope this finds you well." Do not write "As discussed."

That is a complete, functioning skill. Nine lines of instruction and a description. There is no hidden second half.

Why did skills suddenly matter in 2026?

Skills went from a Claude feature to an industry standard because Anthropic open sourced the SKILL.md format in December 2025, and OpenAI adopted the same specification for Codex and ChatGPT within weeks. Skills now work across Claude, ChatGPT, Gemini CLI, Cursor and GitHub Copilot. Something you write today keeps working if you switch tools tomorrow, which is not a promise this industry usually keeps.

That portability is the whole reason to care. Every hour you have ever spent perfecting a prompt was an hour invested in a chat window that closed. A skill is the first thing in this space that behaves like an asset rather than a receipt.

The rest of 2026 has been a steady drumbeat of the same idea. In January, Anthropic shipped hot reloading, so a skill you edit takes effect immediately rather than after a restart. In February, Agent Teams arrived, letting several specialised models work as peers rather than reporting to one lead. In May came Managed Agents, the cloud runtime where skills, multi agent orchestration and rubric graded outcomes all live together.

Meanwhile the community moved faster than any of it. One open library, Antigravity Awesome Skills, now indexes over 1,234 skills across ten agent tools and has passed 22,000 stars on GitHub. When Andrej Karpathy posted his frustrations with AI coding agents in January, a developer turned the complaints into a single instruction file and the repository hit 144,000 stars in weeks. One text file. No code, no dependencies.

The signal there is worth sitting with. The most valuable artefacts being built in AI right now are not models or apps. They are well written instructions. That is a market that rewards people who are good at explaining things, which is a much larger group than people who are good at writing software.

Skill, prompt, project or custom GPT: what is the difference?

Use a prompt for something you will do once. Use a project or custom GPT when you want the same background files available across many chats. Use a skill when you have a repeatable process and you want the model to run it the same way every time, without being asked. The difference is not power. It is when the instructions load, and whether you have to remember to invoke them.

This is the distinction almost everyone gets wrong, so it is worth being precise:

	You have to invoke it	Loads when	Survives switching tools
Prompt	Yes, every single time	You paste it	Yes, but you paste it again
Project or custom GPT	Yes, you open the right one	Every chat in that workspace	No
Skill (SKILL.md)	No	The model recognises the task	Yes

Read the middle column again, because that is the part that changes how the tool feels. A project loads its context every time you open a chat inside it, whether the current task needs it or not. A prompt loads when you remember to paste it. A skill loads itself, only when it is relevant, and stays out of the way otherwise.

You do not invoke a skill. The skill invokes itself. That is the actual product.

How does a skill work under the hood?

Skills work through progressive disclosure, which means the model loads information in three stages rather than all at once. Only the first stage is ever permanently in memory, and it costs roughly 100 tokens. This is why you can have fifty skills installed without slowing the model down, and why fifty pasted instruction sets would cripple it.

The three stages, per Anthropic's Agent Skills documentation:

• Stage one, always present. The skill's name and its one line description. About 100 tokens. The model scans these to decide what is relevant to what you just asked.
• Stage two, on match. The full body of the SKILL.md file, usually one to two thousand tokens. Loads only when the model connects your request to the description.
• Stage three, on demand. Any reference files, templates or examples bundled in the folder. Loaded only if the instructions point to them.

The arithmetic is the argument. Twenty skills sitting installed cost you about 2,000 tokens. Twenty instruction sets loaded eagerly would cost around 40,000, and would actively make the model worse, because performance degrades as the context window fills. That degradation has a name and a body of research behind it, and if you have ever watched a long chat slowly turn stupid, you have met it: context rot.

So skills are not just convenient. They are the mechanism that lets you give a model a lot of knowledge without drowning it, which is the central problem in using these tools well.

How do you install a skill without a terminal?

You install a skill in Claude through the settings panel, in the browser or the desktop app, with no command line involved. Go to Settings, then Capabilities, and switch on code execution and file creation. Then go to Settings, Customize, Skills, and upload your skill as a zip file. It appears in the list. Toggle it on. That is the whole process.

Two details that trip people up:

Zip the folder, not the file. The zip must contain the folder with SKILL.md inside it, not a bare SKILL.md sitting at the root. This is the single most common reason an upload fails, and the error message is not especially forthcoming about it.

You need a paid plan. Custom skills require Pro, Max, Team or Enterprise, because they run in a code execution environment. On the free tier you can benefit from the built in document skills, but you cannot upload your own.

Worth knowing: the prebuilt skills are already running whether you noticed or not. When Claude produces a PowerPoint or a spreadsheet for you, that is a skill doing the work. You have been using them for months.

How do you write your own skill in twenty minutes?

Pick the task you re explain to an AI most often. Write down the steps as if briefing a competent new colleague. Add a description that says exactly when the skill should fire. Save it as SKILL.md, zip the folder, upload it. Most people are done in under half an hour, and the first one is always the hardest.

The description is the whole game

If you take one thing from this article, take this. The description is the only part of your skill that is always loaded, and it is the only thing the model uses to decide whether to fire. Everything else is downstream of it.

A vague description means your skill simply never activates. You will assume it is broken. It is not broken. The model just never saw a reason to open it.

Bad: description: Helps with writing.

Good: description: Rewrites drafts in my voice. Use when I paste text and ask to rewrite, edit, punch up, or make it sound like me. Also use for LinkedIn posts and client emails.

Notice what the good one does. It names the trigger words a real person would actually type. Not the abstract category, the literal phrasing. Write the description for the way you talk, not the way you would file it.

The formal limits, if you plan to publish: the description is capped at 1,024 characters and the name at 64 characters, lowercase with hyphens, and you cannot use the reserved words anthropic or claude in a name.

The body is a briefing, not an essay

Keep it under 500 lines. Shorter is genuinely better, because everything in the body loads into context the moment the skill fires, and a bloated skill just recreates the problem you built it to solve.

Write it the way you would brief someone capable. Steps in order. What good looks like. What to avoid. If you have a template or an example of the finished thing, put that in the folder and reference it, rather than pasting it into the body.

The thing that makes skills work is specificity, and specificity is uncomfortable. "I write reports" is useless. "I write weekly reports that always open with the headline metric, use three sections maximum, and end with next steps as bullets" is a skill that will actually change the output. Vagueness in, vagueness out.

Add negative boundaries, or your skill will hijack you

This is the failure nobody warns you about. Write a description that is too broad and the skill fires when you did not want it. You ask a simple question and suddenly your LinkedIn Post skill activates and turns your one line answer into a hook and three bullet points.

The fix takes one line:

Do NOT use for blog articles, newsletters, emails, or general questions.

Tell it when not to fire. Skills are eager. They need boundaries, in the same way that an over enthusiastic junior needs to be told which meetings not to join.

Test it before you trust it

Open a fresh chat. Type the thing you would normally type, phrased the way you would normally phrase it, and see whether the skill fires on its own. If it does not, your description is the problem, not your instructions. Go back and add the literal words you just used.

Then test the opposite. Type something unrelated and check that the skill stays quiet. A skill that fires on everything is worse than no skill at all.

A worked example: the voice skill

Abstract advice is easy to nod along to and impossible to act on, so here is one skill built end to end. I have picked the voice skill because it is the one with the widest return and the lowest barrier, and because "make it not sound like AI wrote it" is the most common complaint anyone has about these tools.

Step one. Gather the evidence. Find four or five things you have written that sound like you. Emails, Slack messages, a post that did well. Not your most polished work, your most typical work. Polished writing is performance. You want the model to learn the everyday register.

Step two. Interrogate yourself. Open a chat and paste the samples in with this: "Read these. Describe my writing voice as precisely as you can. Sentence length, rhythm, vocabulary, how I open, how I close, what I never do. Be specific and unflattering."

What comes back is usually uncomfortable and genuinely useful. It will tell you things about your own writing you had not noticed, like that you open half your emails with a subordinate clause, or that you use the word "just" as a hedge nine times a page.

Step three. Turn it into rules. Take that description and convert it into instructions. Not a vibe, rules. Something like this:

---
name: my-voice
description: Rewrites text in my voice. Use whenever I paste a draft and ask to rewrite, edit, humanise, punch up, tighten, or make it sound like me. Also use for LinkedIn posts, client emails, and Slack messages. Do NOT use for formal contracts, legal text, or anything I explicitly ask to keep formal.
---

# My voice

## Rules
1. Short sentences. Then one longer one that earns its length. Vary the rhythm.
2. Open with the point. Never open with context, pleasantries, or a subordinate clause.
3. No em dashes. Use full stops or commas.
4. Cut every instance of: just, really, very, actually, simply, leverage, robust, seamless.
5. First person is fine. Opinions are fine. Hedging is not.
6. Never end with a summary paragraph. End on the last real point and stop.
7. If a sentence could appear in any company's blog, delete it.

## What I never do
Never write "I hope this finds you well."
Never write "As per my last email."
Never use three examples where two will do.
Never explain what I am about to say before saying it.

## Test
Read it back. If it sounds like a press release, start again.

Step four. Zip and upload. Folder called my-voice, containing the SKILL.md. Zip the folder. Settings, Capabilities, enable code execution and file creation. Then Settings, Customize, Skills, Upload.

Step five. Test it honestly. Open a new chat, paste a draft, and type the thing you would normally type. "Can you tidy this up?" If the skill fires without you naming it, the description is good. If it does not, add the words you just used to the description and try again.

Twenty minutes, once, and every draft from now on comes back sounding like a person. The version of this we sell as a product goes considerably deeper, but the version you build yourself in an afternoon will still beat every prompt you have ever pasted, because it never has to be pasted again.

What skills cannot do

Skills are not magic and the enthusiasm around them has got slightly out of hand, so here is the honest boundary.

A skill cannot give the model information it does not have. If you need it to read your calendar, query your database, or check today's prices, that is not a skill problem, that is a connection problem, and the answer is MCP or a tool integration. Skills teach procedure. They do not grant access.

A skill cannot fix a task you have not thought through. This is the one that stings. If you cannot explain your process to a competent human in writing, you cannot explain it to a model either, and the skill you build will be exactly as muddled as your thinking. Half the value of building a skill is discovering that your process was never actually a process. It was a set of habits you performed without examining.

A skill cannot make a weak model strong. It makes a capable model consistent, which is a different and more useful thing. If the underlying model cannot do the task at all, no instruction file will rescue it.

And a skill will not fire if you do not describe it properly, which I have now said three times and will keep saying, because it accounts for most of the disappointment people report.

Seven reasons your skill is not working

Almost every skill failure traces back to one of these, and none of them are about the quality of your instructions.

1. The description is too vague. The model never matched it to your request. Rewrite it with the exact words you actually type.
2. The description describes the skill instead of the trigger. "A comprehensive framework for client communication" tells the model what you think of your skill. It does not tell it when to use it.
3. You zipped the file rather than the folder. The upload silently does not work properly. Zip the containing folder.
4. The body is enormous. Everything in it loads on trigger. A 3,000 line skill will bloat your context and degrade the very output it was meant to improve.
5. Two skills overlap. If two descriptions cover similar ground, the model picks one, and it may not pick the one you meant. Make the boundaries between skills explicit.
6. You are restating what the model already knows. A February 2026 study from ETH Zurich looked at whether repository context files actually help coding agents. The result surprised almost everyone: machine generated context files reduced task success by around 3 percent, human written ones improved it by only about 4 percent, and including them raised costs by more than 20 percent. The lesson generalises. Telling the model things it can already work out is not neutral. It is noise, and you pay for noise twice.
7. You built a skill for something you do twice a year. The return on a skill comes from repetition. If you are not doing the task weekly, a good prompt is the right tool and you have overbuilt.

What should you build first?

Build a skill for the task you explain to an AI most often, not the one that sounds most impressive. The test is simple: if you have typed roughly the same instructions into a chat window three times this month, that is your first skill. Everything else is procrastination dressed up as planning.

Some starting points, by the kind of work you actually do:

If you manage people. A one to one preparation skill that turns your rough notes into an agenda, flags what you avoided last time, and drafts the difficult sentence you keep putting off. Pair it with a performance review skill and you have reclaimed most of a Sunday evening. The Manager Stack covers seven of these.

If you sell. A discovery call debrief skill that turns your messy notes into a structured summary with next steps and an honest read on whether the deal is real. Then an objection handling skill that argues back. The Closer Stack is built for this.

If you write anything. A voice skill. Feed it four or five things you have written, describe what you do and what you never do, and stop editing the corporate slush out of every draft. This is the highest return skill most people can build, and almost nobody builds it.

If you live in Microsoft 365. Skills work in Copilot too, and the day to day wins are in the boring places: Excel formulas, deck structure, inbox triage. The Microsoft 365 Copilot Skills Mega Pack bundles the lot.

If you want to skip the build entirely. The AI Skills library has 96 individual skills, the Skill Stacks group them by role, and The Vault is every assistant we have built, for life, at 99 USD. All of them are plain SKILL.md files. Nothing to install, nothing that expires, and they work in whichever model you are using next year.

How do you set this up properly, rather than dabbling?

Block out one Saturday morning. Not an evening after work, when you will do a bad job and conclude the tool does not work. Four hours, once, and you come out the other side with a setup that compounds instead of a folder of prompts you never open.

The sequence that works:

Hour one. Audit what you actually do. Write down every task you have asked an AI to do in the last month. Then mark the ones you have asked more than twice. That list, and only that list, is your skill backlog. Everything else is noise. If you want structure for this, the twelve question AI workflow audit scores where you are stuck.

Hour two. Build your voice skill. Do this one first regardless of your job, because it improves the output of every other skill you build afterwards. The walkthrough above is the whole recipe.

Hour three. Build your two most repeated work skills. From the audit list. Resist the urge to build ten. Two skills you actually use beat ten you built on a Saturday and forgot by Wednesday.

Hour four. Set the boundaries. Go back through each skill and add the negative rules. When should this not fire? What should it never produce? This is the hour everyone skips and it is the one that decides whether your setup is pleasant to live with or a constant low grade irritation.

There is a longer version of this protocol in the first Saturday, and if you want to understand why this compounds when copy pasted prompts never do, the three layers of AI fluency is the underlying argument.

The security part nobody wants to read

A skill runs with your permissions. Treat installing one exactly like installing software from a stranger, because functionally that is what it is.

Anthropic's own documentation is direct about this, and the risks are real rather than theoretical. A malicious skill can invoke tools in harmful ways, read files it has no business reading, or quietly send your data somewhere. The highest risk category is skills that fetch content from external URLs, because whatever comes back may contain instructions the model then follows, and a skill that was safe when you installed it can be compromised later if its dependencies change.

The rules are boring and they work. Read the SKILL.md before you install it, all of it. Look for network calls, file access, or anything that does not match what the skill claims to do. Be more careful, not less, if the skill will touch anything sensitive. And prefer skills you can actually read over skills that arrive as a black box, which is one of the underrated advantages of a format that is just markdown: you can audit it in ninety seconds without knowing how to code.

Why skills work better in groups

A single skill is useful. A set of skills covering one domain is a different thing entirely, because they start handing work to each other.

Take a real sequence. You come out of a client call. Your notes skill turns the mess into a structured debrief. Your voice skill drafts the follow up email from that debrief. Your objection skill pressure tests the two things the client said that you suspect were polite deflections. Three skills, one workflow, and you never named any of them. The model routed between them because each description was specific enough to claim its own territory.

That is why the sensible unit is a set rather than a file. Build one skill and you have automated a task. Build five that cover a domain and you have automated a job, because the handoffs between tasks are where most of your time actually goes. The gap between a good draft and a sent email is not writing. It is the twelve small decisions in between.

The design rule for a group is that descriptions must not overlap. If two skills could plausibly claim the same request, the model will pick one, and you have introduced a coin flip into your own workflow. Give each one a clear territory and an explicit boundary, and the set behaves like a team rather than a committee.

This is the thinking behind the way we package things. The Skill Stacks are sets of seven skills built to hand off to each other inside one domain, at 39 USD each. The Reasoning Engines go the other direction and handle the thinking rather than the output, for when the problem is the decision rather than the draft. And if you want the token discipline to stop all of this bloating your context, LEANBURN exists precisely for that.

Where this goes next

The direction of travel is that instructions become infrastructure. Teams have stopped treating skills as personal files and started checking them into shared repositories, so a new joiner inherits the team's accumulated know how on day one rather than absorbing it over six months. That is a genuinely different model of how organisational knowledge moves.

Two things follow from that, and I think both are underrated right now.

The first is that the skill of writing skills becomes the durable skill. Models will keep changing. GPT-5.4 arrived in March, Gemini 3.5 in May, and there will be another one before you finish reading your backlog. A well written skill survives every one of those transitions, because it describes your process rather than the model's quirks. Prompt tricks tuned to a specific model expire. Procedures do not.

The second is that this quietly reweights who is valuable. The people who will get the most out of AI over the next few years are not the ones who can code. They are the ones who can explain a process clearly, spot the step everyone else skips, and write it down in a way another intelligence can follow. That is an editorial skill, not an engineering one.

Which is a strange and rather cheering thing to be able to say about a technology everyone assumed would reward the engineers.

Frequently asked questions

Do I need to know how to code to use AI skills?

No. A skill is a text file with instructions in plain English. You can write one in any text editor and upload it through your browser settings. The official documentation is written for developers and uses terminal commands, which puts a lot of people off, but nothing about the format requires code. If you can write a clear brief, you can write a skill.

Do AI skills work in ChatGPT, or only in Claude?

Both. Anthropic open sourced the SKILL.md format in December 2025 and OpenAI adopted the same specification for Codex and ChatGPT. The format also works with Gemini CLI, Cursor and GitHub Copilot. Write a skill once and it runs across the tools you already use.

What is the difference between a skill and a custom GPT?

A custom GPT is a workspace you have to open deliberately, and its instructions load every time you use it. A skill fires by itself whenever the model recognises a matching task, and costs almost nothing when it is not being used. Custom GPTs are places you go. Skills are things that come to you.

How many skills should I install?

As many as are genuinely useful, because idle skills cost around 100 tokens each. Fifty installed skills add roughly 5,000 tokens, which is nothing. The real limit is overlap: if two skills have similar descriptions, the model may fire the wrong one. Keep the boundaries between them clear and the number stops mattering.

Why does my skill never activate?

The description, nine times out of ten. It is the only part the model reads when deciding whether the skill is relevant, so if it is vague or written in abstract language, the model never matches it to what you typed. Rewrite the description using the literal words you actually use when you ask for the task.

Are AI skills free?

The format is free and open, and plenty of good skills are given away. What costs money is the model that runs them, and the plans that allow custom skill uploads, which means Pro, Max, Team or Enterprise rather than the free tier. Paid skill libraries exist because writing a good one takes real work, but nothing stops you writing your own.

Will skills still work if I switch from Claude to ChatGPT?

Yes, and that is the point of the open standard. A skill that uses the portable core, which is a name, a description and plain markdown, works across compatible agents. Some platform specific features are ignored by tools that do not support them rather than breaking. Your instructions travel with you.

Sources

• Anthropic. Agent Skills overview. Claude Platform documentation, including progressive disclosure and security guidance.
• Anthropic. Effective context engineering for AI agents. Anthropic Engineering, September 2025.
• Hong, K., Troynikov, A., and Huber, J. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research, July 2025.
• Gloaguen, T. et al. Evaluating AGENTS.md: Are Repository Level Context Files Helpful for Coding Agents? ETH Zurich, February 2026.

Last updated 17 July 2026.