Why I finally started using skills in ChatGPT

For a long time, I didn't see much reason to use skills in ChatGPT.

That sentence needs one qualification. Skills themselves were not new to me. I had used them now and again in Claude, and later we started using them in our own AI applications at Schmuki.

That is where the idea really clicked.

So when I returned to skills in ChatGPT, I wasn't discovering a new concept. I was, in a sense, backporting a way of working that had already become useful elsewhere.

And that is probably why my view changed so much.

I had been working extensively with AI for years, developing ideas, researching subjects, building knowledge-based applications and experimenting with different ways of organising information. ChatGPT was already an important part of my work. But its mechanisms for extending that work had often felt fragmented and difficult to understand.

Meanwhile, our own work was becoming more structured. We were separating knowledge from instructions, moving information into external repositories and building applications that needed to guide people through longer, more deliberate processes.

Skills suddenly had a job to do.

Then ChatGPT itself began to change.

The interesting part, for me, is how those two developments eventually met.

When conversations were enough

Much of our early work with conversational AI involved relatively short interactions. We would help someone explore a question, establish the relevant circumstances and work towards a useful answer.

Even when the underlying knowledge was complicated, the interaction itself could be quite straightforward.

For example, in our work with knowledge-intensive organisations, an assistant might help someone understand a particular legal, financial or administrative situation. It would ask a few questions, establish the context and then consult relevant knowledge to formulate a response.

This worked remarkably well, provided the assistant had access to reliable information and its instructions were carefully designed.

We experimented with system instructions, knowledge files, external integrations and specialised assistants. They all had their uses, although the boundaries between them were not always obvious.

At that stage, I didn't particularly need another mechanism for organising instructions.

The move towards external knowledge

One of the biggest changes came when we started organising more of our knowledge outside the AI systems themselves.

Instead of treating conversations and uploaded documents as the primary home of our knowledge, we began maintaining structured repositories. These could contain research, documentation, legislation, conceptual models and other material that we wanted to preserve and develop over time.

That mattered for several reasons.

Knowledge could now be maintained independently of whichever model happened to use it. We could update it, organise it, track changes and make it available to different AI environments.

It also gave us more control over what was authoritative, what was still being developed and what had changed over time.

But it introduced another distinction that turned out to be just as important.

Having knowledge available is not the same as knowing how to work with it.

A repository might contain extensive information about legislation, education or public administration. But that doesn't necessarily tell an AI assistant how to approach a particular problem.

Which questions should it ask first? When should it retrieve information? How should it deal with uncertainty? When does it have enough context to proceed? Which parts of the process require a different kind of reasoning?

Those are questions about method rather than knowledge.

We already had methods for doing many of these things. Some were embedded in system prompts. Others existed largely in our heads or had emerged through repeated work with clients and applications.

The challenge was finding a better way to preserve and reuse them.

The concept that changed my thinking

Around this time, I became interested in the idea of progressive disclosure.

The principle is simple: don't give an AI model everything it might possibly need at the beginning of a conversation. Make additional information and instructions available when they become relevant.

Large language models have a context window, the working space containing the conversation, instructions, retrieved information and other material the model can use.

There is a natural temptation to fill that space with as much useful information as possible. More context should produce better answers, shouldn't it?

Not necessarily.

Large quantities of irrelevant information can introduce distractions, competing instructions and unnecessary complexity. They also consume tokens and can increase processing costs and latency.

Imagine an assistant that has ten different working methods available. One describes how to conduct an intake, another how to analyse legislation, a third how to review a document, and several others how to produce particular kinds of advice or reports.

You could place all those instructions into the assistant's context and hope it works out which ones matter.

But most of the time, it doesn't need all ten.

Progressive disclosure takes a different approach. The model initially receives enough information to recognise which capabilities are available. When a particular capability becomes relevant, it can load the detailed instructions and supporting resources.

This is one of the ideas behind Agent Skills.

A skill can have a short description explaining what it does and when it should be used, while the detailed method sits in a separate SKILL.md file. Supporting references, templates or scripts can be consulted when required.

The model does not need to carry every detail of every available method throughout the conversation.

Of course, progressive disclosure does not magically create better reasoning. The model still has to recognise the right capability, retrieval itself has costs, and badly written instructions remain badly written instructions.

But the principle changed the way I thought about context.

The objective was no longer to give the model as much context as possible, but to give it the right context at the right moment.

Where skills became real for me

I had already encountered skills in Claude and used them occasionally. I understood the basic idea.

But it was only when we started applying them in our own AI applications at Schmuki that I really saw their value.

Our clients were beginning to ask for interactions that extended beyond a handful of conversational turns.

Rather than simply answering a question, an application might need to guide someone through a structured process. It might first establish the person's circumstances, identify the actual problem, ask follow-up questions, consult specialist knowledge and then help evaluate possible courses of action.

