TL;DR: Si estás en Codex, usa un command para controlar la sesión o la aplicación, y usa una skill para enseñarle al agente una forma de trabajar. En Claude Code, la documentación actual ya trata las skills como algo invocable con /skill-name, así que ambas ideas se mezclan mucho más. En Codex no: types puede existir como skill y /types seguir sin existir.
Hay una confusión muy habitual cuando saltas de Claude Code a Codex. Y es normal.
Creas una skill llamada types, vuelves a la terminal, escribes /types con toda tu buena fe… y Codex te mira como si le hubieras pedido una caña en una ferretería.
El problema no es que la skill esté rota. El problema es que en Codex un skill y un command no son la misma cosa.
Y ojo, porque esta diferencia no es cosmética. Cambia cómo diseñas tu flujo de trabajo.
La analogía que te lo deja claro
Piensa en Codex como un avión con dos capas.
La primera capa es la cabina: botones, palancas, indicadores. Ahí viven los commands. Sirven para cambiar el estado de la sesión, del cliente o de la herramienta. Son control operativo.
La segunda capa es el manual del copiloto: procedimientos, criterios, listas de comprobación, trampas evitables. Ahí viven las skills. Sirven para cambiar cómo razona el agente cuando hace una tarea.
Traducido para humanos:
- Un command toca la cabina.
- Una skill toca la cabeza del copiloto.
Si intentas usar el manual como si fuese un botón, eso no cuela.
Qué es un command en Codex
En Codex hay dos sabores de command que conviene no mezclar.
El primero son los comandos de CLI:
codex login
codex exec "run tests and fix failures"
codex resume --last
codex apply
Aquí no hay misterio. Son operaciones de la aplicación. Autenticarte, lanzar una tarea, reanudar una sesión, aplicar un diff. Si mañana quitas el modelo del medio, estos comandos siguen teniendo sentido.
El segundo son los slash commands dentro de la sesión interactiva:
/model
/permissions
/personality
/agent
/status
Estos tampoco son «prompts bonitos». Son controles de la sesión viva. Cambian el modelo, los permisos, la personalidad, el hilo activo o el estado visible. Son botones del panel de mando.
OpenAI, de hecho, lo documenta así de claro: por un lado tiene una página específica de slash commands para «controlar Codex durante sesiones interactivas», y por otro una página distinta de skills que define las skills como el formato de autoría para reusable workflows.
Por eso existen como commands y no como skills: porque necesitan comportamiento predecible, inmediato y con semántica estable. No quieres que el modelo «interprete creativamente» qué significa /permissions. Quieres que cambie permisos. Punto.
Qué es una skill en Codex
Una skill en Codex es otra cosa. Es un flujo reusable que le enseña al agente cuándo aplicar un enfoque, cómo pensar una tarea y qué pasos seguir.
Y aquí hay otro matiz fino pero importante: OpenAI dice que el skill es el formato de autoría, mientras que el plugin es la unidad instalable o distribuible. O sea, primero diseñas el workflow como skill; si luego quieres repartirlo o envolverlo mejor, lo empaquetas.
Ejemplos claros:
$types
$improve
$owasp
$blog
O, si prefieres lenguaje natural:
usa types para auditar este repo
usa improve para revisar este diff
Ahí no le estás diciendo a Codex «cambia un ajuste». Le estás diciendo «cuando hagas esta tarea, sigue este playbook».
Mi types, por ejemplo, no debería ser un botón. Tiene que leer el proyecto, detectar el lenguaje, inspeccionar modelos, buscar stringly-typed code, decidir si un Optional está bien usado o si está modelando un estado del dominio. Eso exige contexto y criterio. Es justo el tipo de trabajo que una skill hace bien.
Por la misma razón, improve tiene sentido como skill: no es una acción determinista. Es una manera concreta de hacer code review.
Por qué en Claude Code parece «lo mismo»
Aquí está la trampa mental.
La documentación actual de Claude Code ya no es tímida con esto. Habla de skills y te dice que puedes invocarlas directamente con:
/skill-name
O sea: en Claude Code, una parte importante de lo que tú percibes como «workflow reusable» entra por sintaxis de slash command. La UX junta dos conceptos que en Codex están separados:
- reutilizar un flujo
- invocarlo con
/algo
Además, Claude Code mantiene sus built-in commands aparte:
/help
/compact
Y encima separa otra pieza más: los subagents, que son asistentes especializados con su propio contexto, sus permisos y su system prompt.
Dicho de otra forma:
- En Claude Code, skills, subagents y commands conviven, pero las skills se pueden invocar con
/. - En Codex, los workflows reutilizables viven como skills, y los
/commandsse quedan como control explícito de la sesión.
Por eso, si vienes de Claude, tu cerebro aprende muy rápido una equivalencia práctica: «si algo reusable existe, seguramente lo lanzaré con /algo«. En Codex ese atajo mental deja de funcionar.
Ejemplos concretos: qué debe ser skill y qué no
Cosas que en Codex deberían ser skill
types
Porque no quieres «ejecutar una acción». Quieres aplicar criterio de diseño de tipos sobre un codebase real.
improve
Porque revisar un diff no es una operación mecánica. Hay juicio, contexto y prioridades.
blog
Porque escribir un artículo con tono, estructura y verificaciones antificciones es un flujo de razonamiento, no un botón.
owasp
Porque una auditoría de seguridad necesita adaptar heurísticas al stack, al repo y a los riesgos concretos.
Cosas que en Codex deberían ser command
codex login
No hay nada que razonar. O te autenticas o no te autenticas.
/model
Cambiar de modelo es una operación del cliente. No un criterio de trabajo.
/permissions
Tocar permisos a mitad de sesión es control operativo puro.
codex resume --last
Reabrir una sesión no es un workflow cognitivo. Es una acción de la app.
El caso que más confunde: cosas híbridas
Hay una categoría intermedia que te lía la cabeza al principio: workflows que querrías lanzar con una sintaxis cómoda, pero cuya lógica sigue siendo de skill.
Por ejemplo:
- querrías escribir
/types - pero
typessigue siendo conceptualmente una skill
La solución elegante aquí no es «convertir la skill en otra cosa». La solución es envolverla.
Es decir:
- Mantienes la inteligencia en la skill.
- Creas un plugin o un command que la invoque con ergonomía de
/slash-command.
Así consigues lo mejor de ambos mundos: UX de comando, cerebro de skill.
La regla de oro cuando estás en Codex
Si estás dudando entre command y skill, usa esta prueba:
¿Quieres cambiar el estado de la sesión o de la app?
Entonces necesitas un command.
¿Quieres cambiar la forma en que el agente aborda una tarea?
Entonces necesitas una skill.
En formato tabla, que siempre ayuda:
| Quiero… | En Codex uso… | Ejemplo |
|---|---|---|
| cambiar permisos | command |
/permissions |
| cambiar de modelo | command |
/model |
| reanudar una sesión | command |
codex resume --last |
| aplicar un criterio de auditoría | skill |
$types |
| hacer una review con una metodología concreta | skill |
$improve |
| redactar con una guía editorial | skill |
$blog |
Entonces, ¿cuál deberías usar?
La respuesta corta: en Codex deberías usar skills para conocimiento reusable y commands para control operativo.
Si vienes de Claude Code, tu instinto inicial será convertir cualquier workflow reutilizable en /algo. Es un reflejo comprensible, porque en Claude la propia documentación te anima a pensar así. Pero en Codex ese reflejo te mete en una pared muy pronto.
Primero diseña la skill. Si luego necesitas una entrada más ergonómica, la envuelves en un plugin o en un command. No al revés.
Porque si empiezas por el botón antes de tener claro el procedimiento, acabas con una interfaz muy bonita que no sabe hacer gran cosa. Y de eso ya tenemos demasiadas en esta industria.
Quédate con esta frase y me voy: en Claude Code, una skill puede entrar por la puerta de /slash-command. En Codex, no. Y casi mejor así.
Cuando entiendes la diferencia, dejas de pelearte con /types y empiezas a construir flujos que sí encajan con la herramienta. Algo es algo.
Read this article in English.
