Skills on KnightLi Blog

Panorama de herramientas AI PPT populares: cómo elegir entre generación automática, presentaciones web, PPTX e imágenes

Mon, 18 May 2026 22:29:43 +0800

Hacer PPT con IA ya no consiste solo en “escribir un título y aplicar una plantilla”. En entornos de programación con IA como Claude Code, Codex y Cursor, la generación de PPT se está convirtiendo en un conjunto de Agent Skills instalables y reutilizables: algunas generan presentaciones web, otras crean archivos .pptx realmente editables, otras usan modelos de imagen para convertir cada diapositiva en un borrador visual, y otras permiten que la IA opere archivos de PowerPoint mediante MCP.

Aquí organizamos un grupo de Skills populares relacionadas con PPT. Lo valioso no es solo la lista, sino separar estas herramientas por forma de entrega. Antes de elegir una herramienta, conviene hacer una pregunta: quién va a editar el entregable final, dónde se va a presentar y si necesita colaboración posterior.

Varias rutas

1. Presentaciones web HTML

Algunos proyectos representativos son frontend-slides, guizang-ppt-skill y html-ppt-skill.

La ventaja de esta ruta es su capacidad visual. Se pueden usar animaciones CSS, Canvas, WebGL y diseño responsive. Basta abrir el resultado en un navegador para presentarlo, así que encaja con charlas técnicas, lanzamientos de producto, Demo Day y presentaciones con un estilo personal fuerte.

El coste también es claro: después de la entrega no es ideal para clientes que necesitan editar texto punto por punto. Si el cliente recibe HTML en lugar de un archivo de PowerPoint, los cambios posteriores suelen tener que volver al flujo de generación.

Si solo miramos presentaciones HTML, frontend-slides se parece más a una entrada general con muchas estrellas, guizang-ppt-skill destaca por sus restricciones estéticas y estilo temático, y html-ppt-skill sobresale por cantidad de temas, layouts y modo de presentador.

2. PPTX nativo

Algunos proyectos representativos son mckinsey-pptx, ppt-agent-skills, claude-office-skills y ppt-master.

Esta es la ruta más estable para entregas de negocio. Si el cliente pide “poder editar texto, cambiar imágenes y aplicar la plantilla de la empresa en PowerPoint”, el resultado final debe llegar a .pptx.

ppt-master merece una mención aparte. Su idea es pedir primero al LLM que genere SVG y luego convertirlo en objetos DrawingML nativos de PowerPoint. El objetivo es que cuadros de texto, formas y gráficos sigan siendo editables dentro del PPTX. También puede generar PPTX desde PDF, DOCX, URL y Markdown, además de replicar plantillas, añadir animaciones, narración y vista previa local.

Esta ruta encaja con entregas de consultoría, reportes corporativos, presentaciones de white papers y conversión de informes largos en PPT. La desventaja es que el techo visual suele estar limitado por PowerPoint, por lo que los efectos complejos no son tan libres como en HTML o en rutas basadas en imágenes.

3. Flujos impulsados por imágenes de IA

Algunos proyectos representativos son NanoBanana-PPT-Skills, gpt_image_2_skill y ppt-image-first.

Esta ruta trata cada diapositiva primero como una imagen visual, y luego coloca esas imágenes en PPTX u otro contenedor. Su ventaja es un alto nivel de acabado visual, especialmente para portadas, gráficos de redes sociales, propuestas visuales y contenido orientado a difusión.

El problema es la baja editabilidad. La página es, en esencia, una imagen. Si luego hay que cambiar un título, reemplazar un párrafo o mover un icono, quizá haya que regenerarla. Sirve para “que se vea bien”, pero no para “el cliente va a revisarlo muchas veces”.

4. MCP / capa de protocolo

Algunos proyectos representativos son Office-PowerPoint-MCP-Server y PPTAgent.

Estas herramientas no necesariamente generan un PPT completo directamente. Más bien le dan a la IA una interfaz para operar PowerPoint. Tras conectarse con MCP, el modelo puede leer, modificar y escribir archivos .pptx.

Esta ruta encaja con flujos donde ya existe un archivo PPT y se necesita ayuda de IA para modificarlo. Por ejemplo, cambiar formato en lote, reordenar páginas según feedback o pedir al modelo que revise si cada diapositiva cumple el objetivo. PPTAgent enfatiza la generación reflexiva: después de generar cada diapositiva vuelve a revisarla. Esa dirección ayuda a reducir el problema de que “los PPT de IA se ven toscos”.

5. Plataformas de diseño integradas

Algunos proyectos representativos son open-design y docsagent.

Estos proyectos ya van más allá de la generación de PPT. open-design se parece más a una plataforma de diseño local-first: puede generar prototipos, slides, images y videos, y admite varios formatos de exportación. docsagent no es una herramienta de PPT, pero puede indexar documentos locales y conversar con ellos, por lo que sirve como capa de organización de materiales antes de generar PPT.

Si tu necesidad no es hacer un PPT puntual, sino un flujo completo desde materiales, diseño y prototipo hasta entrega, este tipo de plataforma merece más atención.

Metadatos de Skills

Los conteos de Star vienen del resultado capturado el 2026-05-15. Solo sirven como referencia de popularidad. Antes de usarlos en serio, conviene abrir de nuevo los repositorios y confirmar estado de mantenimiento, README y LICENSE.

Skill	Autor	Enlaces	Star	Lenguaje	Ruta
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	Presentación web HTML
guizang-ppt-skill	@op7418 (Guizang)	Artículo interno: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	Presentación web HTML
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	Presentación web HTML
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	PPTX nativo
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	PPTX nativo
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	PPTX nativo
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	PPTX nativo
NanoBanana-PPT-Skills	@op7418 (Guizang)	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	Impulsado por imágenes de IA
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	Impulsado por imágenes de IA
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	Impulsado por imágenes de IA
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / capa de protocolo
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / capa de protocolo
open-design	@nexu-io	Artículo interno: open-design GitHub: nexu-io/open-design	40,822	TypeScript	Plataforma de diseño integrada
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	Plataforma de diseño integrada

Cómo elegir

Si el cliente necesita seguir editando, prioriza la ruta de PPTX nativo, especialmente ppt-master, mckinsey-pptx y ppt-agent-skills.

Si vas a presentar tú mismo y la expresión visual pesa más que la edición posterior, prioriza la ruta HTML, especialmente frontend-slides, guizang-ppt-skill y html-ppt-skill.

Si el objetivo es una pieza con sensación de póster, portada o imagen para difusión, prioriza la ruta de imágenes, como ppt-image-first, gpt_image_2_skill y NanoBanana-PPT-Skills.

Si ya tienes un archivo PPT y solo quieres que la IA te ayude a leerlo, editarlo y reorganizarlo, mira la ruta MCP.

Para escenarios claros como academia, marketing, traducción o compresión de informes largos, también puedes buscar Skills verticales en lugar de forzar un generador generalista de PPT.

Notas finales

No conviene juzgar proyectos open source solo por sus Star. Antes de usarlos de verdad, confirma tres cosas:

Si la LICENSE permite tu forma de uso.
Si el resultado generado cumple los requisitos de entrega, especialmente la editabilidad.
Si el coste es aceptable, incluyendo llamadas a modelos, generación de imágenes, modelos de contexto largo y posibles servicios cloud.

Estas herramientas cambian muy rápido. Los Star cambian y el estado de mantenimiento también. Pero la lógica de selección es relativamente estable: primero define la forma de entrega y luego mira las herramientas concretas. Si un PPT es para presentar, para que otros lo editen o para que otros lo miren, esas tres respuestas suelen reducir mucho el rango de opciones.

24 consejos de Claude Code: modo plan, rewind, CLAUDE.md, Skills, Agents y plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code no es solo una caja de chat. Se parece más a un Agent de programación que puede entrar en un directorio de proyecto, leer y escribir archivos, ejecutar comandos y mantener contexto.

Si solo le das un requisito y esperas código, pronto aparecen problemas: el plan no queda claro, los permisos se repiten, el contexto crece, el resultado no convence, no sabes cómo volver atrás y no hay un lugar estable para reglas del proyecto.

Estos son consejos prácticos para quienes empiezan con Claude Code.

Empieza dentro del directorio del proyecto

Claude Code funciona mejor cuando se inicia dentro del directorio del proyecto, no desde una terminal cualquiera.

Crea una carpeta de proyecto, entra en ella, abre la línea de comandos e inicia Claude Code:

claude

Si al entrar por primera vez pregunta si confías en la carpeta actual, confirma antes de seguir. Así podrá leer archivos, crear archivos y ejecutar operaciones alrededor del proyecto.

Una práctica sencilla es pedirle que cree una web personal de fotógrafo. Es una tarea visual, permite inspeccionar el resultado y sirve para practicar generación de archivos, comandos, rewind y refactorización.

