One Skill Instead of Dozens of Prompts: How to Create Your Own Way of Working with AI

If you use AI tools regularly, you soon notice a recurring pattern. Every time, you have to explain again what you expect, describe the context, spell out how the task should be done, define the response format and remind the AI of the rules it should follow.

Even a well-crafted prompt often solves this problem only partially. You can save it in a separate document, a prompt library or a notebook and then copy it into new conversations. But it is still a single instruction that you have to find, paste, fill in and adapt to the task at hand.

What if, instead of explaining to the AI every time how it should work, you could write that instruction just once?

That is exactly what skills are for. A skill lets you describe a repeatable way of doing a task and store it in a form the AI uses whenever it recognizes the right scenario. It can contain not only an instruction but also the stages of a process, the required response format, rules of conduct, examples, reference materials, templates and even scripts that support more complex operations.

In practice, this means you can turn a proven way of working into a reusable module. Instead of writing a separate, elaborate prompt for every task, you can prepare a skill that describes the whole process. Such a skill can define, for example, how the AI should:

• analyze technical documentation,
• check content for unverified information,
• write articles in an agreed style,
• create presentations based on a company template,
• organize data according to a set procedure,
• generate documents in line with the organization's visual identity,
• carry out a multi-stage analysis of files,
• point out information that could not be verified.

So the key change is not just a shorter prompt. It is the move from one-off commands to a repeatable way of working with AI that can keep evolving.

A skill is more than a saved prompt

At first glance, a skill may look like an extended system prompt. In both cases, we give the model instructions on how to perform a task. The difference becomes clear when the process starts to require more components.

A prompt is usually a single message. A skill, on the other hand, is an organized package that can contain:

• a name and a description of its purpose,
• information on when it should be used,
• instructions stored in a SKILL.md file,
• detailed rules for carrying out the task,
• examples of expected results,
• reference files,
• ready-made templates,
• scripts that perform repetitive operations,
• other resources needed during the work.

This means the main instruction does not have to contain every possible piece of information. Day to day, the AI only "sees" the skill's name and description. It loads the full instruction only when it decides the skill is useful, and the supporting files only when the instruction tells it to. This mechanism is called progressive disclosure.

This is especially useful in more complex processes. An instruction for preparing a report can refer to a separate document template. A data analysis skill can use a script that performs calculations. A skill that supports creating company materials can include guidelines on language, structure, formatting and visual identity. So instead of building one very long prompt, you can prepare an organized set of instructions and resources.

A skill does not change the model

Creating a skill does not mean retraining the model or permanently teaching it new information.

A skill gives the AI additional instructions and materials needed to perform a specific kind of task. You can compare it to a procedure handed to a new employee. The model does not gain new knowledge permanently, but it receives a structured description of how it should act in a given situation. That is why it is more accurate to say that a skill organizes the way the AI works than that it changes the model itself.

This matters in practice too. A skill can be updated as the process changes, extended with new examples, supplemented with additional resources and improved based on test results. You do not need to train your own model or rebuild the whole solution to do that.

Where can you find skills?

Skills are not a single vendor's solution. Mechanisms of this kind appear in various AI environments, both in applications for business users and in developer tools. Below are a few examples - this is not a complete list.

Microsoft Copilot Studio. The feature is called Agent skills. A skill can be created from scratch, generated with the help of AI, or uploaded as a ready-made SKILL.md file or a ZIP package with supporting files such as scripts, templates and reference documents. A skill is a component added to an agent, not a replacement for an entire agent, connector or knowledge source.

ChatGPT and OpenAI tools. A skill can be created in a conversation (e.g. with the command "Build me a skill…"), prepared outside ChatGPT, or uploaded as a ready-made package from your computer. Before it is shared, ChatGPT scans the uploaded skill. In an organization, the administrator decides who can create, upload and share skills - with specific people, groups or the entire workspace. OpenAI describes skills as reusable workflows that can contain instructions, supporting files and code.

