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:
text
$types
$improve
$owasp
$blog
Or, if you prefer natural language:
text
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:
text
/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:
text
/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:
| I want to... | Use in Codex... | Example |
|----------------------------------|-----------------|---------------------|
| change permissions | `command` | `/permissions` |
| switch models | `command` | `/model` |
| resume a session | `command` | `codex resume --last` |
| apply an auditing criterion | `skill` | `$types` |
| review a diff with a methodology | `skill` | `$improve` |
| draft with an editorial guide | `skill` | `$blog` |
## 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!
Top comments (0)