Los repos que están subiendo, y qué hacer con ellos

Para usar con Claude Code o Codex un repositorio de GitHub que acaba de entrar en tendencias, el camino corto casi siempre es el mismo: mira si el repo trae una skill (un archivo SKILL.md), instálala con npx skills add usuario/repo, y pídele al agente que la use. Si no trae skill, apunta al agente al README y deja que sea él quien lea las instrucciones e instale. Lo que sigue es cómo hacer eso sin llevarte un disgusto.

Llevo meses viendo el mismo ciclo. Alguien publica un hilo con un repo que tiene 30.000 estrellas, se llena de respuestas de "brutal", y a la semana nadie lo usa. No es que el repo fuera malo: es que entre "esto es increíble" y "esto está funcionando en mi máquina" hay un trecho que casi nadie cuenta. Esta guía es ese trecho.

Lo que cambia cuando el que instala es el agente

Hasta hace poco, probar un repo era leerte el README, pelearte con las dependencias y rendirte a la mitad. Con un agente de código delante, el cuello de botella se ha movido: instalar ya no es el problema, decidir qué merece la pena sí.

Y hay un cambio de fondo que conviene entender. Muchos de los repos que hoy suben en GitHub no son programas que tú ejecutas: son instrucciones escritas para que las lea tu agente. Un archivo de texto que le enseña a Claude Code a diseñar mejor, o a revisar código, o a manejar un Excel. Eso es una skill. No tiene interfaz, no tiene botones, y si lo abres esperando una aplicación te parecerá que no hay nada. El valor está en el texto.

Por eso la pregunta "¿para qué sirve este repo?" se responde distinto ahora. No es qué hace el programa, es qué deja de hacer mal tu agente cuando lo tiene instalado.

Skills, plugins y MCP: qué es cada cosa

Los tres términos se mezclan constantemente y no son lo mismo:

Formato	Qué es	Cómo lo notas
Skill	Un SKILL.md con instrucciones que el agente carga cuando hace falta	El agente cambia de comportamiento en una tarea concreta
Plugin	Un paquete gestionado que instalas y se actualiza solo	Aparecen comandos nuevos (/algo) en tu sesión
MCP	Un servidor que da al agente acceso a datos o herramientas externas	El agente puede consultar cosas que antes no veía

La diferencia práctica: una skill le enseña a hacer algo, un MCP le da acceso a algo. Un repo como una skill de diseño te cambia cómo escribe el CSS; un MCP de analítica le deja leer tus datos. Muchos repos buenos traen las dos cosas.

Y una distinción que importa más de lo que parece: instalar como plugin significa que te suscribes a los cambios del autor, y se actualiza cuando él publica. Instalar copiando los archivos significa que son tuyos y puedes editarlos, pero nada se actualiza solo. Los repos que traen las dos vías suelen avisar de que no instales ambas, porque acabas con cada skill duplicada.

Dónde van los archivos en cada agente

Esta es la tabla que más veces vas a necesitar. Los repos que siguen el estándar abierto de Agent Skills usan las mismas rutas:

Agente	Ruta personal	Ruta por proyecto
Claude Code	~/.claude/skills/<nombre>/	.claude/skills/<nombre>/
Codex	~/.codex/skills/<nombre>/	.codex/skills/<nombre>/
GitHub Copilot CLI	~/.copilot/skills/<nombre>/	—
Amp y multiagente	~/.agents/skills/<nombre>/	—
Cursor	—	.cursor/rules/<nombre>.mdc

Cursor es el raro: no lee SKILL.md, quiere el cuerpo del archivo pegado en un .mdc y sin el frontmatter de arriba.

La regla que yo sigo: personal para lo que uso en todo (diseño, revisión de código, estilo de escritura) y por proyecto para lo que solo aplica a ese repo (las convenciones de un cliente, el esquema de una base de datos). Si lo metes todo en la ruta personal, acabas con un agente que arrastra veinte skills en cada sesión y se distrae.

El método en cuatro pasos

Lo que hago con cada repo que me interesa, en orden. Tarda diez minutos y me ha ahorrado bastantes tardes.

1. Lee la ficha antes que el README. Mira licencia, fecha del último commit y número de issues abiertas. Un repo con 40.000 estrellas y el último commit hace cinco meses es un repo muerto con buena prensa. Y sin licencia clara (o con una que no sea MIT o Apache) no lo metas en nada de trabajo.

2. Que lo lea el agente, no tú. Esto es lo que más tiempo ahorra. En Claude Code o en Codex:

Lee https://github.com/usuario/repo y dime en cinco líneas qué hace,
qué necesita instalado para funcionar y qué me va a pedir que le dé
(claves de API, permisos, dinero). Sé escéptico: si el README promete
cosas que el código no respalda, dímelo.

Esa última frase importa. Sin ella el agente te resume el marketing del README.

