What does a Skill add beyond a prompt?

When I first came across Skills, my most immediate question was:

when we create a simple Skill, aren’t we still using a prompt to tell AI:

when to use it, what steps to follow, and what to output in the end?

So how is that different from a prompt saved in Notes that you copy and paste when you need it?

The answer isn’t that mysterious:

the simplest Skill may indeed be, at its core, a prompt.

The difference is that these instructions no longer serve only the current conversation. They’re named, their scope is written down, and they’re saved as a method that people or AI can invoke again.

The simplest Skill is still written instructions

Say I often use a prompt like this:

When reviewing an article, first check whether it has only one main thread and whether the evidence supports the conclusion, then judge whether it needs a light edit, a restructure or a rewrite.

Saved in a document and copied out by hand when needed, that’s a prompt template.

Turning it into a Skill usually also means adding:

• what the Skill is called;
• what task it solves;
• when it should be invoked;
• when it doesn’t apply;
• the specific steps to follow;
• what standard the final result must meet.

In the file-based structure Codex and Claude Code currently use, the core of a Skill is usually a SKILL.md, which must state the name, description and instructions. AI first reads the name and description to judge whether the current task matches; only when it actually invokes the Skill does it load the full content.

So prompts and Skills aren’t mutually exclusive.

A prompt can be the core content of a Skill. What a Skill adds is a layer of organization: it lets the instructions be recognized, invoked, shared and edited.

A Skill can carry things beyond instructions

Some Skills need only text.

For example:

• reviewing articles against fixed standards;
• revising copy in the brand voice;
• organizing meeting notes in the same structure;
• checking whether a deliverable is missing required content.

Some tasks need the same set of material each time.

Then you can put templates, glossaries, good examples, product descriptions or internal guidelines into the Skill, instead of uploading them again every time.

A step more complex, a Skill can also include scripts and code.

For example, a data-processing Skill can hold field descriptions, cleaning rules, an output template and the script that actually processes the CSV; a code-review Skill can set the order of checks and call tools to run tests.

At present, both OpenAI’s and Anthropic’s file-based Skills support adding reference material, scripts and other resources beyond the main instructions.

A common structure looks roughly like:

my-skill/

├── SKILL.md

├── references/

├── scripts/

└── assets/

Not every directory has to exist.

A writing Skill may need only SKILL.md; only when the task genuinely depends on fixed material or code do you need to add more files.

Skill, Memory, Tool, Agent

These concepts are often mentioned together, but each is responsible for something different.

Take “reviewing an article” as an example:

The prompt is this time’s request:

Please review the article below.

The context is this task’s material:

the article itself, the target readers, the background, and what explicitly isn’t up for discussion this time.

The Skill is the reusable method:

look at the main thread first, then the evidence, repetition, factual accuracy and the level of revision needed.

Memory stores information that needs to be known across tasks:

for example, that the user has long disliked paper-style titles, or prefers checking logic before polishing wording.

A tool is an ability AI can actually call:

searching the web, reading files, running code, editing documents or working with spreadsheets.

The agent determines whether AI can act continuously toward a goal:

reading material on its own, choosing tools, making the changes, checking the results, and moving on to the next step.

What a Skill provides is “how to do it.”

It isn’t responsible for keeping a full history, and it doesn’t gain files, tools and execution permissions out of nowhere.

A Skill doesn’t automatically absorb each correction

Correcting AI during one task doesn’t mean the Skill has been updated accordingly.

It usually won’t edit its own SKILL.md, nor will it know on its own:

• what happened in the last task;
• where the project stands now;
• what preferences the user has recently changed;
• which request was just a one-time exception.

Some products provide memory or project instructions separately. Claude Code, for example, uses CLAUDE.md and auto memory to keep information across sessions, but those are mechanisms independent of Skills.

So “Skills have no memory” isn’t entirely a flaw; it’s more a boundary of responsibility:

• changes in the current task go into context;
• long-term preferences are kept by memory or project instructions;
• when the method itself changes, edit the Skill explicitly.

Otherwise, a temporary exception may be mistaken for a long-term rule.

Skills work in both chat and agents

Instruction-only Skills don’t necessarily need an agent.

Review standards, writing voice, analysis frameworks and ways of summarizing meetings can all work in chat environments that support Skills.

But if a Skill needs to read multiple real files, run scripts, call outside tools or check results, it depends more on an agentic environment.

The reason is simple:

a Skill only describes the process; how much it can actually do depends on the files, tools, permissions and runtime the current product provides.

