How to Build a ChatGPT Skill That Actually Knows When to Help

For the broader introduction to what Skills are and what I learned from testing one, read ChatGPT Skills Explained: I Built One and Tested It. This tutorial turns that conceptual introduction into a reusable design and testing method.

This is the practical companion to my Systems Strategist Skill experiment. Start here for the method, or open the Lab for the screenshots, paired conversations, and limits of the evidence.

Creating a ChatGPT Skill is relatively easy. Deciding what should become a Skill, when it should activate, and when it should stay out of the way is harder. That distinction matters. OpenAI describes Skills as reusable workflows with task-specific instructions and supporting resources. A relevant installed Skill can be selected automatically or invoked explicitly. That possibility is a reason to test its boundaries, not a guarantee that every matching prompt will activate it.

So the important question is not only:

How do I create a SKILL.md file?

It is:

What should someone with this Skill reliably know how to do?

I ran into that question while designing my own Skills. What started as an attempt to package some of my systems-thinking methods into a reusable Skill quickly became a more interesting design problem. How broad should it be?

What should trigger it?

What should not trigger it?

When should it challenge my assumptions?

When should it stop analyzing and act?

When should another Skill take over?

What belongs in the main instructions, and what belongs in supporting reference material?

Those decisions matter more than simply creating the file. This guide turns the design process behind my Systems Strategist experiment into a method you can use for your own. The companion Lab documents the results; this article explains how to apply the method.

1. Start with a capability, not a topic

One of the easiest mistakes is confusing a topic with a capability. For example:

Skill: Risk Reversal
Skill: CAC
Skill: RAG
Skill: Prompt Engineering

Those are useful concepts. They are not necessarily useful Skills. A better question is:

Can this Skill receive a real situation and reliably produce a useful outcome?

For example:

COMMERCIAL GROWTH MENTOR

Can diagnose and improve:

market
→ offer
→ demand
→ conversion
→ monetization
→ retention

Or:

SYSTEMS STRATEGIST

Can:

frame
→ map
→ diagnose
→ identify constraint
→ find leverage
→ intervene
→ test
→ update

The distinction is important. A topic is something ChatGPT can know about. A Skill should usually describe something ChatGPT can repeatedly do. “RAG” is a topic. “Design a reliable knowledge-retrieval workflow and determine when RAG is appropriate” is a capability.

“Pricing” is a topic. “Diagnose a pricing problem and design a testable pricing intervention” is a capability. “Systems thinking” is a topic. “Identify the system producing a recurring outcome, locate the current constraint, and design a measurable intervention” is a capability.

Thinking this way also prevents your Skill library from slowly turning into a glossary. Not every framework needs its own Skill. Sometimes a framework belongs inside a broader capability.

2. Define the capability contract

Before writing the actual Skill, I now define its capability contract. The contract answers:

What job does this capability own?

For my Systems Strategist Skill, the working mission is:

MISSION

Solve complex real-world problems by identifying
the system producing the outcome, locating the
current constraint, finding leverage, and designing
evidence-driven interventions.

Then I define the operating loop:

Already, that tells me much more than:

Think strategically. or:

Use systems thinking. Those are aspirations. The capability contract begins to define behavior. Before building the Skill itself, I want answers to questions such as:

• What is the mission?
• What kinds of problems does it own?
• What inputs should it expect?
• What useful result should it produce?
• What decisions does it repeatedly make?
• What should trigger it?
• What should not trigger it?
• What assumptions should it challenge?
• What belongs to another capability?
• What supporting knowledge does it need?
• How will I test whether it works?

Only then do I want to worry about packaging it. This is the mental model I now use:

The file comes relatively late. Most of the important design decisions happen before it.

3. Design activation and non-activation

This is one of the most important parts of Skill design. OpenAI explains automatic and explicit Skill selection. The description helps establish relevance, so scope and negative triggers deserve as much attention as the procedure.

For the Systems Strategist, prompts such as these should be strong matches:

"Where is the bottleneck?"

"Why does this problem keep happening?"

"Help me redesign this process."

"What should I fix first?"

"Why did improving one part make another part worse?"

But that does not mean the Skill should appear whenever a request happens to involve several steps. These should probably stay outside its scope:

"Rewrite this email."

"Summarize this article."

"Change this CSS color."