3. Instala en un sitio del que puedas salir. Para skills, la vía corta es el instalador multiagente:

npx skills add usuario/repo

Te pregunta qué skills quieres y para qué agentes. Si el repo no usa ese formato, clona en una carpeta aparte y prueba ahí, nunca directamente sobre un proyecto que te importe.

4. Verifica con una tarea de la que sepas el resultado. No estrenes una herramienta con trabajo real. Dale algo cuyo resultado ya conozcas y compara. Es la única forma de distinguir "funciona" de "parece que funciona".

El riesgo del que casi nadie habla

Cuando le dices a un agente "instala esto", le estás dando permiso para ejecutar código escrito por un desconocido, con tus permisos y en tu máquina. Y muchos READMEs te invitan directamente a hacer esto:

curl -fsSL https://ejemplo.com/install.sh | bash

Eso descarga un script y lo ejecuta sin que lo hayas leído. En un repo serio y con muchos ojos encima, el riesgo es bajo. En un repo que subió a tendencias anteayer, no lo es tanto: las estrellas no son una auditoría de seguridad, y hay extensiones dedicadas precisamente a detectar estrellas compradas.

Tres cosas que sí valen la pena:

• Quita el | bash y mira el script antes de ejecutarlo. Son treinta segundos.
• Desconfía de cualquier repo que pida claves de API por un camino raro, o que quiera acceso a tu correo, tu nube o tu gestor de contraseñas "para funcionar mejor".
• Una skill es texto, y el texto también puede darle instrucciones a tu agente. Ábrela y léela. Si un SKILL.md incluye órdenes que no tienen nada que ver con lo que el repo dice hacer, ahí tienes tu respuesta.

Los cinco errores que se repiten

1. Instalar por FOMO. Cinco skills que no usas empeoran al agente: le comen contexto y le dan instrucciones contradictorias. Menos y elegidas.
2. Instalar el plugin y además copiar los archivos. Acabas con todo duplicado y con el agente sin saber cuál mandar.
3. No ejecutar el comando de configuración. Muchos repos traen un /setup-... que hay que lanzar una vez por proyecto. Si te lo saltas, la mitad de las skills no hacen nada y crees que el repo es malo.
4. Fiarte del número de estrellas. Mira mejor los commits del último mes y si el autor responde issues.
5. Confundir "no tiene interfaz" con "no funciona". Si el repo es una skill, no hay nada que abrir. Se nota cuando le pides al agente la tarea que la skill cubre.

Cómo elijo qué repos analizo

En esta sección no cubro todo lo que sube. El filtro que aplico:

• Que resuelva un problema que tienes de verdad, no uno que suene bien en un hilo.
• Que se pueda verificar. Si no puedo instalarlo y comprobar lo que promete, no lo publico.
• Que aguante tres meses. Prefiero llegar tarde a un repo que sigue vivo que primero a uno que desaparece.

Los datos de cada ficha (estrellas, lenguaje, licencia) los saco de la API de GitHub, no del README, y llevan la fecha del día en que se consultaron. Las estrellas cambian a diario y una cifra sin fecha es una cifra falsa a los quince días.

Preguntas frecuentes

¿Necesito saber programar para usar estos repos?

Para las skills, no demasiado: instalas y le hablas al agente en tu idioma. Para los repos que son programas completos sí conviene manejarte con la terminal, aunque cada vez menos, porque el propio agente hace la instalación. Lo que sí necesitas es criterio para saber si lo que te ha devuelto está bien.

¿Funciona lo mismo en Claude Code que en Codex?

Casi siempre, porque muchos repos siguen el estándar abierto de Agent Skills y los dos leen el mismo SKILL.md. Cambia dónde van los archivos (~/.claude/skills/ frente a ~/.codex/skills/) y que algunos repos traen un plugin nativo solo para Claude Code, con lo que en Codex se instalan copiando los archivos.

¿Qué hago si una skill no se activa?

Tres comprobaciones, en este orden: que el archivo esté en la ruta correcta del agente, que hayas ejecutado el comando de configuración si el repo lo pide, y que le estés pidiendo una tarea que la skill cubra. Las skills se cargan cuando el agente cree que hacen falta; si le pides algo genérico, no la va a usar.

¿Es seguro dejar que el agente instale cosas solas?

Depende de qué le des permiso a hacer. Instalar una skill es copiar un archivo de texto, y el riesgo es bajo. Ejecutar un script de instalación descargado de internet ya no lo es tanto. La regla práctica: deja que el agente lea e instale, pero revisa tú lo que se ejecuta con permisos de tu usuario.

¿Cada cuánto se actualizan las fichas de esta sección?

Las cifras de cada repo se refrescan contra la API de GitHub y llevan siempre la fecha del último dato. Los análisis se revisan cuando el repo cambia de forma relevante: si un proyecto se abandona o cambia de licencia, lo digo en su ficha en vez de dejar el artículo como estaba.