Buscar Skills

Buscar skills que valgan la pena

El ecosistema de skills está saturado de listas "Top 50 skills 2026" escritas para posicionar en Google. Rankean por estrellas e instalaciones, que miden popularidad, no calidad, y sus cifras ni siquiera coinciden entre sí: el mismo repositorio aparece con 58K, 76K y 105K estrellas en tres artículos distintos, todos con tono de autoridad.

Por eso esta skill no consulta rankings para decidir. Los usa, como mucho, para descubrir candidatos; el veredicto sale siempre de leer el SKILL.md real en el repositorio.

Y hay un segundo problema que ninguna lista resuelve: una lista solo sabe sumar. Nunca te dice "no instales esto, ya lo tienes". Ese suele ser el consejo más valioso.

El recorrido

1. Entender qué capacidad falta de verdad

Antes de buscar nada, ten claro qué problema se quiere resolver. Si el usuario pide "skills de testing", lo que necesita puede ser generar tests, ejecutarlos, medir cobertura o diseñar casos límite — son cuatro skills distintas. Si no está claro, pregunta una sola vez y sigue.

2. Leer el perfil antes de recomendar

Una recomendación sin perfil es un ranking. Lee, en este orden:

• ~/.claude/CLAUDE.md — stack, forma de trabajar, a quién le vende, qué le importa.
• El CLAUDE.md del proyecto actual, si existe.
• Los archivos de memoria en ~/.claude/projects/*/memory/.

Extrae de ahí el stack real y los criterios que lo condicionan. Un despliegue en Azure hace irrelevantes seis skills excelentes de AWS SageMaker; no es un detalle menor, es la diferencia entre una recomendación y ruido.

3. Descartar lo ya cubierto — hazlo antes de buscar

Este paso va antes de salir a internet, porque a menudo lo termina. Inventaría lo que ya existe:

• Skills integradas y activas de la sesión (la lista de skills disponibles).
• ~/.claude/skills/ y .claude/skills/ del proyecto — las propias.
• ~/.claude/agents/ — agentes propios.
• Comandos integrados que ya cubren el terreno: /code-review, /security-review, /simplify, /init, /run.
• hf skills list, si el CLI hf está instalado.

Si algo ya cubre la necesidad, dilo primero y con claridad, antes de proponer alternativas. Instalar una segunda herramienta que hace lo mismo que una que ya está no añade capacidad: añade dos criterios distintos compitiendo por el mismo trabajo.

4. Buscar candidatos

Usa búsqueda web y, si gh está instalado, la API de GitHub (gh search repos, gh api), que da datos verificables en vez de páginas raspadas. Fuentes razonables para descubrir:

• Marketplaces oficiales: anthropics/claude-code, huggingface/skills.
• Directorios comunitarios grandes (VoltAgent, Composio y similares) — solo como índice.
• Búsqueda directa en GitHub por SKILL.md y el tema agent-skills.

Reúne entre 5 y 10 candidatos. Más es desperdiciar esfuerzo en la fase de auditoría.

5. Auditar cada candidato leyendo su SKILL.md

Este es el paso que nadie hace y el que da todo el valor. Trae el SKILL.md real (WebFetch sobre la vista raw de GitHub, o gh api) y evalúalo. Un candidato cuyo SKILL.md no puedas leer no se recomienda — se reporta como no verificable.

Puntúa cada uno sobre estas cinco señales, en references/rubrica.md está el detalle:

El Disparo es la señal más predictiva y la más ignorada: una skill excelente con una descripción vaga nunca llega a activarse, y entonces su calidad es irrelevante. Si el description no contiene condiciones de uso, eso solo ya baja mucho la nota.

El Encaje funciona como veto, no como suma: una skill impecable para un stack que el usuario no usa vale cero para él.

6. Señales de humo

Cuando aparezcan varias de estas juntas, el candidato se descarta:

• El description es una sola frase temática sin condiciones ("Skill for testing").
• El SKILL.md es un prompt largo de tono motivacional sin un solo paso concreto.
• El README promete un porcentaje de mejora espectacular sin decir cómo se midió.
• El repositorio es un agregado de cientos de skills generadas de golpe, todas con la misma estructura y ninguna con recursos propios.
• Solo lo encuentras citado en artículos de blog, nunca en el repositorio original.
• Cifras de popularidad que no coinciden entre fuentes — señal de contenido hecho para SEO.

El informe

Usa esta estructura. La sección de descartes no es relleno: suele ser la más útil.

## Ya lo tienes
[Capacidad → qué la cubre ya. Si esto resuelve la petición, dilo y para aquí.]

## Recomendadas
### 1. nombre-skill · encaje alto
Qué hace en una frase.
**Por qué a ti:** [ligado a algo concreto de su perfil o sus proyectos]
**Calidad:** disparo bien definido · trae scripts · último commit hace 3 semanas
**Reserva:** [lo que no cubre, o dónde puede fallar]
`comando de instalación exacto`

## Con reserva
### nombre-skill · encaje medio
[Para candidatos con buen contenido pero algo que impide recomendarlos sin más: repositorio
sin trayectoria, solapamiento parcial, enfoque distinto al que se pidió.]
**Lo que tiene:** [verificado leyendo el archivo]
**Lo que falta:** [el motivo concreto de la reserva]
`comando de instalación, si decide probarlo`

## Descartadas
- **nombre** — motivo en una línea (duplica X / no encaja con Azure / sin condiciones de uso)

## Sin verificar
- **nombre** — no pude leer su SKILL.md; no la recomiendo a ciegas.

No mezcles los cajones. Si una skill no se recomienda, no puede aparecer bajo "Recomendadas" con un comando de instalación debajo — eso es contradecirse. Un candidato con sustancia pero sin trayectoria (pocos commits, ningún usuario, creado hace semanas) va a Con reserva, nunca a Recomendadas. La sección "Recomendadas" puede quedar vacía perfectamente; cuando lo esté, di simplemente que ninguna alcanza el listón y pasa a la siguiente.

Los comandos de instalación tienen que funcionar

Un comando que falla al pegarlo destruye la confianza en todo el informe. Antes de escribirlo, compruébalo mentalmente paso a paso — y si tienes shell, ejecútalo.

El error más fácil de cometer: mkdir -p .claude/skills seguido de curl -o .claude/skills/nombre/SKILL.md falla, porque curl no crea directorios intermedios. El mkdir tiene que apuntar a la carpeta que va a contener el archivo:

mkdir -p ~/.claude/skills/nombre-skill
curl -sL https://raw.githubusercontent.com/OWNER/REPO/main/ruta/SKILL.md \
  -o ~/.claude/skills/nombre-skill/SKILL.md

Cuando la skill traiga references/, scripts/ o cualquier recurso, un curl de un solo archivo la deja rota: usa git clone y copia la carpeta entera.

Di también dónde la instalas y por qué: ~/.claude/skills/ la deja disponible en todos los proyectos; .claude/skills/ dentro del repositorio solo en ese. Por defecto, global — salvo que la skill sea específica de un proyecto concreto.

Cierra siempre recordando el coste de instalar de más: la descripción de cada skill ocupa contexto en todas las sesiones, así que veinte skills instaladas empeoran que se dispare la correcta. Recomienda tres o cuatro, las que se vayan a usar este mes — no un catálogo.

Cómo mantenerte honesto

• No recomiendes nada que no hayas leído. Si solo tienes el resumen de un buscador, dilo.
• Distingue lo verificado de lo citado. "Su SKILL.md incluye un script de X" es verificable; "es la más popular de 2026" es una cita, y ya sabes cuánto valen.
• Menos es la respuesta correcta a menudo. Terminar con "ninguna de estas merece la pena, lo que ya tienes lo cubre" es un resultado válido y frecuentemente el mejor.
• No infles la lista para que parezca que hubo trabajo. Tres candidatos bien auditados valen más que diez enumerados.