Cómo montar una biblioteca de skills para tu equipo: organización, pruebas y seguridad

Crear una skill es cuestión de una tarde. Lo difícil llega después: cuando hay diez, luego treinta, cada persona tiene su versión de la misma y nadie sabe cuál es la buena, cuál está obsoleta ni cuál toca datos que no debería. Una skill suelta ahorra tiempo a una persona; una biblioteca bien cuidada cambia cómo trabaja un equipo entero.

Esta guía recoge un método práctico para pasar de lo primero a lo segundo sin montar burocracia: cómo organizar las skills, quién las mantiene, cómo comprobar que funcionan y qué revisar antes de compartirlas.

Por qué una biblioteca y no un montón de skills

Una skill es una carpeta con un SKILL.md que Claude carga cuando la petición encaja con su descripción. Eso la hace barata de crear y fácil de copiar, y precisamente por eso se descontrola rápido. Los problemas típicos de un equipo sin biblioteca son tres:

• Duplicados que divergen. Marta tiene «informe-ventas» con un formato; Luis, otro. Los resultados no son comparables y nadie sabe cuál manda.
• Skills que compiten. Dos descripciones parecidas confunden la selección: Claude elige una u otra según el día, y el resultado deja de ser predecible.
• Conocimiento que caduca. Una skill que cita una tarifa, una política o un proceso de hace un año sigue funcionando… y sigue dando respuestas equivocadas con total seguridad.

La biblioteca ataca estos tres frentes a la vez: un único sitio, un responsable por skill y un criterio compartido de qué significa «lista para usar».

Paso 1: un repositorio, una carpeta por skill

La forma más simple de empezar es un repositorio de Git (el mismo que ya usáis para otros proyectos, o uno propio) con una carpeta por skill:

skills-equipo/
├── README.md              ← índice: qué hay y quién la mantiene
├── ventas/
│   ├── propuesta-comercial/
│   │   └── SKILL.md
│   └── informe-semanal/
│       ├── SKILL.md
│       └── plantilla.md
├── soporte/
│   └── respuesta-incidencia/
│       └── SKILL.md
└── _plantilla-skill/      ← punto de partida para las nuevas
    └── SKILL.md

Git te da gratis lo que más falta hace: historial (quién cambió qué y por qué), revisión (nadie publica sin que otra persona lo vea) y vuelta atrás (si una modificación empeora los resultados, se revierte en un minuto). Para que cada persona use la biblioteca, instala o enlaza las carpetas en la ubicación de skills de tu entorno (en Claude Code, la carpeta de skills del proyecto o la personal; en Claude.ai, súbelas desde los ajustes de capacidades según el plan de tu organización).

Paso 2: nombres y descripciones con criterio común

Como Claude decide si usar una skill leyendo solo su nombre y su descripción, esos dos campos son la «interfaz pública» de tu biblioteca. Fija reglas que todo el equipo siga:

1. Nombre en minúsculas, con guiones y con el verbo o el entregable por delante: informe-semanal, revision-contrato.
2. Descripción en dos partes: qué entrega + cuándo usarla, con las frases reales con las que la gente lo pide.
3. Exclusiones cuando haya skills vecinas: «No la uses para propuestas; para eso está propuesta-comercial».
4. Una frase de versión o fecha en el cuerpo del archivo (no en el nombre), para saber cuándo se revisó por última vez.

Paso 3: un dueño por skill

Cada skill necesita una persona responsable, igual que cada documento de procesos importante. El dueño no tiene que escribirla toda; tiene que responder a tres cosas: ¿sigue siendo correcta?, ¿se está usando?, ¿alguien ha propuesto cambios que revisar?

Una tabla en el README.md basta:

La columna «Última revisión» es la más útil: ordénala de vez en cuando y verás qué skills llevan meses sin que nadie las mire.

Paso 4: pruebas, o cómo saber que una skill funciona

Aquí es donde la mayoría de equipos se queda corta. Una skill sin pruebas es una opinión. La buena noticia es que no necesitas infraestructura: basta con un archivo de casos de prueba junto a cada skill.

