La respuesta útil no es una lista universal. Si Codex ya resuelve bien tu tarea, no añadas nada; si necesitas repetir un procedimiento, empieza por una Skill; si necesitas distribuir un paquete con Skills o conectar servicios, evalúa un Plugin. Cuando el valor depende de datos o acciones de otro sistema, identifica también el connector (conector) o servidor MCP que hace posible ese acceso.
Esta guía está actualizada a 15 de agosto de 2026. La disponibilidad de un Plugin concreto puede variar según la superficie, la cuenta, el espacio de trabajo, la autenticación y las políticas aplicables. Por eso, el objetivo no es declarar ganadores, sino ayudarte a encontrar la ampliación mínima y comprobar su utilidad antes de depender de ella.
Decide primero qué problema intentas resolver
Empieza con una frase que describa un resultado observable. «Quiero mejorar Codex» es demasiado amplio. «Quiero que, antes de entregar un cambio, ejecute las pruebas relevantes, revise el diff y señale riesgos» ya permite tomar una decisión.
Usa esta tabla como primera criba:
| Tu necesidad | Punto de partida | Motivo | Comprobación imprescindible |
|---|---|---|---|
| Una tarea puntual que Codex ya completa correctamente | Nada adicional | Evitas contexto, mantenimiento y acceso innecesarios | Repite la tarea base con un criterio de éxito definido |
| Un procedimiento reutilizable para un proyecto o tipo de trabajo | Skill | Encapsula instrucciones y recursos para una tarea concreta | Revisa SKILL.md, recursos, scripts y alcance de carga |
| Distribuir varias capacidades como una unidad instalable | Plugin | Puede agrupar Skills y connectors | Confirma los componentes incluidos y la superficie compatible |
| Leer o actuar sobre un servicio externo | Plugin con connector o MCP | La conexión aporta el contexto o la acción que falta | Verifica autenticación, permisos y controles del sistema externo |
La decisión debe hacerse en ese orden. Elegir primero un nombre popular y buscar después qué problema resuelve suele terminar en una pila redundante o con más permisos de los necesarios.
Skill, Plugin y connector no son sinónimos
OpenAI define una Skill como un flujo reutilizable para una tarea específica, compuesto por instrucciones y recursos de apoyo. Su pieza central es SKILL.md; también puede incluir scripts, referencias, recursos y metadatos. Codex puede invocarla de forma explícita o cuando la descripción de la Skill coincide con la petición. Las Skills pueden cargarse desde distintos ámbitos, como el repositorio, el usuario, la administración o el sistema.
Esto hace que una Skill sea una buena candidata cuando el valor está en cómo realizar un trabajo: revisar una migración, preparar una entrega, analizar un tipo de incidente o seguir las convenciones de un repositorio. Una Skill no necesita acceso a un servicio externo para ser útil.
Un Plugin es una unidad instalable que puede contener Skills, connectors o ambos. Sirve para distribuir capacidades relacionadas y puede añadir acceso a herramientas o servicios. Los connectors se apoyan en servidores MCP y pueden incluir una interfaz propia. Por tanto, «Plugin» describe el paquete; «connector» (conector) describe la conexión; y «Skill» describe el flujo reutilizable.
Esta diferencia evita tres errores frecuentes:
- instalar un Plugin completo cuando bastaba con unas instrucciones locales;
- llamar Plugin a cualquier servidor MCP o herramienta auxiliar;
- asumir que una Skill externa es segura o eficaz solo porque su formato es válido.
El formato te dice cómo se integra una capacidad. No demuestra su calidad, mantenimiento ni adecuación a tu tarea.
Cuándo no necesitas instalar nada
La configuración base es un candidato más y debería participar en la comparación. Si Codex puede completar la tarea con una petición clara, los archivos del repositorio y las herramientas ya disponibles, una extensión puede añadir duplicación sin mejorar el resultado.
No instalar nada suele ser la mejor primera opción cuando:
- la tarea ocurre una sola vez;
- el procedimiento cabe en una instrucción breve y estable;
- no necesitas conectarte a otro sistema;
- el resultado base ya supera tu criterio de calidad;
- nadie se hará responsable de mantener la extensión.
Esta ruta no significa renunciar a la automatización. Significa exigir una razón observable antes de añadir otra capa. Si más adelante detectas omisiones repetidas o un proceso estable que merece reutilizarse, ya tendrás evidencia para convertirlo en una Skill.
Cuándo una Skill es la opción mínima
Elige una Skill cuando quieres que Codex siga de manera consistente un procedimiento reconocible. El caso más claro es una regla vinculada al repositorio: comandos de validación, límites de archivos, criterios de revisión o formato de entrega.
Por ejemplo, imagina un equipo que quiere que toda modificación pase por el linter, las pruebas afectadas y una revisión del diff. Una Skill local puede reunir los pasos y las condiciones de parada. Al vivir cerca del proyecto, se puede revisar junto al código y adaptar cuando cambian los comandos.
Antes de adoptar una Skill, inspecciona:
- qué promete su descripción y cuándo se activa;
- el contenido completo de
SKILL.md; - los scripts, referencias y recursos que carga;
- los comandos que propone ejecutar;
- los archivos y datos que podría leer o modificar;
- quién mantiene el contenido, cuándo se actualizó y cómo retirar una versión problemática.
Una Skill instalada para varios proyectos solo compensa cuando el procedimiento común es realmente estable. Si mezcla reglas universales con convenciones de un único repositorio, separa primero ambos niveles. Así evitas que una actualización útil para un proyecto rompa otro.
Cuándo un Plugin aporta valor real
Evalúa un Plugin cuando necesitas distribuir varias capacidades relacionadas o cuando el flujo depende de uno o más servicios conectados. La documentación de OpenAI menciona, entre otros, Codex Security, Gmail, Google Drive y Slack como ejemplos de Plugins. Son ejemplos del catálogo, no una clasificación de calidad ni una promesa de que aparezcan en todas las cuentas.
La superficie importa. A fecha de esta guía, la documentación indica soporte de Plugins en la aplicación de escritorio de ChatGPT y en Codex CLI, pero no en la extensión de Codex para el IDE. Una función puede existir y, aun así, no estar disponible donde planeas trabajar. Comprueba la ficha del Plugin desde la misma superficie y cuenta que usarás.
Un Plugin merece consideración si responde «sí» a estas preguntas:
- ¿agrupa componentes que realmente deben viajar juntos?
- ¿la tarea necesita datos o acciones de un servicio externo?
- ¿la superficie de Codex que utilizas lo admite?
- ¿puedes completar la autenticación requerida?
- ¿los permisos solicitados son proporcionales al resultado?
- ¿hay una alternativa si cambia la disponibilidad?
Si solo aporta una instrucción pequeña, una Skill puede ser más sencilla. Si solo quieres una conexión concreta, identifica el connector o MCP implicado en vez de evaluar el paquete como una caja negra.
El presupuesto de permisos: qué entregas a cambio
La utilidad no puede separarse del acceso. Cuando una capacidad se ejecuta a través de un host de Codex, se aplican el sandbox y la política de aprobaciones de ese host. Los servicios externos conservan además su propia autenticación y sus controles de acceso. Un connector puede requerir configuración o inicio de sesión adicional.
Antes de autorizar, crea un presupuesto explícito:
| Pregunta | Respuesta que debes obtener |
|---|---|
| ¿Qué puede leer? | Repositorios, documentos, mensajes, metadatos o secretos concretos |
| ¿Qué puede cambiar? | Solo lectura, comentarios, commits, envíos o acciones irreversibles |
| ¿Dónde se ejecuta? | Superficie de Codex, sandbox y servicio externo implicado |
| ¿Quién concede acceso? | Usuario, administrador del espacio de trabajo o propietario del sistema |
| ¿Cómo se revoca? | Control para desconectar, retirar credenciales o desinstalar |
| ¿Qué ocurre si falla? | Estado parcial posible, registro disponible y forma de recuperación |
No basta con que el nombre sea conocido. Dos Plugins orientados a la misma tarea pueden requerir alcances muy distintos. El candidato preferible es el que completa el resultado con el menor acceso suficiente y deja una vía clara de revocación.
Una prueba comparable antes de conservar la extensión
Haz una prueba corta con una tarea representativa. La comparación debe usar el mismo repositorio, la misma entrada, el mismo criterio de éxito y un alcance similar.
- Define el resultado. Por ejemplo: identificar la causa de un fallo, proponer un cambio y ejecutar las comprobaciones autorizadas.
- Ejecuta la línea base. Realiza la tarea con Codex y la configuración que ya tienes.
- Añade un solo candidato. Evita instalar una pila completa, porque no sabrás qué componente causó la diferencia.
- Registra el coste. Anota correcciones humanas, pasos extra, permisos utilizados y errores introducidos.
- Repite. Comprueba si otra persona obtiene un resultado semejante bajo las mismas condiciones.
Puedes resumir el ensayo en una ficha:
| Medida | Codex base | Con el candidato |
|---|---|---|
| Resultado requerido completado | Sí / No | Sí / No |
| Correcciones humanas | Número y tipo | Número y tipo |
| Pasos no solicitados | Cuáles | Cuáles |
| Accesos utilizados | Cuáles | Cuáles |
| Resultado repetible | Sí / No / Incierto | Sí / No / Incierto |
Conserva la extensión si mejora un resultado importante de forma repetible y el beneficio justifica su mantenimiento y permisos. Si la diferencia no es clara, vuelve a la configuración más simple. No necesitas demostrar que el candidato es malo; basta con que no haya demostrado valor para tu caso.
Señales para aplazar o descartar un candidato
Detén la instalación o limita la prueba si:
- no puedes identificar qué tipo de componente es;
- la fuente o el responsable de mantenimiento no están claros;
- no existe confirmación para tu superficie de Codex;
- la disponibilidad en tu cuenta sigue siendo desconocida;
- solicita acceso que la tarea no necesita;
- incluye scripts o instrucciones que no has revisado;
- promete mejoras sin una prueba reproducible;
- duplica una capacidad que ya funciona;
- te obliga a diseñar un proceso crítico alrededor de una disponibilidad no confirmada.
La ausencia de evidencia no demuestra que una extensión sea insegura o inútil. Sí impide tratarla como una dependencia fiable. Mantén ese estado como desconocido; si el candidato toca código, credenciales o sistemas externos, amplía la revisión antes de autorizarlo.
La mejor configuración es la que puedes justificar
Antes de terminar, responde cinco preguntas:
- ¿Qué tarea recurrente quiero mejorar y cómo sabré que mejoró?
- ¿Necesito instrucciones, un paquete distribuible o acceso a otro sistema?
- ¿Funciona en mi superficie de Codex y aparece para mi cuenta?
- ¿Entiendo sus componentes, mantenimiento, autenticación y permisos?
- ¿Supera una comparación frente a no instalar nada?
Si necesitas un procedimiento, empieza con una Skill pequeña y revisable. Si necesitas distribuir varias capacidades o conectar servicios, evalúa un Plugin y sus connectors. Si no puedes confirmar superficie, acceso o permisos, no construyas el flujo alrededor del candidato. Y si la prueba no muestra una mejora útil, conserva Codex base.
Los mejores plugins y skills para Codex no forman una lista fija: forman una configuración mínima que resuelve una tarea definida, funciona donde trabajas y justifica cada acceso que añade.
Fuentes y límites
- Skills y Plugins: taxonomía y criterio general de elección.
- Crear Skills: estructura, invocación y ámbitos de carga.
- Plugins: catálogo, componentes, superficies, autenticación y permisos.
Estas fuentes explican el producto, pero no establecen un ranking universal. No se ha inspeccionado tu cuenta, catálogo ni configuración del espacio de trabajo; comprueba allí la disponibilidad de cada candidato. Tampoco se afirma un volumen de búsqueda en España ni que la frase exacta sea de uso habitual.