"Translate this paragraph."

"Give me five YouTube titles."

That led me to one of the most important principles in this entire process:

A good Skill needs to know when not to help.

An overactive Skill can become as annoying as an inactive one. Imagine asking:

Rewrite this customer email so it sounds friendlier. and receiving a six-stage analysis of stakeholders, information flows, bottlenecks, feedback loops, and organizational incentives. Technically sophisticated. Completely unnecessary. The Skill should improve the task.

It should not impose itself on the task.

4. Give each file a clear job

A typical Skill uses SKILL.md as its workflow playbook. I use the main file for the task, inputs, procedure, expected output, and final checks. Supporting material can hold the deeper examples and templates. A more developed Skill might look conceptually like this:

systems-strategist/
├── SKILL.md
├── references/
│   ├── system-mapping.md
│   ├── constraint-diagnosis.md
│   ├── root-cause-analysis.md
│   ├── leverage-and-interventions.md
│   └── experimentation.md
├── scripts/
└── assets/

The way I think about those pieces is:

The goal is not to cram everything you know into SKILL.md. The goal is to encode the smallest reusable procedure that meaningfully changes how ChatGPT performs the work.

5. Write a procedure you can test

Compare these two approaches.

Think like a systems thinker.

Be strategic.

Look for bottlenecks.

Consider root causes.

Nothing is technically wrong with those instructions. But each one leaves a large amount of interpretation to the model. Now compare that with:

1. Clarify the desired outcome.

2. Separate observed facts from assumptions.

3. Define the smallest relevant system boundary.

4. Map the important actors, components,
   dependencies, inputs, outputs, and feedback.

5. Identify the most likely current constraint.

6. Generate interventions that directly target
   the constraint.

7. Prefer reversible tests when uncertainty is high.

8. Measure the result.

9. Update the system model from the evidence.

Now the Skill has a decision path. That is the difference between telling AI to be strategic and defining what strategic behavior should actually look like. It also makes the Skill easier to improve later. If the output is weak, I can ask:

Which step is failing?

Instead of:

Why wasn't it strategic enough?

6. Build guardrails into the decision

A useful Skill should define what not to do. For the Systems Strategist, I might include guardrails such as:

Do not:

- assume technology is the solution
- assume AI is the solution
- optimize a local metric while damaging the whole system
- treat assumptions as facts
- mistake symptoms for constraints
- continue researching indefinitely when a meaningful test is possible
- overcomplicate a simple decision

This matters because users often arrive with a solution already embedded in the question. For example:

We need an AI chatbot because customer support is too slow. A weak implementation might immediately help design the chatbot. A better Systems Strategist should first investigate:

Where is the delay?

Intake?
Classification?
Waiting for information?
Ownership?
Approvals?
Knowledge retrieval?
Technical resolution?
Customer response?

The chatbot might still be the right intervention. But it should follow the diagnosis rather than precede it. That is a Skill doing more than remembering instructions. It is preserving judgment.

A useful Skill shouldn't merely remember what you usually say. It should encode how you've learned to make the decision.

7. Define handoffs and responsibility

A reusable capability does not need to solve every downstream problem. Sometimes identifying where its responsibility ends is part of designing it well. The capability stack I am planning looks roughly like this. Only Systems Strategist was built and tested in the companion Lab; the other capabilities below are proposed roles, not a demonstrated chain of installed Skills:

These are not meant to be giant personalities competing to answer every question. Each owns a different kind of judgment. Imagine the Systems Strategist determines that manual document review is the current constraint. Now the problem changes. The next question becomes:

Could AI perform this review reliably?

That is a natural handoff.

Clear ownership is cleaner than creating one giant:

AI BUSINESS STRATEGY SALES SYSTEMS
AUTOMATION COMMUNICATION SUPER SKILL

OpenAI recommends keeping each Skill focused on one job. I apply that principle by separating capabilities with different responsibilities. That advice makes sense to me.

8. Keep one recognizable job

This is closely related to handoffs, but the failure mode is subtle enough to deserve its own section. Imagine:

AI BUSINESS STRATEGY CONTENT SALES AUTOMATION SKILL

It could technically include strategy, sales, marketing, AI architecture, content creation, automation, financial analysis, communication, and research. Nothing stops you from writing it that way. That does not mean you should. The broader a Skill becomes, the harder it is to make its activation precise.