Consider an issue involving legislation and personal finances.

Before consulting the applicable rules, it may be necessary to understand the household situation, the nature of the problem and the outcome someone is trying to achieve.

That preliminary stage requires a different method from the legal or financial analysis that follows. And helping someone understand the resulting options may require yet another approach.

You can try to describe that entire process in one enormous set of instructions. But as the number of situations grows, those instructions become increasingly difficult to maintain, improve and test.

Skills gave us another way to organise the problem.

A skill could describe how to conduct an initial assessment. Another could guide a particular form of analysis. A third could help structure the resulting advice.

They could be used separately or combined as part of a longer process.

This doesn't make skills a complete workflow engine. Longer interactions may still require explicit state management, deterministic controls, validation and orchestration. Some decisions should remain with people.

But skills provide reusable building blocks for the parts of a process that depend on method.

That was the point at which I stopped thinking of them as another AI feature.

They had become a practical way to preserve something we were developing ourselves: how we wanted an AI system to work.

A small example

Suppose an AI application needs to help someone work through a complex issue.

The knowledge it needs might live in an external repository: legislation, policy documents, organisational guidance and specialist material.

But before searching that knowledge, the application may need to establish what kind of situation it is dealing with.

A reusable assessment skill can describe that method. It might tell the assistant which distinctions matter, which questions are worth asking, when not to jump to a conclusion and what information has to be established before moving on.

The skill does not need to contain the legislation itself.

That remains in the knowledge source, where it can be updated and governed independently.

The skill preserves the method for getting from an initial, often messy user question to the point where the relevant knowledge can actually be applied.

That separation became increasingly important to us.

Knowledge tells the system what is known. A skill can help describe how to work with that knowledge.

Once I saw that distinction operating in a real application, the usefulness of skills became much less abstract.

So what exactly is a skill?

A skill is essentially a reusable set of instructions and supporting resources that an AI system can apply to a particular task.

It might describe a method of analysis, a writing process, a research procedure or a sequence of steps for producing a particular result.

The underlying structure is surprisingly simple.

The central file is usually called SKILL.md, written in Markdown. A skill can also contain reference documents, templates, examples and, where supported, executable scripts.

The important difference from an ordinary prompt is not that the instructions are somehow more intelligent.

It is how they are packaged, discovered, maintained and reused.

A well-designed skill describes both what it does and when it should be applied. That allows an AI environment to recognise a relevant situation and load the more detailed instructions only when needed.

This also makes the idea interesting beyond one particular provider.

The Agent Skills specification provides a common format that can be supported by different compatible environments, although implementations, permissions and available capabilities can differ.

That means a working method can increasingly be maintained outside a single conversation or even a single AI product.

For organisations that are gradually accumulating their own ways of working with AI, that is an attractive property.

Where AGENTS.md and MCP fit in

There are two other concepts worth distinguishing because they often appear in the same conversations.

The first is AGENTS.md, a convention for providing instructions to AI agents working within a repository.

A repository might, for example, explain its structure, conventions, authoritative sources and how changes should be made.

Those instructions describe the environment in which the agent is working.

A skill, by contrast, typically describes a reusable capability or method that becomes relevant for a particular task.

The second concept is MCP, the Model Context Protocol.

MCP provides a standardised way for AI applications to interact with external tools and data sources. An MCP connection might allow an assistant to search a repository, retrieve information from a business application or perform an authorised action.

These concepts can complement one another without forming a rigid hierarchy.

AGENTS.md can explain the working environment. A skill can describe the method. MCP can provide access to tools and information. The knowledge itself can remain in an external repository.

In practice, responsibilities sometimes overlap. The important part is not creating a perfect taxonomy, but knowing why a piece of information or instruction belongs where it does.

This separation has become increasingly useful in our own work.

And then I returned to ChatGPT

By this point, skills were no longer particularly new to me.

I had encountered them in Claude, and we had begun using them seriously in our own applications. I now understood the problem they solved.

But I still wasn't really using them in ChatGPT.

Partly, I hadn't needed to. And partly, ChatGPT's approach to extending its capabilities had felt hazy.

We had Custom GPTs, the GPT Store, connectors, apps, MCP integrations and several ways of configuring behaviour. Useful things were possible, but discovering what was available, where it lived and how the pieces fitted together was not always straightforward.

I experimented with some of it. Some worked well. Other attempts required considerably more effort than I expected.

Eventually, I more or less left the skills question in ChatGPT alone.

Then the architecture started moving.

In July 2026, OpenAI replaced the App Directory with the Plugin Directory. Plugins can bring together different kinds of capabilities, including skills and connected applications. ChatGPT also gained a clearer Skills section within that environment.

