Claude Skills, ChatGPT, Codex & Agent Skills Explained

Four terms are starting to blur into one another. That is creating a bigger architecture problem than the naming suggests.

Claude Skills, ChatGPT Skills, Codex Skills, and Agent Skills are related, but they do not describe four competing versions of the same feature. The confusion starts when teams mix the reusable workflow format with the environment that runs it. One term describes an implementation, another a product surface, and another the open format underneath them.

This article separates those layers. It explains what each term means, what they share, what actually changes across platforms, how portability breaks, and which parts of a Skill an enterprise should keep independent from Claude, ChatGPT, or Codex.

TL;DR  

• The open Skill format defines the portable package, while Claude, ChatGPT, and Codex provide different environments that can use it.

• A Skill can package a repeatable method, including instructions, references, scripts, examples, and supporting resources.

• The runtime changes what the Skill can do, because tools, permissions, files, integrations, networking, and execution capabilities differ by product.

• Portability depends on separation, so the method should stay distinct from platform-specific commands, access, and permissions.

• The useful comparison is not which product has Skills, but which parts of the workflow remain valid when the runtime changes.

What Are Claude Skills, ChatGPT Skills, Codex Skills & Agent Skills?  

The cleanest way to understand the four terms is to separate the format from the environment that executes it.

Term	What It Actually Refers To
Agent Skills	The open format for packaging reusable instructions, scripts, references, assets, and supporting resources.
Claude	Anthropic’s implementation of the Skill model across Claude products and development environments.
ChatGPT	OpenAI’s implementation of reusable workflows inside ChatGPT.
Codex	OpenAI’s Skill implementation in an environment close to repositories, files, tools, and execution.

The Agent Skills specification requires a SKILL.md file and allows optional directories such as scripts/, references/, and assets/. It also defines metadata that helps an agent decide when a Skill applies.

That gives the comparison a clearer starting point:

The specification defines the package. Claude, ChatGPT, and Codex determine how that package runs.

This also prevents another common mix-up. A Skill is not the same thing as an AI agent. It can give an agent reusable operating knowledge, but the surrounding environment still determines which tools, systems, permissions, and actions are available.

What Do These Skill Systems Have in Common?  

All of them solve the same underlying problem: package a repeatable way of working so the AI does not need the process rebuilt in every conversation.

A basic Skill can look like this:

skill-name/
├── SKILL.md
├── scripts/
├── references/
└── assets/

The folder structure matters less than what each layer carries.

• Trigger: Metadata should tell the system what the Skill does and when it should run.

• Process: Instructions should capture the important steps, decision rules, and output expectations.

• Evidence: Reference files can hold policies, schemas, examples, or detailed material.

• Execution: Scripts can handle deterministic work where model judgment adds little value.

• Exceptions: The method should state when the AI needs more information or should return control to a person.

Anthropic’s Skill architecture documentation describes progressive disclosure across its Skill architecture. Claude can start with lightweight metadata, load SKILL.md when the Skill becomes relevant, and read deeper resources only when the task calls for them.

This is also why Claude Code Skills are more than saved prompts. The reusable asset can contain operating knowledge, not just a better instruction.

The same principle applies to the OpenAI implementations. The exact runtime changes, but the useful abstraction stays familiar: keep the repeatable method together and let the environment supply the capabilities needed to execute it.

Teams deciding what is stable enough to package can treat a reusable Skill workflow as the operating unit, instead of spreading the same method across prompts, documents, and individual habits.

Claude Skills vs ChatGPT Skills vs Codex Skills: What Actually Changes?  

The biggest differences sit around the Skill, not necessarily inside the core method.

Area	Claude	ChatGPT	Codex
Runtime	Claude product environment	ChatGPT product environment	Codex environment
Typical context	Claude workflows, Claude Code, and API use	Workspace, files, apps, and knowledge work	Repositories, files, commands, tools, and engineering workflows
Distribution	Varies across Claude surfaces	User and workspace installation or sharing	Varies by Codex surface
Tools and data	Capabilities available to that Claude surface	ChatGPT tools, files, apps, and connected resources	Files, repositories, commands, tools, and integrations
Permissions	Depend on the Claude environment	Depend on user and workspace settings	Depend on the execution environment
Main lock-in risk	Runtime-specific assumptions	Workspace and app assumptions	Repository and execution assumptions

OpenAI describes Skills in ChatGPT as reusable, shareable workflows that can include instructions, examples, code, reusable steps, and scripts. It also notes that Skills can be supported in Codex and that availability, installation, and syncing can differ by product and surface.

That last detail matters because a shared Skill structure does not make the surrounding runtime identical.

Claude Code Skills can sit close to project files and development tools. The same method used through another Claude surface may face a different runtime. The reusable workflow remains recognizable, but its access and execution can change.