Usa modo plan para aclarar la dirección

Ante tareas complejas, Claude Code puede entrar en modo plan. Su función es discutir requisitos, dividir pasos y pedir aprobación antes de ejecutar.

Tras escribir un plan, suelen aparecer opciones como:

Aprobar el plan y permitir automáticamente herramientas de edición posteriores.
Aprobar el plan, pero pedir confirmación manual para futuras ediciones.
Pausar y seguir discutiendo el plan con Claude Code.

Si la tarea está clara, aprueba y continúa. Si no, pídele que complete el plan: estilo de página, stack técnico, estructura de carpetas, interacciones y criterios de aceptación.

El modo plan reduce retrabajo. Si el Agent empieza directamente, puede crear muchos archivos rápido; si la dirección era incorrecta, luego todo se vuelve más difícil de corregir.

Cambia de modo con Shift + Tab

En Claude Code, Shift + Tab permite cambiar entre modos de trabajo. Se usa a menudo para entrar en modo plan o para cambiar a un modo de aprobación automática de edición.

Hábitos recomendados:

Proyecto nuevo, función nueva o cambio grande: primero modo plan.
Cambio pequeño o arreglo claro: ejecutar directamente.
Borrado, reemplazos masivos o instalación de dependencias: mantener confirmación humana.

En modo plan, Claude Code puede preguntar detalles del proyecto. Usa flechas para elegir opciones y Enter para confirmar. Después de enviar feedback, actualizará el plan.

No abras todos los permisos

Cuando Claude Code ejecuta comandos, edita archivos o inicia programas, puede pedir permisos.

Opciones comunes:

Permitir solo esta vez.
Permitir el mismo tipo de comando en esta sesión.
Rechazar o pausar.

Para abrir una página local, iniciar un servidor de desarrollo o revisar archivos, aprueba según necesidad. Pero no uses durante mucho tiempo un modo de “permitir todo” solo por comodidad.

La aprobación total automática solo tiene sentido en tareas de bajo riesgo, muy claras y con respaldo Git. En el uso diario, conserva confirmación humana para borrar, sobrescribir carpetas, instalar dependencias, usar red, hacer commits o ejecutar scripts.

Ejecuta comandos locales en modo terminal

Claude Code puede entrar en modo de comandos de terminal y ejecutar comandos locales.

Por ejemplo, después de generar una página, puedes abrir un archivo HTML con:

`1`	`start index.html`

start es un comando de Windows para abrir archivos. Es más rápido que buscar el archivo manualmente.

El modo terminal sirve para:

Abrir páginas generadas.
Ver contenido de directorios.
Iniciar servidores locales.
Ejecutar pruebas o builds.

Pero los comandos de alto riesgo siguen requiriendo cuidado: borrado recursivo, mover directorios, sobrescrituras masivas y cambios de entorno.

Usa rewind cuando el resultado se desvía

Si la página o el código que hizo Claude Code no es lo que quieres y cada corrección lo empeora, usa rewind temprano.

Rewind puede devolver conversación o código a un punto anterior. Opciones comunes:

Revertir código y conversación.
Revertir solo conversación.
Revertir solo código.
Comprimir contenido anterior como resumen.
Cancelar.

Cuando la dirección se desvió claramente, conviene volver código y conversación juntos. Así contexto y archivos regresan a un estado más limpio.

Ten en cuenta que el rewind de Claude Code normalmente cubre archivos creados o modificados con herramientas internas. Archivos creados por comandos externos quizá no se reviertan por completo. Para proyectos importantes, usa Git.

Escribe prompts largos en un editor

No metas requisitos complejos en una sola línea.

Si el sistema permite editar un prompt largo en un editor, úsalo, guarda y luego envíalo a Claude Code.

Un prompt largo debería aclarar:

Objetivo.
Stack técnico.
Qué no debe hacerse.
Qué archivos deben conservarse.
Cómo verificar el resultado.
Criterios de aceptación.

Por ejemplo, si quieres refactorizar una página HTML a un stack más moderno, no escribas solo “refactoriza”. Explica estructura por componentes, preservación visual, diseño responsive y pide ejecutar una comprobación de build.

Recupera sesiones después de salir

Si necesitas salir de Claude Code, hazlo normalmente. Luego vuelve al mismo directorio y arranca otra vez:

claude

Si el historial anterior no aparece, usa comandos de historial para ver sesiones recientes y cargar la sesión anterior.

Esto sirve para continuar trabajo interrumpido. Pero no uses el historial como única memoria. Reglas del proyecto, stack, comandos comunes y notas deben estar en archivos del proyecto.

Guarda reglas del proyecto en CLAUDE.md

CLAUDE.md es un archivo de memoria importante para Claude Code. Normalmente está en la raíz del proyecto y registra reglas, stack, estructura de carpetas y restricciones de colaboración.

Puedes inicializarlo con:

/init

CLAUDE.md sirve para registrar:

Objetivos del proyecto.
Stack técnico.
Comandos de inicio, prueba y build.
Estructura de directorios.
Estilo de código.
Acciones prohibidas.
Reglas de commit y despliegue.

En cada conversación, Claude Code puede usar estas reglas como parte del contexto. Piensa en él como un manual del proyecto.

Una prueba sencilla es añadir una regla evidente en CLAUDE.md y luego preguntar algo. Si la respuesta sigue la regla, leyó la memoria del proyecto.

Usa @ para referenciar archivos

En el cuadro de entrada, @ permite seleccionar archivos o Agents y añadirlos al contexto actual.

Sirve para:

Hacer que Claude Code lea un archivo de configuración.
Pedir cambios en una página concreta.
Continuar según CLAUDE.md u otro documento.
Decir explícitamente “mira solo este archivo, no adivines la estructura”.

Comparado con pegar el contenido del archivo, @ es más claro y menos propenso a omisiones.

Revisa y comprime contexto

Tras una conversación larga, el contexto crece. Si se vuelve demasiado largo, el modelo puede ralentizarse o ignorar detalles antiguos.

Usa:

`1`	`/context`

Si el contexto ya es largo, comprime el historial:

`1`	`/compact`

Si aun así el efecto es malo, limpia el contexto actual:

/clear

Después de limpiar, Claude Code todavía puede entender parte del proyecto mediante archivos, CLAUDE.md y el directorio actual, pero no conserva todo el historial de conversación.

Una regla útil: abre una conversación nueva al terminar una tarea, escribe reglas del proyecto en CLAUDE.md, y no acumules discusión temporal para siempre en un solo chat.

Skills: convierte flujos fijos en instrucciones

Skills son instrucciones reutilizables para Claude Code. No son prompts de una sola vez, sino flujos de tarea empaquetados.

Por ejemplo, si generas informes semanales a menudo, crea una Skill de informe semanal con:

Información de entrada necesaria.
Formato de salida.
Tono y estructura.
Qué debe conservarse.
Qué no debe inventarse.

Las Skills suelen contener name, description e instrucciones detalladas. Al instalarlas en el directorio global de Skills, Claude Code puede reconocerlas y cargarlas cuando la tarea encaja.

Candidatos adecuados:

Informes semanales.
Plantillas de revisión de código.
Organización de documentos.
Procesamiento de imágenes por lotes.
Artículos con formato fijo.
Flujos de inicialización de proyectos.

Si copias el mismo prompt muchas veces, conviértelo en Skill.

Agents: delega subtareas a asistentes independientes

Agents no son lo mismo que Skills.

Una Skill es un manual de instrucciones. Un Agent se parece más a un asistente independiente que trabaja fuera de la conversación principal y devuelve resultados.

Su valor está en aislar contexto. Para una revisión de código, puedes crear un Agent de solo lectura que lea el proyecto y entregue un informe sin modificar archivos. Así no contamina la conversación principal y reduce riesgos.

Al crear un Agent, considera:

Si será de proyecto o de usuario.
Si Claude Code debe generar la configuración.
Qué herramientas puede usar.
Qué modelo usará.
Si guardará memoria.
Si el prompt del Agent es claro.

Para Agents de auditoría de código, da solo permisos de lectura. Primero que entregue un informe; luego la conversación principal decide si cambia código.

Plugins: empaqueta Skills, Agents, MCP y Hooks

Los plugins son paquetes de capacidad más completos. Pueden incluir:

Skills
Agents
MCP
Hooks

Frente a una Skill aislada, un plugin sirve mejor para capacidades de conjunto. Un plugin de diseño frontend puede empaquetar estética de página, reglas de layout, hábitos de componentes y Agents relacionados.

Al instalar plugins, suele haber opciones:

Directorio de usuario, efectivo para todos los proyectos.
Directorio de proyecto, compartido con el proyecto.
Directorio local del proyecto, solo efectivo en tu ordenador.