OpenAI has since announced that Custom GPTs are planned for retirement, with migration towards plugins. Under the migration model, a GPT's instructions can become a skill, while reference material and connected capabilities are handled within the newer plugin architecture. The exact availability and migration experience can still vary by account and workspace.

The product is still evolving, and I wouldn't pretend every boundary has suddenly become perfectly clear.

But the direction became easier to understand.

And this time I was looking at it from a very different position.

I wasn't asking, Why would I need a skill?

I already knew.

I was asking whether ChatGPT had finally become a useful place to bring in methods that had proved themselves elsewhere.

So I stepped back into the ring.

In software terminology, you could almost call it a backport. We had developed a way of working in one environment, found it useful in our own applications, and were now bringing that approach back into ChatGPT because the surrounding architecture had matured enough to make it worthwhile.

That was the real turning point for me.

Creating and finding skills in ChatGPT

The practical entry point is now the Plugin Directory.

Depending on your account and workspace, you can browse available plugins, inspect their capabilities and install the ones you want to use. Some contain skills only. Others combine reusable instructions with connections to external applications.

Eligible accounts can also create, upload and manage skills directly. Installed skills can be selected explicitly, and ChatGPT can also use a relevant skill automatically when its description matches the task.

I have been experimenting with both ChatGPT Plus and Business and with distributing capabilities across different working environments.

The mechanics are useful, but they are not the part I find most interesting.

The harder question is deciding what should become a skill in the first place.

Not every useful prompt needs to become one. Not every process benefits from being broken into separate capabilities. Sometimes a good instruction inside a conversation is still the simplest solution.

I find skills most useful when they preserve a method that is used repeatedly, benefits from being maintained separately and contains enough judgement or structure that I don't want to reconstruct it every time.

There is also a growing collection of reusable skills outside ChatGPT. Because the underlying format is relatively transparent, it is possible to inspect how a skill works, adapt it and maintain your own version.

I would do exactly that before trusting a skill from an unfamiliar source. Skills can include executable code as well as instructions, so they deserve the same scrutiny as other software and integrations.

The Agent Skills Directory

Discover and install skills for AI agents.

Skills

What it has brought me

I have now created several plugins and skills for different purposes.

Some connect to external knowledge. Others preserve methods for research, inquiry, educational guidance, writing or creative thinking. Some combine instructions with MCP-based tools.

The immediate benefit is practical. I no longer have to reconstruct the same method repeatedly or include every instruction in every conversation.

But there is another benefit that I didn't fully anticipate.

Creating a skill forces you to examine the method itself.

Something that feels perfectly natural when you do it yourself can turn out to contain quite a few implicit decisions. What information do I need before beginning? Which steps are essential? Which are optional? What should happen when information is missing? When should the assistant stop and ask? How do I recognise that the task has been completed properly?

Writing those decisions down makes them visible.

That makes them easier to discuss, improve and test.

This does not mean that documenting a professional method automatically reproduces professional expertise. A skill can be incomplete. A model can misunderstand the instructions. Context still matters, and human judgement remains important.

But even before execution, there is value in making a method explicit.

It encourages us to examine how we actually work.

From conversations to reusable methods

Looking back, I understand why skills didn't initially appeal to me in ChatGPT.

At the time, they didn't solve an urgent problem for me. Conversations, instructions and external knowledge were often sufficient, and ChatGPT's surrounding architecture was difficult enough to understand that I didn't feel compelled to invest heavily in it.

The important shift happened elsewhere.

Our knowledge moved into more durable external structures. Our own AI applications began supporting longer and more complex interactions. We needed reusable methods rather than ever larger blocks of instructions.

Skills became useful because the work changed.

Only after seeing that value in practice did I return to ChatGPT and discover that ChatGPT had changed too.

That combination is what made the difference.

I am still learning how best to organise all of this. I don't think there is one architecture that will suit every organisation or every application. Skills will not remove the need for reliable knowledge, evaluation, system design or human judgement.

But they do point towards a broader change in how we work with AI.

For a long time, much of the discussion about language models revolved around prompting. How should we formulate our questions? Which instructions produce better results? How do we get the model to behave in the way we want?

Those questions still matter.

But another question is becoming increasingly important:

How do we make our accumulated expertise available to AI systems without having to reconstruct it every time?

That is a different challenge.

It asks us to look beyond individual conversations and think about the knowledge, methods and working practices that organisations develop over time.

Some of that expertise will remain difficult to articulate. Some depends on experience, context and human judgement. But other parts can be described, examined, improved and shared.

Skills offer one practical way to begin doing that.

And perhaps that is why I finally started using them seriously in ChatGPT.

I didn't discover skills there.

I came back to ChatGPT after learning elsewhere what they were actually good for.

We began by learning how to ask AI better questions.

Now we are learning how to make our knowledge, methods and tools available to AI systems in a more deliberate and reusable form.

That feels like a meaningful next step.