Here’s the secret nobody leads with: a skill is a folder of text files. When you see how simple that is, a whole category of AI work unlocks — so don’t skip this one, and don’t skim it. Somewhere in the next ten minutes it clicks.
Below, a real skill turns a meeting into a filed, searchable recap. Press play and watch what actually loads, when, and why.
Skills look like software. They're folders of plain text. The moment you can read one, you can rewrite one — and then every skill anyone ships becomes raw material for yours.
9 steps, ~1 minute on autoplay. Use the dots to jump; space bar plays and pauses. Open full screen.
No binary, no installer, no code you can't see. The meeting-recap skill above is eight files and 341 lines, and every line is plain English you could have typed. The .md extension just means markdown — a text file with headings. Anything that can edit text can edit a skill.
The name and description at the top of SKILL.md are the only lines your AI always carries. They're how it decides which skill a task matches — which is why a good description states its triggers outright: "Use when I share a transcript or ask what happened in a meeting." A vague description means a skill that never fires.
Forty installed skills cost almost nothing between tasks. The index is the whole trick.
Tier 1: the header, always in context. Tier 2: the SKILL.md body, loaded when a task matches. Tier 3: referenced files — retrieval procedures, per-type instructions, examples — loaded only when the instructions point at them and the job needs them. That's progressive disclosure, and it's why a skill can hold four meeting types' worth of depth without weighing anything until a meeting actually ends.
SKILL.md doesn't paste a sample recap into itself — it says "match the format in examples/standup-recap.md." Bulk detail lives in the referenced files so the instruction file stays readable in one look. When you see a skill with a 500-line SKILL.md, you're looking at a prompt wearing a skill's clothes.
Download meeting-recap-skill.zip ↓
Download the zip and double-click it to unzip. You'll have a meeting-recap folder. Open it with any text editor — VS Code, Cursor, even TextEdit or Notepad. There is nothing else to install, because there is nothing to install: it's text.
Start with SKILL.md and only SKILL.md. When it says "→ retrieval.md," open that file — you just did tier 3 by hand. Then open types/standup.md and one example. Notice what you did NOT need to read: three of the four type files never opened. You just walked progressive disclosure yourself, and now it's not an abstraction.
Claude Code: ~/.claude/skills/meeting-recap for every project, or .claude/skills/ inside one repo. Codex: ~/.agents/skills/ for you, .agents/skills/ committed to a repo. Gemini CLI: ~/.gemini/skills/ or ~/.agents/skills/. ChatGPT and Claude Desktop: skills live on your account, not your disk — add it from the skills panel.
Same eight files every time. The folder you just read is the folder every one of these tools reads, because they all follow the same open standard. Nobody is holding your skill hostage.
Notice that .agents/skills/ shows up twice. That's the cross-tool path — Codex uses it natively and Gemini accepts it. Put a skill there and two harnesses find it.
Before you paste anything, write down three to five things that have to be true for the recap to be worth keeping. Mine: every decision captured, every owner named, under 150 words, filed in the right place, nothing invented that wasn't in the transcript. Takes a minute. Do it in a notes app, not in your head — the point is that you can't move the goalposts afterward.
Now paste a transcript and ask for a recap. Watch which files it reaches for, and then check the output against your list. A skill firing tells you the AI found it. It does not tell you the AI did what you wanted.
Whatever fails that list is your edit list for the next section. You're not about to customize this skill because customizing is fun. You're repairing specific misses.
One: the banned-words list in SKILL.md — delete mine, type the phrases that make YOU wince. Two: the storage paths — point standups at your shared folder, one-on-ones at your private notes app (Obsidian, Apple Notes, a Drive folder only you can see — the file says vault, you say where). Three: the standup word cap — 150 is my number; maybe yours is 100, maybe your standups deserve 300. Save the files. That's the entire operation — no build step, no restart ritual.
Copy types/standup.md, rename it — board-meeting.md, sales-demo.md, therapy-checkin.md, whatever your week actually contains — and rewrite three things: the tells (how the AI recognizes this meeting), what matters (what the reader needs in 60 seconds), and where it files. Add one row to the routing table in SKILL.md. You didn't customize a skill just now. You authored part of one.
Because after you've edited a skill in a text editor once, no skill is ever opaque again. You'll skim any skill's SKILL.md before installing it the way you'd skim a recipe — spotting its dependencies, its assumptions, its author's answers hiding in neutral sentences. That literacy is the actual product of this guide. The edits are just how you earn it.
Paste this with any skill folder available to your AI. It interviews you one question at a time, touches only the answer-lines, and shows you the diff — so you stay the author and the AI stays the typist.
<task> Rebuild the skill in this folder as MINE, keeping its structure intact. </task> <context> A skill's structure (its mechanics — workflow steps, routing, file layout) transfers between people. Its answers (banned words, storage locations, word caps, notify rules, tone choices — anything marked "yours to change" or reading as a personal default) do not. Your job is to replace the author's answers with mine. </context> <inputs_to_collect> Interview me ONE question at a time. Cover at least: 1. Which of the skill's scenarios/types I actually encounter — drop the ones I don't, and ask what's missing that I do. 2. Where each output should be stored in MY world (shared vs private). 3. My voice rules — words I ban, tone I want, formatting I care about. 4. Any thresholds (length caps, timing) I'd set differently. 5. What should happen after the output exists — who's told, what's indexed. </inputs_to_collect> <requirements> - Change ONLY answer-lines. Do not restructure the skill, rename files, or reorder the workflow unless I ask. - Keep every changed line as plain and readable as the original. - If one of my answers conflicts with a mechanic (e.g. I route private notes to a shared folder), flag it and ask before writing. </requirements> <deliverables> The edited files, plus a summary diff: each changed line, before → after. </deliverables> <verification> End by re-reading the finished SKILL.md top to bottom and confirming every remaining line is either a mechanic or an answer I gave in this interview. </verification>
There isn't one, and there doesn't need to be. Claude Code, Codex, and Gemini CLI all read the same SKILL.md, because skills are an open standard now — agentskills.io, not one vendor's format. The Codex version of a skill is the skill, in a different folder.
And the standard is the smaller half of the answer. A skill broken down to its ideas — here's the workflow, here's the routing, here are my answers — isn't chained to its original tool, stack, or AI even when the format does drift. You re-express it wherever you work. The person who can only install skills is locked to whoever publishes for their platform. The person who can rebuild them is locked to nothing.
This is the founding philosophy of our Open Skills library: don't download skills — make them your own. Every entry there is a reference implementation waiting for your answers. Pick the one closest to a job you actually have this week, and run the loop you just learned: read it, find the answers, replace them, run it.
Codex: type $skill-creator. Built in, nothing to install. ChatGPT: @skill-creator, same tool. Claude Code: it's a plugin, so run /plugin install skill-creator@claude-plugins-official and then /reload-plugins. Gemini CLI: reads skills fine, ships no builder of its own — write the folder by hand, which you now know how to do.
Each of these will interview you and hand back a working folder. That was never the hard part.
You'll find blog posts naming a different Claude marketplace. That name is stale — claude-plugins-official is the current one.
A builder can write mechanics all day. It cannot know your answers, because you've never said them out loud. So go in with both halves already separated: here's the job I repeat, here are the steps, and here are the lines only I can fill — where this files, what I ban, when it stops, what makes an output good enough to keep.
That's the whole difference between a folder you delete in a week and a skill you still use in six months. It's also why this section is last. Ask a builder to make you a skill on day one and you get somebody's average. Ask it after you've read one, tested one, and repaired one, and you get yours.
One more thing worth asking for by name: have it write prompts that SHOULD trigger the skill and prompts that should NOT, then check which way it actually fires. That's the description problem from section 01, and it's the failure you'll never notice on your own — a skill that quietly never runs looks exactly like a skill you forgot you installed.
If you've been installing skills for a while, you have a second problem: you don't know what's in there anymore. Descriptions overlap. Two skills contradict each other and the AI splits the difference. Something fires on every task and quietly eats your context. Nobody notices, because the output is never broken — just flat.
This prompt reads the whole set and reports. It changes nothing.
<task> Audit every skill installed in this environment and tell me what is wrong with the set as a whole, not just with individual files. </task> <scope> Read the skill folders available to you — personal, project, plugin, and bundled. For each one, read the name and description FIRST. That header is all the model normally carries, so it is what decides whether the skill ever fires at all. </scope> <checks> 1. Dead triggers: descriptions too vague to ever match a real request. 2. Overbroad triggers: descriptions that pull the skill into jobs where it does not belong, spending context on every unrelated task. 3. Collisions: two or more skills whose descriptions overlap enough that choosing between them is a coin flip. 4. Contradictions: skills that would give conflicting instructions if they both fired on the same job. 5. Redundancy: skills duplicating something this harness already does natively. 6. Bloat: a SKILL.md long enough that reading it costs more attention than the job it describes. </checks> <requirements> - Report only. Do not edit, move, rename, or delete anything. - Quote the offending line for every finding so I can check your work. - For collisions and contradictions, name both skills and say which should win. - Rank findings by how often the skill would actually fire. A broken skill I never trigger matters less than a bloated one that fires constantly. </requirements> <deliverables> Each finding as: skill name, what is wrong, the line that caused it, and your recommended fix. Then list the skills you found nothing wrong with, so I know they were actually read and not skipped. </deliverables> <verification> Tell me how many skill folders you read and how many you could not read. If you cannot find the skills directory, say so instead of guessing at what is there. </verification>
The audit above only looks at skills. Your AI is also carrying instruction files, memory, tools, permissions, and settings you configured once and forgot — all of it shaping every answer, none of it visible in one place. Same problem, wider blast radius. The harness cleaner is that audit: one read-only report, nothing changes until you approve it.