Buenas prácticas para crear skills que funcionen
Una skill puede estar perfectamente escrita por dentro y aun así no activarse nunca, o activarse cuando no toca. Estos son los principios que separan una skill que funciona de una que Claude ignora. SkillCreator los aplica por ti, pero conocerlos te ayudará a escribir mejores skills.
1. La descripción manda
Claude no lee el interior de todas tus skills en cada mensaje: lee el nombre y la descripción, y con eso decide cuál usar. Por eso la descripción debe contener las dos cosas: qué hace la skill y cuándo usarla. Escríbela en imperativo («Usa esta skill cuando…») y sé un poco insistente: enumera varias situaciones e incluye casos en los que el usuario no la nombre de forma explícita. Es la mejor defensa contra la infra-activación (que la skill exista pero no se dispare). Tienes una guía dedicada en cómo escribir buenas descripciones.
2. Instrucciones en imperativo, y explica el porqué
Da las órdenes de forma directa: «Comprueba…», «Redacta…», «Verifica…». Y cuando una instrucción sea importante, explica por qué lo es. Los modelos actuales siguen mejor una norma cuando entienden el motivo que cuando reciben un «SIEMPRE» o «NUNCA» en mayúsculas y sin contexto. «No apliques cambios sin revisarlos antes, porque un error en producción afecta a usuarios reales» funciona mejor que «NUNCA apliques sin revisar».
3. Los ejemplos enseñan más que las reglas
Un buen ejemplo de entrada y salida le enseña a Claude el resultado esperado mejor que un párrafo de instrucciones. Usa el patrón «Petición → Resultado» con casos realistas. Dos o tres ejemplos bien elegidos valen más que diez reglas abstractas.
4. Define el formato de salida
Si tu skill debe devolver siempre un resultado con la misma estructura (un informe, una plantilla, unas secciones fijas), defínela explícitamente con una plantilla. Así el resultado es consistente en cada uso. En SkillCreator tienes un bloque específico para esto.
5. Divulgación progresiva: mantén la skill ligera
El cuerpo de la skill debe ser conciso. El material pesado —documentación extensa, tablas de referencia, scripts— va en carpetas aparte (references/, scripts/) que Claude consulta solo cuando las necesita. Así el contexto se mantiene ligero y la skill es rápida. Es lo que Anthropic llama «divulgación progresiva».
6. Una skill, una capacidad
Cada skill debe hacer una cosa bien. Si intentas meter tres tareas distintas en una sola, la descripción se vuelve difusa y Claude no sabrá cuándo activarla. Si necesitas varias capacidades, crea varias skills.
7. Nombre correcto
El nombre va en minúsculas, con guiones y sin acentos (por ejemplo analista-de-csv), con un máximo de 64 caracteres. SkillCreator lo formatea por ti automáticamente.
Lo bueno: no tienes que recordar todo esto
El creador de SkillCreator ya aplica estos principios: puntúa tu descripción en vivo, estructura el SKILL.md con el formato correcto, te ofrece un bloque de formato de salida y valida el nombre. Tú aportas la idea; nosotros las buenas prácticas.