Claude. Anthropic uses the names Skills and Agent Skills. Skills are available on the Free, Pro, Max, Team and Enterprise plans, as well as in Claude Code and via the API. They require code execution to be enabled. You can use ready-made skills from Anthropic and partners, skills shared within your organization, and your own skills built for a specific process.

Microsoft, OpenAI and Anthropic are only examples. The Agent Skills format is being developed as an open standard (specification at agentskills.io), so the same skill can often be moved between tools. However, the feature name, installation method and scope of capabilities may differ from platform to platform.

A skill is not a connector

A skill primarily describes how to perform a task. It can contain instructions, procedures, examples and supporting files, but on its own it does not provide access to email, company documents, a CRM system or other services. That kind of access requires a separate integration, such as a connector, an app, an API or an MCP server.

How to create your own skill in Claude

In Claude, you can build your own skill in two ways: with the skill creator, or by hand, by preparing a package with a SKILL.md file and additional resources. In both examples, we will build a skill for company presentations:

• Method 1 - the company-brand-presentation skill, generated by the creator. It uses the company visual identity and logo stored in the package (brand tokens and logo variants).
• Method 2 - the company-presentation skill, built by hand. It uses our company theme stored in the package.

Both skills share the same data protection rule: the only company data a presentation may contain is our own company logo. No names or logos of clients and partners, no contact details, personal data, prices, results or confidential materials. The skill marks missing information as "To be completed".

Method 1: Creating a skill with the skill creator

The creator (skill-creator, provided by Anthropic) gathers the requirements, asks follow-up questions if needed and prepares a ready-made skill structure.

Step 1: Enable skills

1. Open Claude's settings.
2. Go to Settings → Capabilities and turn on Code execution and file creation. Without this option, the skills section does not work.
3. Go to Customize → Skills. Here you will find skills from Anthropic (including skill-creator), skills shared in your organization and your own skills.

On the Team and Enterprise plans, both features - code execution and skills - must first be enabled by the organization owner in Organization settings → Plugins & skills (Policy tab).

Step 2: Launch the skill creator

The easiest way is to launch the creator directly in a conversation. Type a slash and the skill name - /skill-creator - in the message box and select it from the list. In the same message, paste the task description from Step 3.

You can also write in plain language, e.g. "Use skill-creator and help me build a skill for company presentations step by step".

Step 3: Describe the task precisely

The quality of the skill depends on the quality of the description. Instead of a vague request ("make me a presentation skill"), prepare a complete brief that answers five questions:

• When should the skill run (which user requests)?
• What needs to be established before starting work?
• In what order should the stages be carried out?
• What should the result be, and in what format?
• What must the skill not do?

The brief used in our example. Paste it into the message box right after calling /skill-creator (Step 2) and send everything as a single message:

/skill-creator The skill should run when the user asks to prepare a company
presentation, create slides based on a document, or adapt material to the brand
guidelines.

Before starting, establish: the purpose of the presentation, the target audience,
the language, the number of slides, the visual variant and the available source
materials.

First prepare a slide plan. Create the PPTX file only after the plan has been
explicitly approved. The only company data you may use is our company logo. Do not
use client names or logos, personal data or confidential materials. Mark missing
information as "To be completed".

Step 4: Answer the creator's questions

The creator asks about whatever is missing from the brief: presentation style, slide layout, file format, how to handle missing data or quality criteria. If the brief is complete, the creator can prepare the skill straight away - as it did in our example. After preparing a draft, the creator also suggests a few test cases and asks whether to run them.

If questions do come up, answer specifically and in a way that can be verified. An example of a good answer:

Each slide should have one key message, a clear hierarchy and no more than 5
bullet points. If no brand materials are provided, use a neutral demo theme.

Step 5: Review the generated skill

Before you save the skill, check it against five points:

• the name and description clearly state when the skill should run,
• the process follows the right order of steps,
• the slide plan must be approved before the PPTX is created,
• missing data is not filled in with guesses,
• apart from the logo, the skill does not use any company data, and the package contains no client names or confidential files.

The most important part of the file is the header. The description field is the main triggering mechanism - Claude compares the user's request against it. That is why the description lists both what the skill does and the typical phrases that should trigger it. An excerpt of the generated file:

