Skills on KnightLi Blog

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.

¿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