Para capacidades personales frecuentes, usa el directorio de usuario. Para acuerdos de equipo, usa el proyecto. Para pruebas temporales, usa instalación local.

Los plugins mejoran tareas concretas

En generación de páginas frontend, un plugin suele ser más estable que un prompt desnudo.

Por ejemplo, para “crear una web personal de fotógrafo”, un prompt normal puede crear una página aceptable. Si usas explícitamente un plugin de diseño frontend, la estructura, jerarquía visual, espaciado, color y acabado suelen mejorar.

Esto no reemplaza el criterio humano. Lo razonable es dejar que el plugin genere un primer borrador mejor y luego ajustar detalles manualmente.

Un flujo de trabajo más estable

Combinando todo lo anterior, queda un flujo más estable:

Inicia claude dentro del directorio del proyecto.
Discute requisitos primero en modo plan.
Confirma stack y criterios de aceptación antes de aprobar.
Mantén confirmación manual para acciones de alto riesgo.
Usa modo terminal para previsualización y pruebas.
Usa rewind cuando el resultado se desvíe.
Escribe reglas en CLAUDE.md.
Revisa y comprime contexto en conversaciones largas.
Convierte flujos repetidos en Skills.
Delega inspección, investigación y análisis a Agents de solo lectura.
Usa plugins para tareas de dominio específico.
Mantén puntos de commit Git en proyectos importantes.

Así Claude Code será mucho más estable que enviar una frase y esperar generación.

Resumen

La eficiencia de Claude Code no viene solo del modelo, sino también del control del flujo.

El modo plan define la dirección, los permisos controlan el riesgo, rewind reduce retrabajo, CLAUDE.md guarda reglas del proyecto, /context, /compact y /clear gestionan contexto, Skills reutilizan flujos, Agents aíslan subtareas y plugins empaquetan capacidades completas.

La mejor forma de usar Claude Code es dejar que avance dentro de límites claros, no entregarle todo el proyecto de una vez.

Awesome Codex Skills: un catalogo comunitario para ampliar Codex CLI

Thu, 07 May 2026 20:19:15 +0800

awesome-codex-skills, de ComposioHQ, es un catalogo comunitario de skills para Codex CLI. Su valor no esta en ser otra pila de plantillas de prompts, sino en ofrecer una forma de empaquetar flujos repetibles como Skills instalables, reutilizables y mantenibles.

Si ya usas Codex como parte del desarrollo diario, este tipo de repositorio resulta util de inmediato: reglas, comandos, materiales de referencia y pasos operativos que antes tenias que explicar una y otra vez pueden escribirse una vez y reutilizarse cada vez que se invoque la Skill correspondiente.

Que resuelve este repositorio

Las Codex Skills pueden entenderse como modos de trabajo especializados para Codex CLI. Un prompt normal sirve bien para una instruccion temporal; una Skill encaja mejor con algo que quieres reutilizar durante mucho tiempo.

Por ejemplo, puede que a menudo necesites:

generar mensajes de commit con un formato fijo;
consultar una familia especifica de documentacion de API;
ejecutar comandos de pruebas y despliegue propios de un proyecto;
reescribir articulos, traducir documentos u organizar notas segun reglas del equipo;
llamar herramientas externas para tareas de desarrollo repetitivas.

Escribir estas instrucciones cada vez se convierte rapidamente en sobrecarga. Una Skill coloca las reglas en un directorio independiente. El nucleo suele ser un archivo SKILL.md, a veces acompanado de scripts, plantillas, documentos de referencia o assets. Cuando Codex se activa, lee las instrucciones y sigue el flujo descrito alli.

En que se diferencia de un prompt

Un prompt se parece mas a una instruccion puntual: “haz esta tarea de esta forma”. Una Skill se parece mas a un pequeno manual operativo: “cuando aparezca esta clase de tarea, trabaja de esta manera”.

Sus principales ventajas son:

Reutilizable: los flujos comunes ya no necesitan preparacion por copy-and-paste.
Revisable: los archivos de skill suelen ser Markdown locales que pueden abrirse, editarse y versionarse.
Extensible: las skills complejas pueden incluir scripts, plantillas y referencias, no solo instrucciones en lenguaje natural.

Por eso catalogos como awesome-codex-skills son utiles: ayudan a descubrir skills existentes y luego adaptarlas a tu propio flujo de trabajo.

Instalacion y uso

El repositorio ofrece un script de instalacion y tambien soporta instalacion manual. Un flujo tipico es:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

Si solo quieres probar algunas skills, lee primero el SKILL.md de cada directorio. Revisa que lee, que scripts puede ejecutar, que archivos puede editar y si los valores por defecto encajan con tu entorno local.

Despues de instalar, Codex puede detectar skills cuando la tarea las necesita, o puedes nombrar una skill de forma explicita. Para uso a largo plazo, el enfoque mas practico suele ser instalar primero una skill comunitaria y despues reescribir sus instrucciones alrededor de las convenciones de tu proyecto.

Que skills merece la pena observar

Las skills mas valiosas no son necesariamente las que tienen los nombres mas llamativos. Son las que eliminan trabajo repetido de forma fiable.

Yo miraria primero:

Skills de flujo de desarrollo: review, pruebas, commits, releases, comprobacion de dependencias.
Skills de documentacion: reescritura, traduccion, resumen, organizacion estructurada.
Skills de integracion de herramientas: conectar Codex con servicios externos, APIs y herramientas CLI.
Skills de convenciones de proyecto: codificar reglas del equipo, estructura de directorios, convenciones de nombres y pasos de despliegue.

Si una skill solo envuelve un prompt de una frase, su valor es limitado. Si puede conectar investigacion, juicio, ejecucion, verificacion y salida en un flujo estable, merece conservarse.

Puntos de cuidado

Las skills comunitarias son comodas, pero no deberian tratarse como cajas negras. Esto es especialmente cierto para Skills que incluyen scripts. Antes de instalar una, revisa:

que le pide SKILL.md a Codex;
si incluye scripts que acceden a la red, leen o escriben archivos, o llaman servicios externos;
si las rutas, comandos y permisos por defecto encajan con tu maquina.

Una Skill amplia lo que Codex puede hacer. Bien escrita, hace que Codex se sienta mas como un companero que conoce tu proyecto. Escrita con descuido, puede traer reglas inadecuadas a tu flujo de trabajo. El mejor patron no es instalar muchas skills, sino mantener un conjunto pequeno, ajustarlas con cuidado y conservarlas con el tiempo.

Mi lectura

awesome-codex-skills merece guardarse en favoritos, especialmente si ya usas Codex CLI para desarrollo real, documentacion o automatizacion. No es una capacidad oficial por si misma; es un punto de entrada comunitario para encontrar y adaptar flujos reutilizables.

Para usuarios intensivos, el punto de Codex Skills no es simplemente ayudar a la IA a recordar mas. Es ayudar a la IA a dar menos rodeos en tareas repetidas. Escribir reglas como Skills convierte instrucciones temporales en infraestructura de trabajo reutilizable.

CC Switch: una herramienta de escritorio para gestionar Claude Code, Codex, Gemini CLI y OpenClaw en un solo lugar

Wed, 06 May 2026 09:03:08 +0800

CC Switch es una herramienta de gestión de escritorio para usuarios intensivos de programación con IA. El problema que intenta resolver es directo: muchas personas ahora usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw al mismo tiempo, pero cada herramienta tiene su propio formato de configuración, sintaxis de Provider, configuración MCP y forma de gestionar Skills.

Cuando solo usas una herramienta, editar archivos de configuración manualmente todavía es tolerable. Una vez que se mezclan varias herramientas, además de cuentas oficiales, APIs de terceros, servicios relay, modelos locales y configuración compartida de equipo, editar JSON, TOML y archivos .env a mano se vuelve tedioso rápidamente.

CC Switch se posiciona como una forma de reunir estas configuraciones dispersas en una sola app de escritorio multiplataforma.

Qué problema resuelve

Las herramientas modernas de programación con IA se sienten cada vez más como “colegas de desarrollo dentro de la línea de comandos”, pero sus ecosistemas aún no están completamente unificados.

Los puntos de dolor comunes incluyen:

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw usan formatos de configuración distintos.
Cambiar API Providers requiere editar repetidamente archivos de configuración.
Los servidores MCP se configuran una y otra vez en distintas herramientas.
Archivos de prompt como CLAUDE.md, AGENTS.md y GEMINI.md son difíciles de mantener de forma consistente.
Instalación, sincronización, respaldo y eliminación de Skills carecen de una entrada central.
Cambiar entre múltiples cuentas, relays y servicios de modelos puede volverse confuso fácilmente.
Cuando un archivo de configuración editado a mano se rompe, depurarlo cuesta tiempo.

