La skill en tres minutos
Una skill funcionando antes de explicar qué es. La promesa se demuestra, no se enuncia.
Todo eso estaba escrito en un archivo, una sola vez.
Webinar en vivo el jueves 1 de octubre, 9:00 h CDMX
Deja de repetir el mismo prompt. Enséñaselo una vez.
--- name: redactando-commits description: Redacta el mensaje de commit a partir de los cambios preparados, siguiendo commits convencionales. Úsala cuando el usuario pida un commit o un mensaje de commit. --- > dame un mensaje de commit para esto ✓ skill cargada sin escribir / feat(facturas): agrega cupones de descuento
38 minutos de exposición y 52 con la terminal en pantalla. Cada demo tiene su corrida capturada paso a paso, para que la repases a tu ritmo.
Una skill funcionando antes de explicar qué es. La promesa se demuestra, no se enuncia.
Todo eso estaba escrito en un archivo, una sola vez.
La descripción siempre en contexto; el cuerpo, solo al invocar. El concepto del que depende todo lo demás.
La descripción siempre está en contexto. El cuerpo, no.
La misma skill con dos descripciones. Una nunca se activa y la otra sí. Solo cambió el texto.
Si no se dispara, el problema está en la descripción.
La que vas a usar mañana: convertir una conversación que ya funcionó en una skill reutilizable.
Nadie escribe un SKILL.md bueno de memoria y a la primera.
Una skill que ejecuta código, y el patrón que evita la solicitud de permiso.
Los scripts se ejecutan, no se leen.
Diagnóstico de una skill saboteada. Las fallas más caras son las que ninguna herramienta señala.
Las descripciones malas no las marca ninguna herramienta.
Todo se descarga aquí mismo, sin salir de la página.
Para leer, imprimir y consultar. Empieza por aquí.
DescargarZIP
Trece skills listas para instalar en tu equipo.
DescargarZIP
Para repasar las demos o replicar el webinar.
DescargarZIP · 3 MB
Cada documento del primer paquete también se descarga por separado.
Tócalas para leerlas completas antes de instalarlas. Muestran las decisiones, no solo las reglas.
cp -r kit-skills/calidad-documental/* ~/.claude/skills/
mkdir -p .claude/skills cp -r kit-skills/desarrollo/* .claude/skills/ git add .claude/skills && git commit -m "add: kit de skills"
La descripción está siempre en contexto. El cuerpo, no. Ese es todo el mecanismo.
Una skill casi no cuesta nada hasta que hace falta. Lo que decide si existe en la práctica es una sola línea de texto.
Qué hace y cuándo usarla, en tercera persona y con las palabras que escribirías tú. Si se pasa, se recorta por el final: el caso principal va primero.
El tope del SKILL.md. Si lo pasa, hay que partirla.
De SKILL.md a reference.md, nunca más profundo.
Cuánto detalle depende de qué tan frágil es la tarea.
Un gerundio que describe la actividad: revisando-prs, no helper. El directorio define el comando.
Si está bien descrita, se dispara sola.
Arriba, entre los tres guiones, los metadatos: siempre están en el contexto de Claude. Abajo, el cuerpo: solo entra cuando la skill se usa.
| Nivel | Ruta | Alcance |
|---|---|---|
| Personal | ~/.claude/skills/ | Todos tus proyectos |
| Proyecto | .claude/skills/ | Ese repo, viaja con git |
| Plugin | empaquetada | Espacio de nombres propio |
| Administrada | organización | Toda la empresa |
La que usarás en equipo es la de proyecto: se versiona con el código y llega con el git clone.
--- name: resumiendo-cambios description: Resume los cambios sin commitear y señala lo riesgoso. Úsala cuando el usuario pregunte qué cambió, pida un mensaje de commit o quiera revisar su diff. --- ## Cambios actuales !`git diff HEAD` ## Instrucciones Resume en dos o tres viñetas qué cambió. Luego lista los riesgos: manejo de errores ausente, valores hardcodeados, pruebas que quedaron desactualizadas.
Es lo único que Claude ve para decidir si tu skill aplica. Si está mal, la skill no existe.
Se inyecta en la indicación del sistema.
Analiza documentos y aplica el formato del equipo.
Te puedo ayudar con tus documentos.
Úsala cuando el usuario mencione README, documentación o formato.
Úsala para la gestión documental del repositorio.
Si se recorta, se recorta por el final.
Combinado con when_to_use.
Varios caminos sirven
Dirección general, en prosa. Revisión de código, análisis.
Hay un patrón preferido
Plantilla o script con parámetros. Commits, reportes.
La secuencia importa
Comando exacto, prohibido variarlo. Migraciones, despliegues.
mi-skill/ ├── SKILL.md el procedimiento ├── reference.md el detalle, si hace falta └── scripts/ └── revisar.sh se ejecuta, no se lee
SKILL.md a reference.md, nunca un tercer archivo.${CLAUDE_SKILL_DIR}. Nunca absolutas.CLAUDE.mdHecho permanente del proyecto
SkillProcedimiento o material de referencia
SubagenteTarea con contexto aislado y rol propio
HookRegla que debe cumplirse siempre
Servidor MCPAcceso a un sistema externo
CLAUDE.md o skill
¿Hace falta en cada conversación, o solo en algunas?
Skill o hook
¿Confío en que el modelo decida aplicarlo?
| Síntoma | Causa más probable | Qué revisas |
|---|---|---|
| No se activa nunca | Descripción sin tus palabras reales, o en 1ª o 2ª persona | description |
Responde a /nombre pero nunca sola | Frontmatter mal formado | Los tres guiones |
| Se activa cuando no debe | Descripción demasiado amplia | Acota el «cuándo» |
| No encuentra un archivo | Ruta absoluta o barra invertida | ${CLAUDE_SKILL_DIR} |
| Salta la solicitud de permiso | Falta declarar la herramienta | allowed-tools |
| A veces sí, a veces no | Referencias a dos niveles | Aplana a uno |
| La invocación se aborta | Un comando ! falló | Pruébalo a mano |
Pégalo al final de la conversación en la que resolviste algo que vas a volver a necesitar.
Destila esta conversación en un SKILL.md de Claude Code. Nombre en gerundio. Descripción en tercera persona con la fórmula [qué hace] + "Úsala cuando..." usando las palabras que yo usé de verdad en esta conversación, no lenguaje de manual. En el cuerpo pon solo el contexto que tuve que darte y que no sabías; quita todo lo que ya sabías. Menos de 60 líneas. Termina con un comentario del grado de libertad. Dame el archivo y el mkdir. Nada más.
Con prompting normal, en una sesión cualquiera. Fíjate en qué contexto tuviste que dar y dónde corregiste a Claude.
La conversación ya tiene todo: el contexto, las correcciones y el resultado que aceptaste. Recorta lo que Claude ya sabía.
Sesión nueva. Pide la tarea en lenguaje natural, sin escribir /. Si se dispara sola, la descripción funciona.
¿No se disparó? Corrige la descripción. ¿Hizo otra cosa? Corrige el cuerpo. Nadie escribe un SKILL.md bueno a la primera.
El ambiente que deja tu máquina igual que la de la transmisión, el guion de las demos y todo el paquete de documentación. Para repasar, o para replicar el webinar con tu equipo.
| Script | Qué hace |
|---|---|
preparar.sh | Crea ~/demo-webinar con un calculador de facturas y cuatro problemas sembrados, e instala las skills de las demos |
verificar.sh | Revisa versión, sesión, skills, diff y permisos, y dice qué falta |
resetear.sh | Devuelve todo al estado inicial entre una demo y otra |
Requiere Claude Code 2.1.233 o más nueva.
unzip ambiente-demo.zip bash ambiente-demo/preparar.sh bash ambiente-demo/verificar.sh
La mayoría de quienes ven un webinar no aplican nada. No es falta de interés: falta un siguiente paso concreto. Este es.
Copia redactando-commits, prepara un cambio y pide un mensaje de commit. Fíjate en que no escribiste /. Luego anota tu caso y destílalo.
Tres usos reales. Una línea cada vez que tropiece. Sin datos de uso, las mejoras son suposiciones.
Corrige una sola cosa con el ciclo A/B. La segunda, en otra categoría, sale en la mitad del tiempo.
Límpiala con la variante para equipo del destilador, súbela al repositorio y pide una prueba sin explicar nada.
¿Cuántas en uso real? ¿Cuál no se invocó en dos semanas? Corre auditando-skills sobre las tuyas.
Tu avance se guarda en este navegador.
Antes de ejecutar una skill que no escribiste, lee su allowed-tools. Preaprueba, no restringe.