It also becomes easier for instructions intended for one type of problem to distort another. A useful test is:

Does this capability have one recognizable job?

For the Systems Strategist, I can answer in a single sentence:

Understand the system producing the outcome, find the constraint, and design the next useful intervention. That is coherent. AI architecture can live somewhere else. Commercial growth can live somewhere else. Creative production can live somewhere else. Separate capabilities can be coordinated through explicit handoffs, but instructions alone do not guarantee that another Skill will load or inherit the right context. The receiving capability must be available, and the transition needs its own test.

They do not need to be fused into one instruction file to produce an end-to-end result.

9. Test matches, boundaries, and handoffs

Once a Skill looks intelligent on paper, the temptation is to keep editing it. Testing is more valuable. I would build at least four groups of test prompts. Clear matches. Our projects keep missing deadlines even after we hire more people. Help me figure out what's actually going wrong.

A Systems Strategist should be highly relevant here. Useful, but it should not overtake the whole response. We're redesigning our customer onboarding process. What should we examine?

Tasks where the capability would introduce unnecessary complexity. Rewrite this onboarding email so it is clearer. Prompts that begin inside one capability and naturally transition into another. The bottleneck appears to be manual document review. Could an AI agent handle it?

The desired behavior becomes:

This kind of testing exposes problems that are almost impossible to find by admiring the Skill file. A Skill can look perfectly scoped and still activate too often. Or fail when the user phrases the same problem differently. Reality is a much better reviewer. I applied this method to a Systems Strategist Skill and documented four paired tests covering non-activation, systems diagnosis, AI guardrails, and a conceptual handoff. A separate, explicitly invoked synthetic scenario explored the full procedure under ambiguity. These were illustrative runs, not a formal benchmark or a demonstrated Skill-to-Skill handoff.

Read next: Skills Lab: Building and Testing a ChatGPT Systems Strategist Skill

The Lab matters because it shows something the design file cannot:

what the Skill actually did when it encountered the recorded test prompts.

10. Create and install in your supported surface

The exact Skills interface can change. Check the current setup instructions for the surface you use. OpenAI currently documents standalone Skills in the ChatGPT desktop app, Codex CLI, and IDE extension. Skills packaged in plugins also work across Chat and Work on web, desktop, and mobile. Those are different installation paths.

For a guided start, use @skill-creator in ChatGPT Work or $skill-creator in Codex. Describe the job, review the generated instructions, and test them. You can also author a folder containing SKILL.md manually. The practical flow is:

Do not assume every account exposes the same menus or installation route. If Skills is missing, consult the current documentation and your workspace settings before changing your design.

11. Start with a small SKILL.md

A simple Systems Strategist Skill could begin like this. This is an illustrative starting point, not the exact v0.1 tested in the Lab. Check the description length accepted by your creation interface before installing it:

---
name: systems-strategist
description: >
  Diagnose recurring system and process problems,
  bottlenecks, broken handoffs, and unclear priorities.
  Use when the user needs help understanding why an
  outcome keeps recurring, what to fix first, or how
  to test an improvement.

  Do not use for simple rewriting, summarization,
  translation, factual lookup, routine coding edits,
  calculations, formatting, or other tasks that do
  not require system-level diagnosis.
---

# Systems Strategist

## Mission

Help the user understand and improve the system
producing the outcome rather than reacting only
to the visible symptom.

## Workflow

1. Clarify the desired outcome.
2. Separate observations from assumptions.
3. Define the smallest relevant system boundary.
4. Map important components and dependencies.
5. Identify the likely current constraint.
6. Test the diagnosis against available evidence.
7. Generate interventions targeting the constraint.
8. Prefer reversible tests when uncertainty is high.
9. Measure the result.
10. Update the model from the evidence.

## Guardrails

Do not:
- assume technology is the solution
- assume AI is the solution
- optimize local performance at the expense of the whole
- treat assumptions as evidence
- overcomplicate simple questions
- continue analysis when a useful test is available

That is not my finished Skill. It is intentionally small. Notice what it does not contain. It does not attempt to teach ChatGPT everything ever written about systems thinking. It defines how ChatGPT should behave differently when the capability is relevant. And importantly, the description demonstrates both sides of activation:

USE WHEN
...

DO NOT USE WHEN
...