---
name: company-brand-presentation
description: >
  Prepare a branded company presentation as an editable PowerPoint (.pptx)
  using the company visual identity and logo. Use this skill whenever the user
  asks to prepare a company presentation, build a deck or slides, turn a
  document, report, PDF, notes or offer into slides, or adapt/rebrand existing
  material or an existing deck to the company brand guidelines - even if they
  only say "make slides from this", "przygotuj prezentację", "zrób slajdy z
  tego dokumentu" or "dostosuj to do naszego brandu". The skill first collects
  a brief (purpose, audience, language, slide count, visual variant, sources),
  then proposes a slide plan, and builds the .pptx only after the user
  explicitly approves the plan. It uses no company data other than the logo
  and never includes client names or logos, personal data or confidential
  material.
---

# Company brand presentation
## What is in this skill               - logo, brand tokens, helper scripts
## Data rules (apply at every stage)   - the logo is the only company data allowed
## Stage 1 - Brief                     - six parameters, ask only about gaps
## Stage 2 - Read the sources          - facts, gaps, data that must not be used
## Stage 3 - Slide plan                - plan format, "To be completed" fields
## Stage 4 - Approval gate, then build - what is and is not approval of the plan
## Stage 5 - Quality check             - qa_check.py, validator, render
## Stage 6 - Deliver                   - summary and open "To be completed" items
## Language and typography             - diacritics, punctuation

assets/logo/ - four logo variants
references/brand-tokens.md - colors, fonts and layouts of the Dark and Light variants
scripts/brand.js, scripts/qa_check.py - build helper and automated checks

Step 6: Save the skill

The creator delivers the finished skill as a file with the .skill extension. Click the file card to open a preview and select Save skill. Before saving, you can review and edit the files directly in the editor.

Once saved, the skill appears in Customize → Skills with an on/off toggle. Make sure it is enabled. On the Team and Enterprise plans, you can also share it with the entire organization using the Publish to org button, if the administrator's settings allow it.

Step 7: Test it

Open a new conversation, attach a sample document and send your request. It is worth running two tests: one in plain language (to check whether the skill triggers on its own based on the description) and one that calls /company-brand-presentation directly (to check the procedure itself). Our test - deliberately without any rules in the request, so we can check whether the plan and the stop before the PPTX come from the skill, not from the prompt:

Create presentation based on this file.

What to look for in the response:

• The right skill - Claude tells you which skill it used.
• Missing information - the skill uses what has already been provided and does not ask for it again. It asks about missing parameters or makes explicit assumptions for you to confirm.
• The plan - it has the required format, and gaps are marked as "To be completed".
• Stopping - no PPTX file is created before the plan is approved.

In our test, the skill launched correctly and prepared an 8-slide plan. It took the source material from the attached file; below the plan, it listed the fields to be completed, what it anonymized, the assumptions it made and what it left out, and asked us to approve the plan. The PPTX file was created only after we replied "yes".

It is also worth testing a request for the plan right away. In the first version of the skill, such a test revealed a gap: the instruction did not settle what to do when the user wants the plan immediately but the skill is supposed to ask questions first. So we added a rule that in this situation the skill makes assumptions and asks for them to be confirmed together with the plan approval. That is exactly why you test - to catch ambiguities like this before sharing the skill with others.

Method 2: Building a custom skill by hand

This method gives you full control over the package structure and how materials are organized. We will build the company-presentation skill, which creates a presentation from a source document in our company theme.

Step 1: Create the folder structure

company-presentation/
├── SKILL.md                     main instruction (required)
├── references/
│   └── brand-guidelines.md      brand and PPTX build guidelines
└── assets/
    └── theme/
        ├── README.md            description of the theme files
        ├── design-system-dark.html
        ├── design-system-light.html
        ├── export-rules.md
        ├── template.pptx
        ├── ColorVersion1.png    color logo (Light)
        ├── ColorVersion2.png    color logo (Dark)
        ├── DarkVersion.png      logo for light backgrounds
        └── WhiteVerion.png      logo for dark backgrounds