La idea detrás de CC Switch es dejar de obligar a los usuarios a recordar los detalles de configuración de cada herramienta, y usar una interfaz unificada para gestionar Providers, MCP, Prompts, Skills, Sessions y proxies.

Herramientas soportadas

El README enumera cinco objetivos principales soportados:

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

Estas herramientas son similares en posicionamiento: todas se centran en programación con IA, flujos Agent y colaboración por línea de comandos. Pero sus sistemas de configuración difieren, y el valor de CC Switch está en envolver esas diferencias.

Para quienes comparan con frecuencia distintas herramientas de programación con IA, esto es mucho más fácil que abrir manualmente archivos de configuración cada vez.

Gestión de Providers

La primera capa de CC Switch es la gestión de Providers.

Incluye más de 50 presets de Provider. El README menciona direcciones como AWS Bedrock, NVIDIA NIM y varios relays comunitarios. Los usuarios pueden copiar una API key, importarla con un clic y luego cambiar desde la interfaz.

Los puntos prácticos incluyen:

Añadir Providers con un clic.
Reordenar Providers arrastrando.
Cambiar rápidamente desde la bandeja del sistema.
Importar y exportar Providers.
Sincronizar algunos Providers comunes entre varias apps.

Para muchas personas, esta función por sí sola ya es atractiva. En el trabajo diario de programación con IA, el problema muchas veces no es “no sé usar el modelo”, sino “qué herramienta, endpoint y cuenta debería usar hoy esta key”.

Proxy local y failover

Además de escribir archivos de configuración, CC Switch también proporciona un modo de proxy local.

El foco de esta capacidad es:

Cambio en caliente de Providers.
Conversión de formatos.
Failover automático.
Circuit breakers.
Health checks de Providers.
Corrección de solicitudes.

En términos simples, no solo escribe configuración en herramientas objetivo. También puede añadir una capa de proxy local en el medio, para que distintas herramientas accedan a servicios de modelos mediante el proxy.

Esto es útil para usuarios con múltiples Providers: si un servicio cae, cambiar a otro; si un modelo es caro, pasar a uno más barato; si el formato de solicitud es incompatible, adaptarlo mediante la capa de proxy.

MCP, Prompts y Skills

La segunda capa importante de CC Switch es la gestión unificada de MCP, Prompts y Skills.

MCP

Proporciona un panel MCP unificado para gestionar servidores MCP entre varias apps, con soporte para sincronización bidireccional e importación mediante Deep Link.

Esto es práctico para usuarios que ya trabajan con MCP. Cuando hay muchos servidores MCP, la configuración se dispersa fácilmente entre distintos clientes. Un panel unificado reduce la configuración duplicada y facilita la migración.

Prompts

La sección Prompts soporta edición Markdown y puede sincronizar archivos correspondientes entre distintas herramientas, como:

CLAUDE.md
AGENTS.md
GEMINI.md

Estos archivos son esencialmente manuales de proyecto para Agents. La gestión unificada facilita mantener reglas de equipo, convenciones de proyecto y prompts globales.

Skills

Las Skills pueden instalarse con un clic desde repositorios GitHub o archivos ZIP. También se soportan gestión de repositorios personalizados, enlaces simbólicos y copia de archivos.

Si usas herramientas como Claude Code, Codex y OpenClaw al mismo tiempo, las Skills pueden convertirse fácilmente en archivos dispersos por distintos directorios. CC Switch las centraliza y reduce el costo de mantenimiento.

Sesiones y workspace

El README también menciona funciones de Session Manager y Workspace.

Puede explorar, buscar y restaurar historial de sesiones de varias apps. Para personas que usan herramientas de programación con IA durante mucho tiempo, la gestión de sesiones es realmente importante: muchos contextos valiosos, rastros de depuración y comparaciones de soluciones quedan enterrados en conversaciones antiguas.

También proporciona un editor de Workspace para OpenClaw, permitiendo editar archivos de agente como AGENTS.md y SOUL.md con vista previa Markdown.

Esto muestra que CC Switch no es solo una pequeña utilidad para “cambiar keys”. Se está expandiendo hacia una estación de trabajo para AI Agent.

Sincronización en la nube y almacenamiento de datos

CC Switch soporta sincronizar datos de Providers mediante Dropbox, OneDrive, iCloud, NAS o WebDAV.

El almacenamiento local de datos también está claramente definido:

Base de datos: ~/.cc-switch/cc-switch.db
Configuración local: ~/.cc-switch/settings.json
Copias automáticas: ~/.cc-switch/backups/
Skills: ~/.cc-switch/skills/
Copias de Skills: ~/.cc-switch/skill-backups/

Usa SQLite como fuente principal de datos y enfatiza escrituras atómicas y copias automáticas, con el objetivo de evitar corrupción de archivos de configuración durante cambios o escrituras.

Este diseño importa para usuarios intensivos. Si la herramienta de gestión de configuración escribe una mala configuración, todas las herramientas de programación con IA pueden verse afectadas.

Instalación

CC Switch es una app de escritorio multiplataforma construida sobre Tauri 2.

Los requisitos aproximados del sistema son:

Windows: Windows 10 o posterior
macOS: macOS 12 Monterey o posterior
Linux: Ubuntu 22.04+, Debian 11+, Fedora 34+ y otras distribuciones principales

Los usuarios de Windows pueden descargar el instalador .msi o un paquete comprimido portable.

Los usuarios de macOS pueden instalarlo con Homebrew:

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

Para actualizar:

`1`	`brew upgrade --cask cc-switch`

Los usuarios de Linux pueden elegir .deb, .rpm o AppImage. Los usuarios de Arch Linux también pueden instalarlo con paru -S cc-switch-bin.

Al 6 de mayo de 2026, la página del repositorio muestra la última release como CC Switch v3.14.1, publicada el 23 de abril de 2026.

Stack técnico

Por la estructura del repositorio, CC Switch es una app de escritorio Tauri típica:

Frontend: React 18, TypeScript, Vite, TailwindCSS, TanStack Query, shadcn/ui
Backend: Tauri 2, Rust, SQLite, Tokio
Testing: Vitest, MSW, Testing Library

Los patrones de diseño principales incluyen:

SQLite como Single Source of Truth.
JSON para configuración local a nivel de dispositivo.
Escritura en la configuración viva de herramientas objetivo durante el cambio.
Rellenar ediciones del Provider actual desde la configuración viva.
Escrituras atómicas usando archivos temporales más rename.
Conexiones de base de datos bloqueadas para evitar problemas de escritura concurrente.

Esta arquitectura sugiere que el proyecto no es un script simple, sino una herramienta de escritorio diseñada para uso de largo plazo.

Para quién es

CC Switch encaja con estos usuarios:

Personas que usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw juntas.
Personas que cambian con frecuencia entre cuentas oficiales, relays de terceros, modelos locales o Providers de equipo.
Usuarios que ya usan MCP intensivamente.
Equipos que quieren mantener CLAUDE.md, AGENTS.md y GEMINI.md en un solo lugar.
Usuarios que instalan, prueban y migran Skills con frecuencia.
Personas que quieren ver historial de sesiones y uso entre distintas herramientas.

Si solo usas una herramienta de programación con IA, dependes del login oficial y rara vez tocas Providers, MCP o Skills, su valor puede no ser evidente.

Pero si ya entraste en un estado de “muchas herramientas, muchas cuentas, muchos Providers, muchos proyectos”, puede eliminar mucho trabajo repetitivo de configuración.

Qué vigilar

Herramientas como esta son cómodas, pero también necesitan límites claros.

Primero, gestiona configuración para múltiples AI CLIs, así que los usuarios deben asegurarse de confiar en la herramienta y su lógica de escritura.

Segundo, API keys, endpoints relay y servidores MCP son configuración sensible. Antes de activar sincronización en la nube, asegúrate de que la carpeta de sincronización y el servicio WebDAV sean seguros y confiables.

Tercero, después de cambiar Providers, la mayoría de herramientas todavía necesitan reiniciar la terminal o CLI para que los cambios surtan efecto. El README menciona que Claude Code soporta cambio en caliente de datos de Provider, pero otras herramientas normalmente aún requieren reinicio.

Cuarto, al volver al login oficial, es mejor añadir el provider oficial según las instrucciones del proyecto y luego volver a ejecutar el flujo de login de la herramienta correspondiente.

Resumen

El valor de CC Switch no está en crear otra herramienta de programación con IA. Su valor está en reconocer una realidad: el ecosistema de AI coding entró en una etapa donde coexisten múltiples herramientas.

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw tienen cada una sus propios sistemas de configuración, mientras MCP, Skills, Prompts y Providers se expanden rápidamente. Seguir editando archivos de configuración a mano terminará convirtiéndose en una carga.