If knowing when not to activate is central to the design philosophy, the example should show that directly.

12. Load references when they help

Some capabilities require deeper knowledge. That does not mean all of it belongs in the main Skill instructions. My Systems Strategist might eventually include references such as:

references/
├── system-mapping.md
├── constraint-diagnosis.md
├── root-cause-analysis.md
├── feedback-loops.md
├── leverage-points.md
└── experimentation.md

Then the main procedure can tell ChatGPT when particular knowledge is useful. For example:

If the problem involves recurring queues,
delays, or accumulated work,
consult constraint-diagnosis.md.

If behavior changes over time through
reinforcing or balancing effects,
consult feedback-loops.md.

That is more useful than:

Read all the reference files. The architecture should be layered:

This is also the layered structure documented by OpenAI: relevance metadata, core instructions, and optional supporting resources. Keep the core capability focused. Make deeper knowledge available when the task actually needs it.

13. Refine from observed failures

Your first Skill will probably fail in ways you did not anticipate. That is useful. Instead of treating failure as proof that the design is bad, turn it into diagnostic information. For example:

This is why I would not spend forever perfecting version one. Build it. Run mixed prompts through it. Observe where it fails. Change the design when the evidence justifies it. Test again. That loop is more valuable than another page of instructions written in advance.

14. Resist the encyclopedia instinct

More instructions do not automatically create more intelligence. Past a certain point, they create more opportunities for irrelevant instructions to compete with the task you actually care about. The layered approach gives each piece a job: relevance first, procedure next, deeper material when needed.

So when you are tempted to add another page of theory to the core file, ask:

Does the Skill need this every time it activates?

If the answer is no, it probably belongs in a reference. Or nowhere at all. A focused Skill is easier to understand. Easier to test. Easier to debug. And easier to compose with other capabilities later.

15. Complete the design worksheet

Before creating a new Skill, I now find it useful to complete a compact design worksheet.

SKILL NAME:

MISSION:
What should this Skill reliably know how to do?

INPUTS:
What kinds of situations should it receive?

OUTPUT:
What useful result should it produce?

CORE LOOP:
1.
2.
3.
4.
5.

STRONG TRIGGERS:
-

NEGATIVE TRIGGERS:
-

GUARDRAILS:
-

PUSHBACK RULES:
-

HANDOFFS:
-

REFERENCE MATERIAL:
-

TEST PROMPTS:

Must activate:
-

Should probably activate:
-

Must not activate:
-

Handoff:
-

This forces me to solve the capability-design problem before worrying about the file structure.

16. Use a guided design prompt

And if you want ChatGPT to help with that work, you can turn the worksheet into a guided design conversation. The important instruction is:

Don't let ChatGPT immediately write SKILL.md. First define the capability. Then build it.

Help me design a ChatGPT Skill for this capability:

[DESCRIBE CAPABILITY — this is the only line you need
to edit before pasting. Describe a capability, not a
topic: e.g. "diagnose why a recurring workflow keeps
breaking and design the next intervention," not
"systems thinking."]

Before writing SKILL.md, first define:

- mission
- inputs
- outputs
- core procedure
- strong triggers
- negative triggers
- guardrails
- handoffs
- reference material
- test prompts

Treat the Skill as a reusable capability,
not a topic or persona.

Prefer procedures over vague instructions.

Keep the main Skill concise and move
deep knowledge into references.

Show me the capability contract first
and wait for approval before generating
the Skill files.

If you already understand the job reasonably well, that may be enough. For a more rigorous process, use the full version.

I want you to help me design a reusable ChatGPT Skill.

Do not jump straight into writing SKILL.md.

First help me define the capability clearly.

My starting idea is:

[DESCRIBE THE PROBLEM, TASK, OR CAPABILITY HERE —
this is the only line you need to edit before pasting.
Describe a capability, not a topic: e.g. "diagnose why
a recurring workflow keeps breaking and design the next
intervention," not "systems thinking."]

Work through the following steps with me:

1. CAPABILITY

Identify what this Skill should reliably know how to DO.

Do not define it as a topic, persona,
or body of knowledge.


2. MISSION

Write a one-sentence mission describing
the useful outcome the Skill should produce.


3. SCOPE

Define:

- what kinds of problems it should handle
- what it should not handle
- what is explicitly out of scope


4. INPUTS

Describe the kinds of user requests or
situations that should activate this Skill.


5. OUTPUTS

Describe the useful results the Skill
should produce.


6. CORE PROCEDURE

Create a repeatable decision or workflow
sequence the Skill should follow.

Prefer clear procedures such as:

UNDERSTAND
→ DIAGNOSE
→ DECIDE
→ ACT
→ TEST
→ UPDATE

rather than vague instructions such as:

"be strategic"

or:

"think like an expert."


7. ACTIVATION

Create examples of:

- strong trigger prompts
- borderline prompts
- prompts where the Skill must NOT activate


8. GUARDRAILS

Define:

- assumptions the Skill should avoid
- common failure modes
- when it should push back
- when it should ask for clarification
- when it should stop analyzing and act


9. HANDOFFS

Identify whether part of the task should
be handed to another Skill or capability.

For each handoff, state:

- what this Skill owns
- what the other capability owns
- when the transition should occur


10. REFERENCES

Identify knowledge, frameworks, examples,
templates, or documentation that should
live in reference files rather than the
main Skill instructions.


11. TEST PLAN

Create four groups of test prompts:

A. Must activate
B. Should probably activate
C. Must not activate
D. Handoff cases


12. FAILURE TESTING

For each of these failures, explain how
we would detect and fix them:

- activates too often
- fails to activate
- gives overly complicated answers
- dumps frameworks instead of solving the problem
- conflicts with another Skill
- relies on irrelevant reference material


13. FINAL CAPABILITY CONTRACT

Before writing the Skill, produce a compact
summary containing:

SKILL NAME
MISSION
CORE LOOP
STRONG TRIGGERS
NEGATIVE TRIGGERS
GUARDRAILS
HANDOFFS
REFERENCE MATERIAL
TEST PLAN

Stop there and ask me to approve the
capability contract.

Only after I approve it should you create:

- SKILL.md
- recommended references/ files
- scripts/ if genuinely useful
- assets/ if genuinely useful

Keep SKILL.md focused on reusable behavior
and decision procedures.

Do not turn it into an encyclopedia.

Move deep background knowledge into
reference files.

Use the minimum instructions necessary
to make the Skill behave reliably.

The structure is deliberate. Without that constraint, it is easy to begin with:

Create me a marketing Skill. and receive a large instruction file before you have even decided what capability you are trying to create. The better sequence is:

The Skill file comes after the thinking.

17. Build the smallest usable version

The best Skill is not the one with the longest instructions. It is not the one with the most reference files. And it is not the one that tries to sound like an expert at everything. I think a useful Skill needs to do three things reliably:

Recognize the right kind of problem.

Apply the right procedure.

Stay out of the way when it is not needed.

That last one may be just as important as the first two. Because a Skill becomes valuable not only when it knows how to help. It becomes valuable when it has a clear enough boundary to know when it should not interfere. That is the standard I am using for my Systems Strategist Skill.

If you want to try this yourself, start with the worksheet or copy one of the prompts above into ChatGPT. Do not begin by asking:

What Skill should I create?

Start with:

What useful process do I already repeat often enough that it deserves to become reusable?

Define the capability. Build the smallest usable version. Test it against clear matches, ambiguous cases, non-matches, and handoffs. Record what activated, what stayed out of the way, what produced useful output, and what failed. Then adjust the design and test again.

The design gets better when reality pushes back. If you want to see that process applied rather than just described, continue with:

Skills Lab: Building and Testing a ChatGPT Systems Strategist Skill

There I document the before-and-after tests, activation behavior, AI guardrails, handoff boundaries, screenshots, full test conversations, and a more ambiguous scenario where the Skill had to operate end to end.

Sources & updates

Skills are a changing product surface. Treat the design principles in this guide as the durable part. For exact menus, installation routes, and product support, use OpenAI’s current Skills guidance.

• Systems Strategist Lab: firsthand test evidence and limitations.
• OpenAI: Build skills: structure, activation, authoring, and product surfaces.
• OpenAI: Skills & Plugins: guided creation and installation overview.

Reviewed September 13, 2026. The capability contract, worksheet, and prompts are my editorial method, informed by the linked experiment. No new trials were conducted for this guide. Proposed handoffs are not demonstrated automatic orchestration. No affiliate links.