Skills as Reusable Workflows

Skills are valuable because repeated work should not require the same conversation every time.

The concept of skills now appears in two distinct places in the OpenAI ecosystem: Skills in ChatGPT (a workspace-level feature for teams) and Codex skills (a developer-facing packaging format). Both share the same principle -- when a workflow repeats, it benefits from being packaged more clearly -- but they serve different audiences and work differently.

The deeper reason skills matter is that they represent a shift from conversational prompting to operational design. A prompt is a one-time instruction. A skill is a reusable procedure. That distinction changes how you think about quality: a prompt only needs to work once, but a skill needs to work reliably across many different instances of the same kind of task. That reliability requirement forces you to think more carefully about what the stable parts of the procedure actually are.

Show a repeated task becoming a reusable package with instructions, references, and tools.

Skills in ChatGPT

OpenAI launched Skills as a workspace-level feature in ChatGPT. Skills let teams turn proven workflows into reusable instructions that ChatGPT applies automatically when relevant.

Key characteristics:

• Workspace-scoped. A skill belongs to the team workspace, not to an individual user.
• Shareable. Once created, skills can be shared across the workspace so the whole team benefits.
• Automatic application. ChatGPT recognizes when a skill is relevant to the current task and applies it without the user needing to invoke it manually.
• Built from proven workflows. The idea is to capture what already works well -- a review checklist, a formatting standard, an analysis procedure -- and make it persistent.

This is useful for teams that find themselves restating the same instructions across different conversations. Instead of re-explaining the process each time, the team packages it once as a skill.

The practical impact is significant for team consistency. Without a skill, each team member interprets the task slightly differently, applies different quality standards, and produces outputs that vary in structure and depth. With a skill, the baseline is shared. Individual judgment still matters, but it operates on top of a consistent foundation rather than from scratch each time.

Codex skills

For developers working with Codex, skills have a more formal structure:

• SKILL.md files. Each skill is defined in a SKILL.md file with structured metadata including name and description.
• Optional supporting directories. Skills can include scripts/, references/, and assets/ directories for supporting materials.
• Progressive disclosure. Codex loads only the skill metadata first, then loads full instructions only when the skill is activated. This keeps context efficient.
• Explicit invocation. Users can invoke a skill directly using the $ prefix (e.g., $review-pr).
• Implicit invocation. Codex also matches tasks to relevant skills automatically when the task description fits.
• Layered customization. Codex skills sit in a hierarchy: AGENTS.md is the foundational per-repo customization layer, skills are the second layer, MCP connections are the third, and multi-agent coordination is the fourth.

AGENTS.md provides the baseline instructions that apply to every task in a repository. Skills build on top of that foundation for specific, repeatable procedures.

The layered model is worth understanding even if you do not use Codex, because the principle applies everywhere: establish a baseline of always-on instructions, then add task-specific procedures on top. That same pattern works for custom GPTs (system instructions as the baseline, conversation prompts as the layer) and for team workflows in ChatGPT (workspace skills as the baseline, individual prompts as the layer).

The core idea

A skill is a packaged workflow, not just a prompt shortcut.

It is most useful when the task repeats, the procedure matters, and the quality improves when the instructions and supporting materials stay stable. That makes skills especially good for review routines, docs workflows, release steps, and other repeated operating procedures.

The distinction between a skill and a saved prompt is worth understanding clearly. A saved prompt is a piece of text you paste into a conversation. A skill is a procedure with context, references, and structure. The saved prompt says "do this." The skill says "here is how this kind of work should be done, here is the supporting material, and here are the boundaries." That difference is what makes skills more reliable for repeated work. They carry the context with them rather than relying on you to reconstruct it each time.

There is also a maintenance question that many users overlook. A skill is not a set-and-forget asset. Procedures evolve, quality standards shift, and tools change. The best skill owners review their skills periodically -- not constantly, but at natural checkpoints like quarterly planning or after a process change. A skill that reflects last year's procedure can be worse than no skill at all because it enforces outdated standards with the authority of a packaged workflow.

Use a skill when you are having the same conversation repeatedly. Avoid creating skills for work that is still too fuzzy or infrequent.

How it works