CC Switch reúne estas piezas en una app de escritorio, facilitando cambiar Providers, sincronizar MCP, gestionar Skills, mantener archivos de prompt y ver sesiones. Para usuarios intensivos de programación con IA, herramientas como esta pueden pasar de “utilidad opcional” a “infraestructura diaria”.

Referencias

farion1231/cc-switch

Guía inicial de Codex App: instalación, sandbox, tareas paralelas, Skills y MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App puede entenderse como un espacio de trabajo de tareas para programación con IA. No es un IDE tradicional ni solo una ventana de chat. Reúne multitarea, gestión de proyectos, permisos de sandbox, Git, ejecución en la nube, plugins, Skills, MCP y automatización en una sola interfaz.

Si ya usas Codex CLI, Claude Code, Cursor u otros coding agents, la parte más interesante de Codex App es que convierte “ejecutar varios agentes en paralelo” en un flujo de escritorio más claro.

Para qué sirve Codex App

El valor central de Codex App no es responder preguntas, sino permitir que la IA ejecute tareas de forma continua dentro de un directorio de proyecto:

Editar código, ejecutar comandos e iniciar servidores de desarrollo.
Gestionar múltiples proyectos y múltiples tareas.
Ejecutar tareas largas localmente o en la nube.
Llamar plugins, Skills y MCP para ampliar capacidades.
Gestionar cambios mediante Git, worktree y flujos PR.

OpenAI también posiciona Codex App como una interfaz para gestionar múltiples coding agents. Es adecuada para personas que necesitan avanzar varias tareas de programación a la vez, especialmente páginas frontend, scripts, apps pequeñas, documentación y flujos de automatización.

Preparación antes de instalar

Antes de usar Codex App, conviene preparar tres herramientas básicas:

Git
Node.js
VS Code o tu IDE preferido

Codex App soporta macOS y Windows. Después de instalar, inicia sesión con tu cuenta de ChatGPT. En el primer lanzamiento, puedes elegir tu escenario principal de uso, como programación o trabajo diario. Codex precargará algunos plugins y Skills según tus elecciones, y luego puedes ajustarlos en configuración y en el marketplace de plugins.

Las funciones principales en Windows y macOS son bastante parecidas, pero algunas capacidades de automatización del ordenador pueden depender de la plataforma y del soporte de plugins. Usa lo que tu versión actual muestre realmente.

Estructura de interfaz: proyectos, tareas y chats

Codex App usa un diseño clásico de tres columnas:

Izquierda: proyectos, tareas, historial de chats, plugins y entradas de automatización.
Centro: ventana de chat actual.
Derecha: archivos, navegador, terminal, resultados de ejecución y otros paneles.

Un proyecto normalmente corresponde a una carpeta local. Puedes abrir varios chats dentro del mismo proyecto, o abrir varios proyectos a la vez para que distintos agentes trabajen en paralelo.

La lista de tareas muestra distintos estados:

Running: el agente sigue ejecutando.
Waiting for approval: debes confirmar permisos, red, instalación de dependencias o una acción de alto riesgo.
Completed: la tarea terminó, y puedes inspeccionar el resultado o seguir preguntando.

Esto es más intuitivo que cambiar entre varias ventanas de terminal, y se adapta mejor a gestionar varias tareas de IA a la vez.

Sandbox y control de permisos

El sistema de permisos de Codex App se construye alrededor del sandbox. Por defecto, la carpeta actual del proyecto se convierte en el workspace principal del agente.

Los límites de permisos comunes incluyen:

Puede leer y modificar archivos dentro del directorio del proyecto.
Por defecto no puede modificar libremente archivos fuera del proyecto.
La red o comandos de alto riesgo están restringidos por defecto.
Cuando necesita acceso elevado, pide aprobación al usuario.

Un modo práctico es “auto review”: las acciones de bajo riesgo se permiten automáticamente, mientras que las acciones de alto riesgo siguen siendo confirmadas por el usuario. Esto reduce ventanas emergentes frecuentes y evita que operaciones peligrosas ocurran en silencio.

“Full access” debe habilitarse con cautela. Es adecuado cuando sabes exactamente qué necesita hacer el agente, el proyecto ya tiene respaldos Git y los archivos importantes tienen copias separadas. No se recomienda como valor diario permanente.

Contexto, modelos y cuotas

Codex App muestra el uso de contexto del chat actual. Cuanto más larga es la conversación y más historial contiene, más contexto necesita procesar el modelo.

Hábitos útiles:

Empezar un chat nuevo después de terminar una tarea.
Los chats largos pueden comprimirse manualmente, pero no trates la compresión como memoria perfecta.
Para tareas complejas, declara claramente objetivos, límites y criterios de aceptación.
No pegues de golpe logs, errores o archivos grandes e irrelevantes en un chat.

Para selección de modelos, ajusta la fuerza de razonamiento según la complejidad de la tarea. Ediciones simples, escritura y tareas repetitivas no siempre necesitan el modelo más fuerte. Migraciones de arquitectura, bugs difíciles y refactors entre archivos encajan mejor con modelos más potentes.

Si la interfaz tiene un modo rápido, recuerda que normalmente consume más cuota. Úsalo cuando la velocidad importe, pero no como valor diario predeterminado.

Generación de imágenes y entradas multimodales

Codex App puede aceptar imágenes y archivos como contexto, y puede llamar generación de imágenes en escenarios adecuados.

Esto es útil para proyectos frontend y de contenido. Por ejemplo, puedes pedir a Codex:

Corregir estilos de página según capturas.
Reemplazar imágenes inadecuadas en una web.
Generar imágenes de producto, imágenes de carrusel o assets de página.
Señalar qué debe cambiarse a partir de una captura de UI.

Un enfoque más eficiente no es decir solo “hazlo más bonito”, sino usar capturas y señalar problemas concretos, como “el espacio en esta tarjeta es demasiado grande”, “esta imagen no coincide con la escena del servicio” o “haz más clara el área del mapa”.

Steer: corregir dirección durante la ejecución

Steer puede entenderse como tomar control de la dirección durante la ejecución. Si el agente ya empezó pero notas que entendió mal, no siempre conviene esperar a que termine para corregirlo.

Puedes usar steering para insertar una nueva instrucción en el flujo de ejecución actual y hacer que Codex corrija el rumbo.

Buenos casos de uso para Steer incluyen:

El agente entendió mal el requisito.
El estilo de página generado es claramente incorrecto.
El plan actual es demasiado costoso o pesado.
Necesitas añadir una restricción clave temporalmente.

En general, mantén el comportamiento predeterminado en cola y usa Steer manualmente solo cuando se necesite intervención. Esto evita interrumpir tareas normales y aun así permite recuperar la dirección en momentos clave.

Modo plan y navegador integrado

Para tareas complejas, empieza con modo plan. En modo plan, Codex no modifica código de inmediato. Primero produce un plan y puede hacer preguntas clave con tarjetas.

Tareas adecuadas para modo plan incluyen:

Migración de frameworks, como pasar un proyecto React a Next.js.
Refactors grandes.
Funciones que involucran bases de datos, autenticación o despliegue.
Requisitos donde aún no has decidido la ruta técnica.

El panel derecho de Codex App puede abrir un navegador integrado para previsualizar el servidor local de desarrollo. Puedes anotar la página y dejar que Codex modifique una ubicación específica de UI. Este flujo de “mirar la página, hacer clic en la posición y pedir a la IA que la cambie” suele ser mejor para depuración frontend que descripciones puramente textuales.

Git, IDE y rollback de código

Codex App no es un IDE completo. Puede ver código y añadir anotaciones, pero la edición manual sigue siendo mejor en VS Code, Cursor, Windsurf u otro IDE.

Todo proyecto de Codex debería inicializar Git temprano:

Pedir a Codex que cree o revise .gitignore.
Hacer un commit al llegar a un estado usable.
Asegurar un punto de commit limpio antes de cada cambio grande.
Volver atrás con Git si no estás satisfecho.

Si haces rollback solo del historial de chat, el código no vuelve automáticamente. Un enfoque más seguro es devolver el chat al punto correcto y luego usar un hash de commit Git para devolver el código al estado correspondiente.

Worktree: desarrollo paralelo en varias direcciones

git worktree es especialmente adecuado para agentes paralelos en Codex App.

Crea varios directorios de trabajo independientes desde el mismo repositorio, cada uno correspondiente a una rama distinta. Esto permite que diferentes agentes trabajen en distintas carpetas al mismo tiempo sin sobrescribirse.

Uso típico:

Un worktree optimiza el componente de reseñas de clientes.
Un worktree ajusta información de tienda y diseño del mapa.
Fusionar ambas tareas de vuelta a main tras completarlas.
Eliminar worktrees temporales después de fusionar.