Each folder has a different role:

• SKILL.md - the only required file. It contains the header with the name and description, and the main procedure.
• references/ - documents Claude reads only when the instruction tells it to.
• assets/ - files used in the output: templates, palettes, logos.
• scripts/ (optional, not used here) - scripts for repetitive operations.

A minimal skill can contain just SKILL.md. Add extra folders only when they genuinely support the process.

Folder name and the name field. The Agent Skills specification requires the folder name and the name field in SKILL.md to be identical, which is why both are called company-presentation in our package. Stick to this rule if you plan to use the skill in other standard-compliant tools as well (e.g. VS Code with GitHub Copilot).

A side note: Claude itself is more lenient - it also accepts a package with different names and shows the one from the name field in the interface.

Step 2: Write the SKILL.md header

The SKILL.md file starts with a YAML header enclosed in --- lines. Two fields are required:

• name - the skill identifier: up to 64 characters, lowercase letters, digits and hyphens only, no diacritics.
• description - up to 1024 characters. It describes what the skill does and when to use it. This is the only part of the skill Claude sees before launching it, so it is worth including the typical phrases users would use.

Step 3: Describe the workflow

Below the header, write the procedure as a sequence of steps. Our skill has eight steps and a section of hard rules:

# Presentation based on a source
## Objective
## Package contents
## Company data and confidentiality
## Source of truth
## Workflow
### Step 0 - collect requirements
### Step 1 - inventory the sources
### Step 2 - analyze the material
### Step 3 - propose the narrative
### Step 4 - prepare the slide plan
### Step 5 - approval gate
### Step 6 - build the presentation
### Step 7 - quality assurance
## Hard rules
## Result

What each step does:

• Step 0 - establishes the purpose, audience, language, number of slides, variant (Dark or Light) and the nature of the material. It does not block the work: missing parameters are replaced with explicit assumptions, and if no variant is specified, it chooses Dark.
• Step 1 - lists the sources. If one of them cannot be read, it says so directly instead of filling the gap with the model's knowledge.
• Step 2 - extracts the thesis, facts, figures, gaps and data that must not be used.
• Step 3 - builds the narrative: one slide, one message.
• Step 4 - presents the plan in the chat. For each slide it gives the source, and at the end it adds the sections "To be checked / source gaps" and "Omitted elements".
• Step 5 - waits for explicit approval. Corrections or a general "looks good" do not count as approval.
• Step 6 - builds a native, editable PPTX following the guidelines in references.
• Step 7 - checks consistency with the sources, the absence of company data other than the logo, readability, validation and the rendering of all slides.

The "Hard rules" section repeats the rules the skill must not break at any step: plan first, then the file; do not invent data; mark editorial suggestions as suggestions; the logo is the only company data allowed.

You can download the full SKILL.md file of the company-presentation skill and use it as a starting point for your own skill.

Step 4: Separate the workflow from supporting materials

Keep the main procedure in SKILL.md and move the details to the references folder. It is enough for the instruction to say when to reach for a given file. In our skill, Step 6 begins with the sentence:

Read references/brand-guidelines.md and follow it.

The brand-guidelines.md file contains everything that is only needed when building the file: the order of brand sources, a table matching the logo to the variant, a list of data that must not be included, font selection rules, writing style, rules for building slides natively, common tool pitfalls, and the quality check and delivery procedure.

Thanks to this split, Claude does not load these details until they are needed - at the slide plan stage, they take up no space in the context.

Step 5: Add materials to the assets folder

Put the visual materials the skill should use in the assets/theme folder: design-system files with colors, fonts and slide layouts, export rules, a base PPTX template and variants of our company logo.

The only company data the skill uses is our logo. Do not add client or partner logos or presentations, real results, contact details, confidential roadmaps, or files containing client comments and metadata to the package.

Also pay attention to the sample content in the templates. Our design-system files contain a sample quote, a phone number and a website address. The skill has an explicit instruction to treat them only as a layout reference and not to carry them over to the slides.