1. Notice repetition. If the same job requires the same guidance again and again, it may deserve packaging. The signal is not that you did something twice -- it is that you gave the same instructions twice and wished you did not have to.
2. Identify the stable core. Not everything about a repeated workflow is stable. Some parts vary with each instance. The skill should capture the parts that stay the same -- the procedure, the quality criteria, the reference materials -- and leave the variable parts to each conversation.
3. Define the stable workflow. Instructions, references, and tools should map to a real procedure. If you cannot describe the procedure clearly enough to teach it to a new team member, it is not ready to be a skill.
4. Keep the skill narrow enough to stay reliable. A bloated skill is just a complicated prompt in disguise. One skill should handle one kind of task well.
5. Test and revise. Use the skill at least three times before considering it finished. Each use reveals something about whether the instructions are clear enough, whether the references are complete, and whether the boundaries are in the right place. A skill that has not been tested in real use is still a hypothesis.

What skilled users do differently

A less experienced user creates skills eagerly. They see the feature, package a few workflows immediately, and end up with a collection of skills that are too broad, rarely invoked, or quickly outdated. The skill library becomes clutter rather than leverage.

A skilled user waits for the signal. They notice when they are having the same conversation for the third or fourth time. They notice when they keep forgetting to include a particular constraint or reference. They notice when the team keeps asking the same questions about how a procedure should work. Those signals indicate that a workflow has stabilized enough to deserve packaging. The skilled user also keeps skills narrow. Each skill does one thing well. If a skill starts accumulating too many responsibilities, it is split into two smaller skills rather than allowed to grow into a general-purpose instruction dump. This discipline is what keeps the skill library small, reliable, and actually used.

Two worked examples

Example 1: a premature skill

A team notices that they sometimes ask ChatGPT to help draft customer emails. They immediately create a skill called "Customer Email Writer." But the team has no stable process for customer emails -- different team members have different tones, different situations call for different approaches, and the "skill" ends up being a vague instruction to "write professional customer emails." It is invoked rarely because it adds nothing that a reasonable prompt would not already produce.

This fails because the workflow was not yet stable enough to package. The team was still figuring out what good customer emails looked like for their context. The skill was an attempt to shortcut a process that had not yet been established. The fix is not to abandon the skill idea entirely, but to wait until the team has drafted enough emails manually to identify the stable patterns, the consistent quality criteria, and the boundaries of what the skill should and should not do.

Example 2: a well-timed skill

A development team notices that every PR review follows the same pattern: check for consistent error handling, verify that new functions have tests, confirm that the naming conventions match the project's style guide, and flag any TODO comments without linked issues. The reviewer has been restating these criteria in every review. They package the checklist into a Codex skill called $review-pr with references to the project's style guide and testing standards. Now every PR review starts from the same baseline, and the team can focus on the substantive questions rather than the procedural ones.

This works because the procedure was already stable, the criteria were clear, and the supporting references were well-defined. The skill captured something that was already working -- it did not try to create a process from scratch. The team also kept the skill narrow: it handles PR review, not all code quality tasks. That focus is what makes it reliable.

The contrast between these two examples reveals the core timing principle: package what already works, not what you hope will work. The first team tried to create a process through the skill. The second team codified a process that already existed. That distinction is the difference between a skill that gets used and one that gets abandoned.

There is a useful test for readiness: can you write the skill's instructions in under ten minutes? If you can, the procedure is clear enough to package. If you cannot, you are still discovering the procedure, and further manual repetition will help you identify the stable core. The ten-minute test catches premature packaging before it wastes the team's time.

Prompt block

Could this become a skill?

Better prompt block

Evaluate whether this repeated workflow should become a reusable skill.

Workflow:
[describe the repeated task]

Please tell me:
- what repeats here
- what stable instructions or references would help
- whether the workflow is narrow enough to package cleanly
- what should stay outside the skill

Why this works

The better prompt asks whether the workflow is sufficiently repeatable and stable, which is the real question behind skill design. It also asks what should stay outside the skill, which is an underrated question. A skill that tries to capture everything about a workflow usually captures nothing well. The best skills have clear boundaries between what they handle and what they leave to the user's judgment. Making that boundary explicit during design prevents the skill from becoming bloated over time.

The question "whether the workflow is narrow enough to package cleanly" is also doing important work. It forces an honest assessment of scope before packaging begins. Many failed skills were not bad ideas -- they were good ideas with too much scope. By asking this question before building, you catch the problem when it is cheapest to fix: at the design stage rather than after the skill has been built, shared, and discovered to be unreliable.