Esto es mucho más seguro que dejar que varios agentes modifiquen código en el mismo directorio. Si hay conflictos, revísalos y fusiónalos con flujos Git normales.

Entorno de ejecución en la nube

Codex puede trabajar no solo en tu máquina local, sino también en un entorno de nube.

La ejecución en la nube es adecuada cuando:

Estás fuera y solo tienes un teléfono.
Quieres que los agentes ejecuten tareas largas en segundo plano.
El código ya se sincronizó con GitHub y Codex necesita modificar el repositorio remoto.
Quieres revisar y fusionar cambios mediante PRs.

Un flujo típico es: subir el código local a GitHub, dejar que Codex descargue el repositorio en un entorno de nube, ejecutar la tarea, generar cambios y presentarlos como PR o diff para revisión.

Al continuar el desarrollo local, recuerda traer los últimos cambios remotos.

Sistema de memoria: escribe un buen AGENTS.md

Los chats nuevos no tienen memoria histórica completa por defecto. Una vez que un proyecto se vuelve complejo, explicar el contexto repetidamente es ineficiente.

La solución más general es mantener AGENTS.md en la raíz del proyecto. Este archivo puede registrar:

Objetivos del proyecto y stack principal.
Comandos comunes.
Estructura de directorios.
Estilo de código y convenciones de nombres.
Acciones prohibidas, como borrar archivos en masa.
Reglas de pruebas, build y despliegue.

También puedes pedir a Codex que lea el proyecto y genere una primera versión de AGENTS.md, luego revisarla manualmente. Para proyectos complejos, vale la pena mantener este archivo.

Las reglas globales deben usarse con cuidado. Son adecuadas para restricciones universales de seguridad, como “no borrar directorios recursivamente” o “confirmar antes de operaciones destructivas”. No pongas detalles específicos del proyecto en reglas globales, o contaminarán otros proyectos.

Plugins y automatizaciones

Los plugins conectan Codex con servicios externos como GitHub, Gmail, Google Drive, bases de datos y plataformas de despliegue.

Su valor está en reducir copiar y pegar. Por ejemplo, Codex puede:

Revisar tendencias de estrellas de un repositorio GitHub.
Resumir contenido de email y enviártelo.
Ejecutar una revisión recurrente.
Escribir el resultado como resumen.

Las automatizaciones son adecuadas para tareas repetidas. Por ejemplo, revisar datos de un repositorio todos los viernes por la tarde y enviar un informe por email. Las tareas simples de automatización normalmente no requieren el modelo más fuerte; basta un modelo más ligero.

Skills: convertir flujos de trabajo en capacidades reutilizables

Las Skills son “manuales profesionales” para Codex. No son prompts de una sola vez. Empaquetan un flujo de tarea, reglas, scripts y notas para que Codex pueda reutilizarlos de forma fiable después.

Fuentes comunes incluyen:

Skills oficiales.
Skills de terceros.
Skills escritas por ti.

Buenos candidatos para Skills incluyen:

Convertir subtítulos en notas ilustradas.
Escribir informes semanales con formato de empresa.
Procesar imágenes o documentos por lotes.
Revisiones de código con formato fijo.
Inicialización de proyectos para un framework concreto.

Si has copiado y pegado el mismo prompt muchas veces, vale la pena convertirlo en una Skill.

MCP: conectar herramientas externas y bases de datos

MCP puede entenderse como un protocolo estandarizado de herramientas para modelos grandes. Mediante MCP, Codex puede llamar servicios externos para completar tareas más concretas.

Por ejemplo, después de conectar Supabase, Codex puede:

Crear tablas de base de datos.
Leer esquemas de base de datos.
Modificar endpoints backend.
Enviar formularios frontend a la base de datos.
Depurar problemas según el estado de la base de datos.

Esto es poderoso, pero los permisos importan. Bases de datos, entornos de producción, plataformas de despliegue y cuentas de email son recursos de alto riesgo. Al conectarlos por primera vez, usa un proyecto de prueba y una cuenta con pocos privilegios.

Plugins de despliegue

Los plugins de plataformas de despliegue pueden permitir que Codex complete builds y releases directamente, como desplegar un proyecto frontend en Netlify.

Estos plugins son adecuados para sitios pequeños, prototipos, herramientas internas y demos. En uso real, presta atención a:

Ejecutar un build local antes del despliegue.
No escribir variables de entorno directamente en el código.
Comprobar que la página abre normalmente después de publicar.
Mantener revisión humana para proyectos de producción.

La IA puede ayudar a conectar el flujo de despliegue, pero los permisos de despliegue deben gestionarse con cuidado.

Automatización del ordenador

Con plataformas y entornos de plugins soportados, Codex también puede operar navegadores o apps de escritorio, completando tareas más cercanas a RPA.

Ejemplos:

Abrir una app de chat y preparar un mensaje.
Navegar un tablero de proyecto y resumir estado de tareas.
Generar un brief en inglés.
Enviarlo a un destinatario especificado después de tu confirmación.
Convertir el flujo en una automatización programada.

Estas capacidades son imaginativas, pero requieren los límites de seguridad más fuertes. Cualquier operación que implique enviar mensajes, enviar email, enviar formularios, pagos o eliminar datos debe conservar confirmación humana.

Sugerencias de uso

La forma correcta de usar Codex App no es dejarle tomar todo de golpe, sino dividir tareas y permitir que ejecute eficientemente en un entorno controlado.

Hábitos recomendados:

Inicializar Git en cada proyecto.
Usar modo plan para tareas complejas.
Usar worktree para tareas paralelas.
Poner reglas de proyecto en AGENTS.md.
Mantener confirmación humana para acciones de alto riesgo.
Convertir flujos repetidos en Skills o automatizaciones.
Validar plugins y MCP primero en un entorno de prueba.

Referencias

Resumen

Codex App no es “otra ventana de chat con IA”. Su foco es convertir la programación con IA en un espacio de trabajo gestionable, donde proyectos locales, tareas en la nube, Git, worktree, plugins, Skills, MCP y automatización puedan conectarse.

La clave para usarla bien es equilibrar libertad y control. Las tareas pequeñas pueden entregarse a Codex con confianza. Las tareas complejas deben empezar con un plan. Las acciones de alto riesgo deben confirmarse. Usada así, Codex puede convertirse no solo en un asistente que escribe código, sino en una herramienta de ingeniería de largo plazo.

mattpocock/skills: una colecci贸n pr谩ctica de habilidades para agentes de codificaci贸n con IA

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills es una colección pública de habilidades de agentes de codificación IA de Matt Pocock.

No es una aplicación completa ni un nuevo cliente de chat. Es un conjunto de habilidades funcionales que pueden ser utilizadas por asistentes de codificación IA. La idea es práctica: desglosar problemas comunes de codificación de IA en pequeñas habilidades que un Agent puede llamar en la tarea adecuada, en lugar de depender de un solo prompt enorme cada vez.

Si a menudo utilizas Claude Code, Codex, Cursor o herramientas de codificación IA similares, vale la pena observar este tipo de colección de habilidades. Lo que realmente afecta la experiencia de codificación con IA a menudo no es si el modelo puede escribir código, sino si puede avanzar en la tarea según tu estilo de trabajo preferido.

false

Qué Problema Resuelve

Los asistentes de codificación de IA son potentes, pero pueden cometer errores fácilmente.

Las situaciones comunes incluyen:

Comenzar cambios de código sin entender el requisito
Modificar demasiados archivos a la vez
Producir mucha explicación pero poca acción útil
Intentar cosas a ciegas después de errores
No ejecutar pruebas o verificaciones a tiempo
Ignorar patrones de proyecto existentes
Introducir abstracciones innecesarias para terminar una tarea
Escribir código sin revisar realmente los riesgos después

Estos problemas no siempre son causados por una débil capacidad del modelo. A menudo, el flujo de trabajo no está lo suficientemente restringido.

El valor de mattpocock/skills es que transforma estos modos de fallo comunes en métodos operativos reutilizables, haciendo que el Agent se comporte más como un colaborador de ingeniería experimentado en diferentes escenarios.

false

¿Qué son los Skills

En el contexto de AI Agent, un skill se puede entender como una instrucción de tarea reutilizable, un método de trabajo o un flujo de trabajo profesional.

No tiene por qué ser un código plugin, y no siempre necesita llamar a un servicio externo. En muchos casos, un skill es simplemente un conjunto claro de reglas:

Cuándo usarlo
Qué hacer primero
Qué no hacer
Qué salida se requiere
Cómo juzgar la finalización de la tarea

Esto es algo parecido a una normal prompt template, pero la granularidad está más cerca de una capacidad de tarea.