1. Reúne entre 5 y 10 peticiones reales que deberían activar la skill, con variaciones en cómo se piden.
2. Añade 3-5 peticiones que NO deberían activarla pero se le parecen (los falsos amigos).
3. Para cada caso que sí la activa, anota qué debe tener el resultado: secciones obligatorias, tono, datos que no puede inventar.
4. Ejecuta los casos con la skill instalada y marca aciertos y fallos; guarda el resultado con la fecha.
5. Cada vez que modifiques la skill, repite el conjunto completo y comprueba que no has roto lo que ya funcionaba.

Dos consejos para que esto no se convierta en una carga:

• Convierte cada fallo en un caso nuevo. Cuando alguien reporte «la skill se equivocó con esto», ese ejemplo entra en el conjunto de pruebas. Con el tiempo, tu batería recoge los errores reales, no los imaginados.
• Evalúa el resultado con criterios concretos, no con impresiones. «Queda bien» no es comprobable; «incluye resumen de tres líneas y una tabla de cifras con variación semanal» sí lo es.

Paso 5: revisión de seguridad antes de compartir

Una skill puede incluir instrucciones y también scripts que se ejecutan. Eso las hace muy potentes y exige la misma prudencia que cualquier código o procedimiento que otras personas van a lanzar. Antes de aceptar una skill en la biblioteca, revisa:

• Qué scripts contiene y qué hacen. Léelos completos. Un script que borra, envía datos fuera o descarga y ejecuta algo no debería pasar sin una razón clara.
• A qué datos accede. Una skill de informes no necesita leer tu correo; si lo pide, pregúntate por qué.
• De dónde viene. Instalar skills de terceros desconocidos es equivalente a ejecutar su código. Prioriza las que puedas leer y entender, o las de fuentes que ya conoces.
• Qué permisos necesita. Aplica el principio de mínimo privilegio: solo lo imprescindible para la tarea.
• Qué información sensible hay escrita dentro. Nunca claves, contraseñas ni datos personales de clientes dentro de una skill; viven en un repositorio que más gente puede leer.

Paso 6: medir lo justo

No necesitas un cuadro de mando. Con tres indicadores sencillos sabrás si la biblioteca merece la pena:

• Uso: ¿qué skills se invocan de verdad? Las que nadie usa en dos meses se archivan o se reescriben.
• Tasa de corrección: ¿cuánto tiene que retocar la persona el resultado? Si siempre se corrigen las mismas cosas, esa corrección debería estar escrita en la skill.
• Tiempo ahorrado, estimado: pregunta a quienes la usan cuánto tardaban antes. No hace falta precisión; sí una idea para decidir en qué skill invertir la próxima tarde.

Un prompt para empezar hoy

Si quieres arrancar sin esperar a tener todo organizado, pídele a Claude que te ayude a hacer inventario:

Un calendario realista para el primer mes

• Semana 1: crea el repositorio, la plantilla y el README. Migra solo las dos o tres skills que ya se usan.
• Semana 2: asigna dueños y escribe los casos de prueba de esas skills.
• Semana 3: pasa la revisión de seguridad, publica la biblioteca y enséñala al equipo en una sesión corta.
• Semana 4: recoge fallos reales, conviértelos en casos de prueba y mide el uso.

Empezar con pocas skills y cuidarlas bien da mejores resultados que publicar treinta a medias. Una biblioteca pequeña, fiable y viva se convierte en el modo habitual de trabajar; una grande y abandonada acaba ignorada.

Lo esencial

• Una biblioteca convierte el «cómo lo hacemos aquí» en archivos revisables, versionados y compartidos.
• El nombre y la descripción de cada skill son su interfaz: cuídalos con reglas comunes.
• Un dueño por skill y una fecha de revisión evitan que el conocimiento caduque en silencio.
• Los casos de prueba, alimentados con fallos reales, son lo que separa una skill fiable de una opinión.
• Revisa scripts, datos y permisos antes de compartir: una skill puede ejecutar código.