OpenAI’s Agents SDK repositories make the Codex side concrete. Skills such as code-change-verification, docs-sync, implementation-strategy, and pr-draft-summary capture repeatable repository workflows. Codex then uses repository context, commands, files, and project instructions to carry them out. OpenAI documents these examples in its Agents SDK Skills workflow.

So “what’s actually different?” has a short answer:

The method can be similar. The runtime, tools, access, permissions, distribution, and execution context are not.

How Portable Are Skills Across Claude, ChatGPT & Codex?  

A common format can make a Skill easier to move, but portability has two different meanings.

Format portability asks whether the package can move to another compatible environment.

Behavioral portability asks whether it will still work the same way after it moves.

Those are not the same test.

Take a product-review method:

1. Gather the required evidence.

2. Apply the review criteria.

3. Flag failures.

4. Escalate defined exceptions.

5. Produce the required output.

That method can travel.

Now add an assumption that a specific shell command exists, a package is pre-installed, files always live at one path, one app is connected, or internet access is available.

The method did not change. The dependency did.

This is one reason the question “how do Claude Skills work?” cannot stop at the contents of SKILL.md. The runtime also determines what the Skill can access and execute.

The same test applies to the ChatGPT and Codex implementations. A workflow tied to a particular app, repository convention, filesystem layout, or permission model may be reusable inside one environment without being portable across products.

A practical portability review should ask:

• Method: Would the operating process still make sense in another runtime?

• Dependencies: Which packages, commands, paths, or product features does the workflow assume?

• Access: Which data sources, apps, files, or systems does it need?

• Authority: Which actions may the AI recommend, change, or execute?

If the runtime can change without forcing a rewrite of the business method, the Skill has a stronger portability boundary.

Where Do Skills, MCP, Apps & APIs Fit?  

Skills and access mechanisms solve different parts of the workflow.

The Skill can carry the method. MCP, apps, or APIs can provide the live access and actions that method needs.

Consider a risk-review workflow.

• Evidence: The Skill specifies which information must be checked.

• Sequence: It defines which checks happen first and which depend on earlier results.

• Exceptions: It identifies conditions that should stop automation or require review.

• Output: It defines what a completed assessment must contain.

The connected layer might supply customer records, transaction history, support data, product information, or permissioned actions.

This is the useful way to interpret Claude Skills vs MCP. It is less a product contest and more a boundary question: which knowledge belongs in the reusable workflow, and which capability belongs in the connection layer?

The same logic applies when comparing the open Skill format with MCP. A portable operating method should not need to change simply because the organization switches the system that supplies its data.

That separation also helps when a Skill becomes part of a broader AI agent architecture. Tools, access, orchestration, observability, and human approval can change without forcing every operating rule into one platform-specific workflow.

What Creates Lock-In Across Skill Platforms?  

Most lock-in does not start with the Skill format. It starts with assumptions that quietly become part of the implementation.

1. Runtime-Specific Commands  

A workflow may expect a particular CLI, package manager, shell, or installed library.

The underlying method can remain valid even when that command does not exist elsewhere.

2. Hard-Coded Paths and Repository Structures  

A Skill can assume that configuration, source files, reference material, or documentation always lives at one path.

That works until the same method runs in another repository or a workspace with a different filesystem model.

3. Vendor-Specific Tool Logic  

A ChatGPT workflow can depend on resources available inside its workspace. A Codex workflow can depend on repository or execution context. The Claude implementation can depend on capabilities available to a particular product surface.

If those mechanics are mixed throughout the method itself, migration means rewriting the process instead of replacing an adapter.

4. Hidden Access Assumptions  

A workflow may assume it can reach the internet, read a connected account, install a package, query a system, or modify a file.

Those assumptions need to be explicit because available capabilities can vary by product surface.

5. Authority Hidden Inside Access  

This is the more consequential form of lock-in.

A system that can read a record should not automatically inherit permission to change it. A workflow that can recommend an action should not automatically gain authority to execute it.

The method should define the decision boundary. The platform should enforce the permitted action.

That distinction becomes especially important when the same Skill moves between environments with different permission models.

For teams making these architecture decisions before implementation, AI Innovation Strategy can help separate the reusable method from platform dependencies, access rules, and product-specific execution.

What Should Enterprise Teams Standardize Across AI Skill Platforms?  

The platform is not the durable asset.

Claude Skills, ChatGPT Skills, Codex Skills, and Agent Skills become more useful when the organization separates its operating method from the product that executes it. The method should remain understandable even if the runtime changes.

Standardize the evidence the workflow needs, the sequence it follows, the criteria it applies, the exceptions it escalates, and the point where human judgment or another control takes over. Keep commands, integrations, permissions, and access mechanisms outside that core wherever possible.

That is the difference between a workflow that is reusable and one that only works inside one tool. If your team is deciding which AI workflows should become reusable infrastructure and which parts should remain platform-specific, start with a working session with ProCreator.

FAQs