Las normal prompt templates suelen copiarse y pegarse manualmente por el usuario. Los skills son mejores como parte de una toolbox de agente, lo que permite al Agent elegir el flujo de trabajo correcto para la tarea.

false

Por qué es importante la pequeñez y la componibilidad

El README enfatiza que estas habilidades son pequeñas y componibles.

Esta dirección es importante.

Si una habilidad intenta manejarlo todo, rápidamente se convierte en un nuevo prompt gigante: largo, vago y difícil de mantener. La ventaja de las habilidades pequeñas son los límites claros.

Por ejemplo, una habilidad puede centrarse en:

Planificar primero
Arreglar errores de TypeScript
Ejecutar pruebas y corregir basándose en los resultados
Realizar revisión de código (code review)
Resumir convenciones del proyecto
Mejorar prompts
Eliminar abstracciones innecesarias

Estas habilidades se pueden combinar según la tarea. Una tarea simple puede necesitar solo una habilidad, mientras que una tarea compleja puede encadenar varias.

Esto se acerca más al trabajo de ingeniería real. No utilizas el mismo flujo de trabajo (workflow) para cada problema; eliges las herramientas según la situación.

false

Manteniendo al Ingeniero en Control

Una dirección importante de este repositorio es mantener al ingeniero en control.

La codificación con IA puede derivarse fácilmente en dos extremos.

El primero es completamente manual. La IA solo ayuda a escribir unas pocas líneas de código, mientras que todo el contexto, la planificación y la verificación todavía dependen de ti.

El segundo es completamente automatizado (hands-off). Tú envías una tarea a un Agent, lo dejas cambiar muchas cosas, y luego te enfrentas a un diff que es difícil de revisar.

Las habilidades ayudan a encontrar una posición intermedia más estable.

Permiten que la IA asuma más flujo de trabajo repetitivo, mientras la sigue limitando con reglas:

Entender la tarea antes de actuar
Leer los archivos relevantes antes de editar
Mantener el alcance de la modificación controlado
Informar sobre la incertidumbre
Verificar después de los cambios
No refactorizar código no relacionado solo para demostrar

Esto no debilita a la IA. Hace que las acciones de la IA sean más fáciles de revisar y asumir para los humanos.

false

Problemas de Alineación

El primer tipo de fallo de codificación de IA suele ser un fallo de alineación.

El usuario quiere un cambio muy específico, pero el Agent puede entenderlo como una refactorización más amplia. El usuario solo quiere que se arregle un bug, pero cambia estilos en el proceso. El usuario quiere que se siga la arquitectura existente, pero introduce un patrón nuevo.

Las habilidades pueden ayudar al Agent a hacer varias cosas al comienzo de una tarea:

Restatear el objetivo
Identificar el alcance del impacto
Reconocer los patrones de implementación existentes
Proporcionar un plan
Aclarar lo que no se hará

Este paso es como una autocomprobación del ingeniero antes de comenzar el trabajo.

Si el Agent no puede declarar claramente los límites de la tarea y comienza a escribir código directamente, es fácil que la tarea se desvíe.

false

Problemas del Bucle de Retroalimentación

La IA no debe escribir código únicamente mediante la generación one-shot.

En el desarrollo real, los bucles de retroalimentación son importantes:

Cambiar una pequeña parte
Ejecutar pruebas o type checks
Leer los errores
Corregirlos
Verificar de nuevo

Muchos Agents fallan porque omiten la retroalimentación intermedia. Cambian muchas cosas a la vez y luego resumen por intuición que “it should work”.

Las Skills pueden hacer explícito el bucle de retroalimentación. Por ejemplo, pueden exigir al Agent que:

Ejecute comprobaciones relevantes después de la modificación
Lea los mensajes de error primero si las comprobaciones fallan
Evite cambiar ciegamente archivos no relacionados
Verifique de nuevo después de cada ronda de correcciones
Informe los resultados finales de la verificación

Esto hace que la codificación con IA se parezca más al depurado (debugging) real y menos a la escritura one-shot.

false

Problemas de Control de Arquitectura

AI es bueno generando abstracciones, y también bueno sobregenerando abstracciones.

Para completar un requisito pequeño, puede crear una capa de servicio (service layer), funciones auxiliares (helper functions), objetos de configuración, type wrappers y adaptadores, haciendo que el código sea mucho más complejo que el requisito en sí.

Esto es especialmente peligroso en proyectos grandes. Las abstracciones generadas por AI a menudo parecen profesionales, pero pueden no coincidir con el estilo del proyecto existente y pueden aumentar el costo de mantenimiento.

Las buenas habilidades recuerdan al Agent que:

Preferir patrones existentes
Evitar nuevas abstracciones innecesarias
Evitar la refactorización de áreas no relacionadas
Ajustar el cambio al tamaño de la tarea
Comprender el código antes de diseñar la estructura

Esto reduce la producción que parece ingenierizada pero que en realidad es más difícil de mantener.

false

Por qué son importantes las habilidades de revisión

Escribir código y revisar código son estados diferentes.

Cuando un Agent escribe código, generalmente tiende a demostrar que su implementación funciona. Puede explicar por qué el cambio debería funcionar, pero no siempre busca activamente riesgos.

El propósito de una habilidad de revisión es cambiar el rol del Agent:

Encontrar posibles errores (bugs)
Encontrar regresiones de comportamiento
Encontrar pruebas faltantes
Encontrar casos límite (edge cases)
Encontrar mayor complejidad
Encontrar inconsistencias con las convenciones existentes

Esto es importante para la programación con IA porque la IA genera código rápidamente. Sin revisión, los usuarios pueden sentirse fácilmente abrumados por grandes diffs.

Una buena salida de revisión debe listar los problemas primero, no alabar la implementación primero. Debe ayudar al ingeniero a decidir si el cambio se puede fusionar (merged).

false

Diferencia con los archivos de reglas normales

Muchas herramientas de codificación de IA admiten reglas, instrucciones o memoria.

Estos archivos generalmente registran reglas a largo plazo, como:

Stack tecnológico del proyecto
Convenciones de nomenclatura
Comandos de prueba
Directorios que no deben modificarse
Preferencias de estilo de respuesta

Las habilidades (Skills) se centran más en el flujo de trabajo de la tarea.

Las reglas le dicen al Agent “cómo comportarse a largo plazo”, mientras que las habilidades le dicen al Agent “cómo ejecutar este tipo de tarea”.

Ambos funcionan mejor juntos.

Por ejemplo, las reglas pueden indicar que el proyecto usa pnpm test, mientras que una habilidad de revisión requiere verificar la cobertura de pruebas después de los cambios. Entonces el Agent sabe no solo el comando, sino también cuándo usarlo.

false

Escenarios Adecuados

Los repositorios como mattpocock/skills son adecuados para:

Uso frecuente de AI coding tools
Agents que trabajan en codebases reales
Reducir ediciones de AI fuera de alcance
Hacer que el Agent verifique los resultados de forma más activa
Convertir tus hábitos de ingeniería en skills
Aprender cómo otros diseñan workflows de agentes
Convertir prompts temporales en una colección de skills mantenible

Si solo pides ocasionalmente a AI que escriba una función pequeña, quizás no necesites mantener skills.

Pero si ya tratas a AI como un socio de desarrollo a largo plazo, las skills se vuelven cada vez más importantes. Son como un método de trabajo reutilizable para el Agent.

false

Cómo aprender de este repositorio

Incluso si no utilizas cada habilidad directamente, puedes aprender varias cosas de este repositorio.

Primero, anota los modos de fallo.

No solo te quejes cuando la AI comete un error. Convierte los patrones que a menudo se equivoca en reglas, para que una habilidad pueda evitarlos la próxima vez.

Segundo, mantén las habilidades cortas.

Una habilidad debe resolver un problema claro. Cuanto más corta sea, más fácil será llamarla correctamente y mantenerla.

Tercero, haz que el formato de salida sea claro.

Si quieres que el Agent enumere un plan primero, ejecute después y resuma los resultados de verificación al final, escribe esa estructura claramente. Los requisitos vagos suelen producir resultados vagos.

Cuarto, conserva puntos de traspaso humano.

Una buena habilidad no debe permitir que la AI funcione sola durante demasiado tiempo. Cuando haya incertidumbre, un alcance de impacto expandido, pruebas fallidas o una decisión de producto, debe detenerse y explicar la situación.

false

Notas de uso

Primero, no conviertas todo en habilidades (skills).

Demasiadas habilidades hacen que el sistema sea complejo, y el Agent podría no saber cuál elegir. Empieza con los escenarios más frecuentes y más problemáticos.

Segundo, las habilidades necesitan iteración.

La primera versión de una habilidad puede no ser buena. Observa cómo la IA la ejecuta realmente, luego elimina, añade y reescribe gradualmente.

Tercero, no permitas que las habilidades reemplacen el juicio de la ingeniería.

