In Codex, a Skill Is Not a /Command (but in Claude Code, It Almost Is)

TL;DR: If you’re using Codex, use a command to control the session or application, and use a skill to teach the agent a way of working. In Claude Code, the current documentation already treats skills as something you can invoke with /skill-name, so the concepts merge more there. Not so in Codex: types might exist as a skill, but /types won’t exist by default.

There’s a common confusion when switching from Claude Code to Codex. And it’s understandable.

You create a skill called types, go back to the terminal, type /types all confident… and Codex looks at you like you just walked into a hardware store and ordered a latte.

The problem isn’t that your skill is broken. The problem is that in Codex, a skill and a command are not the same thing.

And here’s the kicker: this distinction is not just cosmetic. It changes how you design your workflows.

A Simple Analogy to Make It Clear

Think of Codex as a plane with two levels.

The first level is the cockpit: buttons, levers, indicators. That’s where commands live. They control the session, the client, or the tool. It’s operational control.

The second level is the copilot’s manual: procedures, guidelines, checklists, avoidable pitfalls. That’s where skills live. They change how the agent thinks when performing a task.

Put simply:

• A command affects the cockpit.
• A skill affects the copilot’s head.

If you try to use the manual as if it were a button, that doesn’t fly.

What Is a Command in Codex?

In Codex, commands come in two flavors that shouldn’t be mixed up.

The first type is CLI commands:

codex login
codex exec "run tests and fix failures"
codex resume --last
codex apply
---

No mystery here. These are application operations. Authenticating, running a task, resuming a session, applying a diff. If you removed the model tomorrow, these commands would still make sense.

The second type is **slash commands in an interactive session**:

```text
/model
/permissions
/personality
/agent
/status

These aren’t “fancy prompts” either. They’re live session controls. They change the model, permissions, personality, active thread, or visible state. They’re cockpit buttons.

OpenAI, in fact, documents it this clearly: there’s one dedicated page for slash commands “to control Codex during interactive sessions,” and another distinct page for skills, defining them as the authoring format for reusable workflows.

That’s why these are commands and not skills: they require predictable, immediate behavior with stable semantics. You don’t want the model to “creatively interpret” what /permissions means. You want it to change permissions. Period.

What Is a Skill in Codex?

A skill in Codex is something else entirely. It’s a reusable workflow that teaches the agent when to apply an approach, how to think about a task, and which steps to follow.

And here’s another fine but important nuance: OpenAI says a skill is the authoring format, whereas the plugin is the installable or distributable unit. In other words, you first design the workflow as a skill; if you want to share or package it later, you wrap it up.

Clear examples:

$types
$improve
$owasp
$blog

Or, if you prefer natural language:

use types to audit this repo
use improve to review this diff

Here, you’re not telling Codex, “Change a setting.” You’re saying, “When you do this task, follow this playbook.”

For example, my types skill shouldn’t be a button. It needs to read the project, detect the language, inspect models, look for stringly-typed code, decide if an Optional is being used correctly or if it’s modeling a domain state. That requires context and judgment. That’s exactly the type of work a skill is designed to handle.

For the same reason, improve makes sense as a skill: reviewing a diff isn’t a deterministic action. It’s a specific way to approach code review.

Why It Feels Like “The Same Thing” in Claude Code

Here’s the mental trap.

The current Claude Code documentation isn’t shy about this. It talks about skills and tells you that you can invoke them directly with:

/skill-name

In Claude Code, a significant part of what you perceive as a “reusable workflow” enters through a slash command syntax. The UX blends two concepts that are separate in Codex:

• Reusing a workflow
• Invoking it with /something

Additionally, Claude Code retains its built-in commands separately:

/help
/compact

And it even separates yet another piece: subagents, which are specialized assistants with their own context, permissions, and system prompt.

In other words:

• In Claude Code, skills, subagents, and commands coexist, but skills can be invoked with /.
• In Codex, reusable workflows live as skills, and /commands are reserved for explicit session control.

That’s why, coming from Claude, your brain quickly learns a practical equivalence: “If something reusable exists, I’ll probably trigger it with /something.” In Codex, this mental shortcut stops working.

Concrete Examples: What Should Be a Skill vs. a Command?

Things That Should Be a Skill in Codex

types

Because you’re not “triggering an action.” You want to apply type design principles on a real codebase.

improve

Because reviewing a diff isn’t a mechanical operation. It involves judgment, context, and priorities.

blog

Because writing an article with tone, structure, and fact-checking is a reasoning flow, not a button.

owasp

Because a security audit needs to adapt heuristics to the stack, repo, and specific risks.

Things That Should Be a Command in Codex

codex login

There’s nothing to reason about. You either authenticate or you don’t.

/model

Switching models is a client operation. Not a work criterion.

/permissions

Tweaking permissions mid-session is pure operational control.

codex resume --last

Reopening a session isn’t cognitive workflow. It’s an app action.

The Trickiest Case: Hybrid Tasks

There’s an intermediate category that can trip you up at first: workflows you’d like to launch with a convenient syntax, but whose logic is still skill-based.

For example:

• You’d like to write /types
• But conceptually, types is still a skill

The elegant solution here isn’t “turn the skill into something else.” The solution is to wrap it.

That means:

1. Keep the intelligence in the skill.
2. Create a plugin or command to invoke it with slash-command ergonomics.

This way, you get the best of both worlds: command UX, skill brains.

The Golden Rule in Codex

When deciding between a command and a skill, use this test:

Do you want to change the session or app state?

Then you need a command.

Do you want to change how the agent approaches a task?

Then you need a skill.

Here’s a handy table:

So, Which Should You Use?

The short answer: in Codex, use skills for reusable knowledge and commands for operational control.

If you’re coming from Claude Code, your first instinct will be to turn every reusable workflow into /something. That’s an understandable habit because Claude’s documentation encourages that thinking. But in Codex, that habit will get you stuck fast.

First, design the skill. If you later need more ergonomic input, wrap it in a plugin or command. Not the other way around.

Because if you start with the button before you’re clear on the procedure, you’ll end up with a pretty interface that doesn’t do much. And we’ve already got too many of those in this industry.

Here’s the takeaway: in Claude Code, a skill can come through the /slash-command door. In Codex, it can’t. And honestly, that’s probably a good thing.

Once you understand this difference, you’ll stop fighting with /types and start building workflows that actually fit the tool. Progress!