OpenAI currently splits things into three entry points: Chat, Work and Codex. Chat mainly handles questions and conversation, Work is for research and complete deliverables, and Codex is for software development, repos, terminals and tests.

The same “review” kind of Skill might show up in different entry points as:

• Chat: giving review comments;
• Work: reading several documents and producing a full report;
• Codex: checking project files, changing code and running tests.

The Skill didn’t change; the environment it can use did.

How do in-product Skills differ from local Skills?

In-product Skills are usually stored in a platform account or workspace.

Their advantage is that creating, installing and sharing them is easier, with no need to manage local files directly. ChatGPT currently supports creating Skills through conversation, an editor or upload, and sharing them within a workspace.

But which files they can access and which tools they can use is decided by the platform, the plan, the entry point and admin permissions.

Local Skills live directly on your computer or in a project repo.

Codex and Claude Code, for example, can read SKILL.md, scripts and reference material from local directories. A local Skill can go into Git with the project, and can hold a workflow specific to one repo.

The local way is more transparent and better suited to code, files and project-specific tasks; in return, you have to maintain the file structure, dependencies, permissions and versions yourself.

The two aren’t simply a “basic version” and an “advanced version.”

A writing method that doesn’t depend on any particular project is more convenient in-product; a workflow that needs to run local scripts naturally suits a local environment better.

The same Skill won’t automatically sync across all products

OpenAI and Anthropic are both adopting the open Agent Skills file format, which makes Skill files easier to move.

But “compatible format” doesn’t mean “install once, works everywhere.”

OpenAI currently says that personal Skills in ChatGPT need to be added separately on desktop and on web/mobile, and don’t sync automatically; governance and runtime environments may also differ between ChatGPT and Codex.

Anthropic draws an even clearer line between claude.ai, the Claude API and Claude Code: custom Skills for the three need to be uploaded or saved separately and don’t sync automatically; the network, file and code environments available at runtime differ too.

So a pure-text review Skill is usually fairly easy to move.

A Skill that depends on a particular directory structure, scripts, packages or outside tools often needs re-adapting when you move it to another product.

How do you create a Skill from scratch?

You can start with the simplest instruction-only version, without adding scripts and complex directories at the start.

A practical starting point is to find three real occurrences of a similar task, then work out:

• which requests come up every time;
• when this method should be invoked;
• when it shouldn’t be used;
• what the steps are;
• how to judge whether the result is acceptable.

Then test it on new tasks, not just the cases you used to create it.

If it doesn’t appear when it should be invoked, you usually need to change the name and description.

If it triggers on every task, its scope is written too broadly.

If it carries out the process completely but the result is still poor, the problem may not be the invocation mechanism but the method itself.

If the rules keep getting longer, one Skill may be taking on several different tasks and needs splitting.

Codex’s Skill Creator currently generates an instruction-only Skill by default; Claude’s official advice likewise stresses keeping a Skill clear, and testing and iterating with real situations.

Check public Skills the way you’d check software you install

Skills you make yourself can be distributed through workspace sharing, exported files, project repos or plugins.

When using Skills others have published, you need to look one step further.

Because they may contain more than text: scripts, outside dependencies, file reads and writes, and tool calls.

OpenAI scans uploaded Skills, but also says plainly that platform scanning can’t replace your own review; Anthropic recommends checking every file in a Skill and evaluating third-party Skills as you would software.

For a first try, it’s better to start with tasks whose results are easy to check and that need few permissions, for example:

• document formatting and voice;
• organizing meeting notes;
• a pre-publish checklist;
• code review;
• fixed data format conversion.

Don’t assume that because a Skill can be installed, it suits your workflow or may access sensitive environments.

A Skill is still a set of instructions for a model to carry out

Skills can improve reuse and consistency, but they don’t turn a language model into a deterministic program.

It may still:

• not be invoked when it should be;
• be triggered on tasks it doesn’t suit;
• skip a step;
• interpret the same rule differently;
• carry out the whole process and still reach a wrong judgment.

Nor can it replace permission controls, human approval and safety mechanisms.

If an operation must absolutely never happen, writing “never do this” in a Skill isn’t enough.

So what a Skill adds beyond a prompt isn’t some magical intelligence.

What it adds is:

a clearer scope, a more stable way of being invoked, and the ability to carry material, scripts and tool workflows.

A simple task may need only a saved prompt.

Only when a method needs to be discovered automatically, invoked again and again, or must work together with material, scripts and a real environment, does a Skill really show its difference.