Las habilidades pueden mejorar el flujo de trabajo, pero no pueden garantizar una implementación correcta. Las pruebas (tests), la revisión, las comprobaciones de compilación (build checks) y el juicio humano siguen siendo importantes.

Cuarto, presta atención a las diferencias entre los Agents.

Claude Code, Codex, Cursor y Copilot soportan las instrucciones, las habilidades y las reglas de manera diferente. La misma idea se puede reutilizar, pero el formato específico debe ajustarse para cada herramienta.

false

Referencia

mattpocock/skills

false

Pensamiento Final

Lo que hace que mattpocock/skills merezca la pena es no un único prompt mágico dentro de él, sino la idea práctica de codificación con IA que demuestra: dividir la experiencia de ingeniería en pequeñas habilidades y luego permitir que el Agent las combine según el escenario.

A medida que la codificación con IA pasa de ser una asistencia ocasional a formar parte del flujo de trabajo diario, las habilidades se convierten en herramientas importantes para limitar a los Agents, mantener a los ingenieros en control y mejorar la calidad de la retroalimentación. false

¿Por qué existe una habilidad del Codex en el directorio pero aún no aparece?

Wed, 29 Apr 2026 11:18:00 +0800

Este problema era fácil de pasar por alto: varias habilidades ya estaban ubicadas en ~/.codex/skills, pero después de abrir un nuevo hilo del Codex, la barra lateral todavía mostraba solo un pequeño subconjunto de ellas.

Al principio, parecía un problema de caché o de indexación. La causa real fue más específica: varios archivos SKILL.md comenzaron con una lista de materiales UTF-8. El cargador de habilidades de Codex 0.111.0 no omitió esa secuencia de bytes, por lo que calculó erróneamente que los archivos no tenían contenido YAML válido.

Síntoma

El directorio local contenía estas habilidades:

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

Pero después de abrir un hilo nuevo, las habilidades realmente expuestas fueron solo:

1
2

bilibili-speech-transcriber
product-cutout-normalize

En otras palabras, un archivo existente en el disco no significa que la sesión actual pueda cargarlo correctamente. Codex analiza primero la portada de cada SKILL.md. Si el análisis falla, esa habilidad se excluye directamente.

Investigación

Iniciar una nueva sesión con codex exec mostró un error más directo. En VS Code u otros IDE, es posible que estos registros no sean visibles:

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

Visualmente, estos archivos parecían tener un encabezado normal:

---
name: post-rewrite
description: ...
---

El verdadero problema estaba en el nivel de bytes.

El comienzo de un archivo fallido fue:

`1`	`EF-BB-BF-2D-2D-2D`

El comienzo de un archivo que se cargó correctamente fue:

`1`	`2D-2D-2D`

2D-2D-2D es ---. El EF-BB-BF anterior es la lista de materiales UTF-8.

Causa

En Codex 0.111.0, el cargador de habilidades espera que el primer byte de SKILL.md sea el primer - en ---.

Si el archivo comienza con una lista de materiales UTF-8, el comienzo real será:

`1`	`BOM + ---`

Entonces, el cargador piensa que el archivo no comienza con el delimitador inicial e informa:

`1`	`missing YAML frontmatter delimited by ---`

El contenido de la habilidad no era incorrecto y el directorio tampoco era incorrecto. Un pequeño detalle de codificación impidió que el analizador reconociera el archivo.

Arreglar

Convierta los archivos SKILL.md afectados a UTF-8 sin BOM.

En PowerShell, esto se puede hacer así:

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

Después del procesamiento, el encabezado del archivo debería cambiar de:

`1`	`EF-BB-BF-2D-2D-2D`

`1`	`2D-2D-2D`

Verificación

Después de reiniciar una sesión del Codex, las habilidades visibles se restauraron en:

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

Si la barra lateral todavía muestra la lista anterior, cierre la barra lateral o ventana actual del Codex y vuelva a abrir el proyecto. La lista de habilidades generalmente se carga cuando comienza la sesión, por lo que es posible que los cambios realizados en mitad de una sesión no se actualicen inmediatamente.

Una última línea

Este tipo de problema es fácil de confundir con “El Codex no se volvió a indexar” o “la habilidad no se instaló correctamente”.

Al solucionar problemas, verifique primero estas tres cosas:

si SKILL.md está realmente en el directorio correcto
si el archivo tiene un texto inicial --- válido en la parte superior
si el archivo es UTF-8 sin BOM

La clave en este caso fue el tercer punto: el archivo se veía bien, pero su primer byte no era “-”, por lo que Codex no lo trató como una habilidad válida.

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

Wed, 29 Apr 2026 11:08:00 +0800

Al organizar las habilidades del Codex, la gente suele quedarse estancada en dos preguntas:

¿Cuál es la diferencia entre ~/.codex/skills y project/.codex/skills?
¿Por qué existe una habilidad en el directorio pero no aparece en la sesión actual?

Aquí está la versión corta.

La diferencia

La forma más sencilla de recordarlo:

~/.codex/skills es tu biblioteca de habilidades global
project/.codex/skills es la biblioteca de habilidades local para ese repositorio

`~/.codex/skills`

Úselo para:

Habilidades que reutilizas personalmente en todos los proyectos.
flujos de trabajo generales que no están vinculados a un repositorio específico
flujos de trabajo que claramente pertenecen a sus propios hábitos

Por ejemplo:

post-reescritura
post-traducir -git-commit-push -hugo-rsync-deploy
bilibili-transcriptor-de-voz

El rasgo clave de este tipo de habilidad es: todavía tiene sentido fuera del proyecto actual.

`proyecto/.codex/skills`

Úselo para:

flujos de trabajo que solo se aplican a este repositorio
reglas estrechamente acopladas a la estructura, scripts o plantillas del proyecto actual
Habilidades que deben ser compartidas por el equipo.

Por ejemplo:

un flujo de trabajo de publicación específico para este repositorio
una plantilla de generación que solo funciona en este proyecto
pasos de automatización estrechamente vinculados a scripts de proyectos privados

El rasgo clave de este tipo de habilidad es: deja de ser significativo una vez que sale de este repositorio.

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

Esta regla general es suficiente:

Si se trata de tus hábitos personales, ponlo en ~/.codex/skills
Si se trata de reglas del repositorio, colóquelo en project/.codex/skills
Si se puede reutilizar en todos los proyectos, prefiera global
Si debe ser compartido por varias personas y evolucionar con el repositorio, prefiera el nivel de proyecto

El repositorio actual

Basado en el estado actual:

su máquina tiene ~/.codex/skills
este repositorio no tiene .codex/skills

Así que ahora mismo dependes principalmente de las habilidades globales.

Eso significa que flujos de trabajo como “post-reescritura”, “post-traducción” y “git-commit-push” son actualmente más bien parte de su flujo de trabajo personal, no algo incluido explícitamente con este repositorio.

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Hay dos cosas diferentes aquí:

Existente en el disco: el archivo de habilidad existe en un directorio local
Expuesto a la sesión: la sesión actual lo registró en la lista de habilidades disponibles

Estos no son lo mismo.

Entonces esto puede suceder:

ya existe una habilidad en ~/.codex/skills
pero no aparece en la lista después de /

Por lo general, esto no significa que la habilidad esté rota. Más a menudo significa: la sesión actual no la ha vuelto a indexar.

Cómo hacer que una habilidad esté disponible en la sesión actual

La lista de verificación práctica es breve.

1. Colóquelo en el directorio correcto

Mundiales:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Nivel de proyecto:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Haga que el encabezado `SKILL.md` sea reconocible

Como mínimo, necesita:

---
name: your-skill-name
description: What this skill does
---

3. Abra una nueva sesión después de crearla o editarla

En muchos casos, una habilidad no aparece porque la sesión actual ya fijó su lista de habilidades disponibles cuando comenzó.

Entonces, si crea una habilidad en medio de una sesión, es posible que ya exista en el disco, pero es posible que esta sesión no la reconozca.

El flujo de trabajo más confiable es:

Ponga en práctica la habilidad
Finalizar la sesión actual
Vuelva a ingresar al proyecto.
Abre una nueva sesión
Compruebe si aparece debajo de /

4. Implemente las habilidades para el proyecto antes de comenzar

Si desea que project/.codex/skills se reconozca de manera más confiable, coloque esas habilidades en el proyecto antes de ingresar al repositorio e iniciar la sesión.

Una última línea

La conclusión más corta es:

~/.codex/skills es tu biblioteca de habilidades personales
project/.codex/skills es la biblioteca de reglas local del repositorio
una habilidad existente en el directorio no significa que la sesión actual siempre la mostrará
la solución más común es colocarlo en el directorio correcto, escribir un SKILL.md válido y luego iniciar una nueva sesión