Step 6: Package and upload the skill

1. Make sure SKILL.md is directly in the skill's root folder, not in a subfolder.
2. Compress the whole folder into a ZIP file.
3. In Claude, open Customize → Skills, click Add and choose to upload a skill (Upload a skill).
4. Select the ZIP file. Claude shows a preview of the name and description from the header - check that they are correct and click Upload.
5. Enable the skill with the toggle in the skills list.

On the Team and Enterprise plans, the organization owner can also upload a skill so that it automatically appears for all users.

Step 7: Test the skill

The test works the same way as in Method 1. This time we call the skill explicitly with the /company-presentation command, using the same brief and the same request.

This skill deliberately asks no questions before the plan. As defined in Step 0, it listed the sources and the assumptions made - including the default Dark variant - and then presented the plan. For each slide, it gave the part of the brief it is based on. At the end, it listed the gaps in the sources (for example, the Copilot Studio section, which contains only a link) and the omitted elements (for example, the names of the companies behind the independent analyses). It marked the recommendation on the last slide as an editorial suggestion, because it does not come from the source. It did not create a PPTX file.

It is also worth testing harder cases: a source containing a client name and contact details (the skill should omit them and say so), a request for a PPTX "right away, without a plan" (the skill should still show the plan), and a request with no material attached.

Method 1 or Method 2?

Both methods lead to the same result: a package with a SKILL.md file, in which the description says when the skill should run and the procedure says how it should work. In both tests, the skill prepared a slide plan and stopped before creating the PPTX file. The difference lies in who decides on the details.

The skill creator is the fastest way to a working skill. A good brief is enough, and the creator prepares the structure, the procedure and the supporting files on its own. Building the package by hand takes more work, but it gives you full control over every step, rule and file - including your own theme, template and logos in assets. It is the better choice for processes that should always run the same way.

In practice, combining both methods works well: the creator prepares the first version, and then you refine it by hand - you add rules, move details to references and put your own materials in assets.

How to make a skill more effective

• One skill should handle one main, repeatable process.
• The trigger description should point to specific situations and typical user phrases.
• Do not keep several skills with similar descriptions enabled at the same time. They will compete with each other, and it will be hard to predict which one runs. Disable the ones you do not need or narrow their descriptions.
• For presentations and other costly files, require approval of a plan before generating the output.
• Missing data should lead to a question, an explicit assumption or a "To be completed" marker - not to guessing.
• State explicitly which data the skill must not use. In our case: the logo is the only company data allowed.
• Keep the main workflow in SKILL.md and the details in references, assets and scripts.
• Test faulty and incomplete cases too, and improve the skill based on the results.
• Before sharing the package, check file names, comments, notes, metadata and sample content in templates.

Summary

Skills are a natural next step in the evolution of working with AI. Prompts helped us communicate with models more effectively, but for repetitive tasks, constantly copying and adapting the same instructions quickly becomes inefficient. A skill lets you go one step further: capture not just a single command but an entire proven way of getting a task done.

In a business environment, this can be particularly valuable. A well-designed skill helps turn an employee's know-how, a company procedure or an established workflow into a solution the whole team can use. Users do not have to recreate elaborate instructions on their own, and the results are more consistent with the agreed standards.

Skills do not replace prompts. The prompt still defines what we want to achieve, while the skill describes how the AI should perform the task. That is exactly why the two mechanisms complement each other so well.

So it is worth looking at skills not as another technological novelty, but as a way of organizing and reusing organizational knowledge. Prompt libraries were a good start. Libraries of company skills may be the next stage of mature AI adoption. The question is no longer just "What prompt should I write?", but also "Which repetitive tasks in my company are worth turning into skills?"

As of 25 September 2026. Option names, plan availability and the way skills are installed may change as Claude, ChatGPT and Copilot Studio evolve.

Sources

• Claude Help Center - Use skills in Claude
• Claude Help Center - What are skills?
• Agent Skills - format specification
• Microsoft Learn - Skills overview for agents (Copilot Studio)
• OpenAI Help Center - Skills in ChatGPT