Habilidades de verificación

Por qué una skill de verificación es la primera que debes construir

Piensa en cómo normalmente revisas el trabajo de Claude. Le pides que refactorice algo, termina, y luego tienes que acordarte de revisarlo dos veces. Tal vez le pides que ejecute las pruebas. Tal vez lees el diff tú mismo. El problema es que la revisión depende de que tú te acuerdes de pedirla. Te saltas ese paso una vez y el código defectuoso se te escapa.

Una skill de verificación elimina esa dependencia. Así es como funciona. Le pides a Claude que refactorice algo. Cuando termina, el cambio coincide con la descripción de la skill, así que la skill se activa por sí sola. A partir de ahí:

• Ejecuta la suite de pruebas.
• Lee el diff.
• Verifica que ninguna prueba se haya debilitado solo para que pase.
• Reporta éxito o fallo, con la evidencia adjunta.

Todo el flujo se ejecuta sin que tú lo pidas. La descripción de la skill es lo que la activa, y una vez activada recorre los mismos pasos cada vez.

Fíjate en la última verificación de esa cadena. No basta con ejecutar las pruebas y ver que pasan. Una prueba puede debilitarse silenciosamente para que pase sin importar qué. Por eso la skill lee el diff y confirma que las pruebas no se debilitaron. "Terminado" no es "el código se ve bien" a partir de leer el diff solamente. Terminado es que las verificaciones se ejecutaron y se observaron, con los resultados declarados explícitamente.

Esta misma estructura sirve para cualquier procedimiento que tu equipo repita. Una lista de verificación de lanzamiento. Una receta de migración. Una revisión previa a un PR. La regla general: si has escrito la misma instrucción de varios pasos dos veces, eso es una skill.

Una carpeta de skill puede contener más que instrucciones

Una skill no es solo un único archivo SKILL.md. La carpeta que la rodea puede contener otras cosas, y esto es lo que hace que las skills sean útiles para la verificación.

• Coloca un reference.md junto a SKILL.md para el material detallado, y luego enlázalo desde SKILL.md. Claude lo lee solo cuando necesita esa profundidad. Tu archivo principal se mantiene corto.
• Pon también scripts en la carpeta. Claude los ejecuta en lugar de cargar su contenido en el contexto. Eso significa que una skill puede llevar sus propias herramientas, como un check.sh que ejecuta todas las verificaciones.

La conclusión: mantén SKILL.md en sí mismo ligero. Empuja el material pesado (las explicaciones largas y los scripts ejecutables) hacia archivos secundarios. El archivo ligero describe qué hacer. Los archivos secundarios contienen la profundidad y las herramientas.

Qué superficie de instrucciones posee cada regla

A estas alturas tienes tres lugares donde poner instrucciones, y es fácil confundirlos. Aquí tienes una forma rápida de mantenerlos claros.

Las convenciones que aplican todo el tiempo, cosas como reglas de nomenclatura o dónde van los archivos, pertenecen a tu archivo CLAUDE.md. Los procedimientos y el material de referencia vinculados a un tipo particular de tarea pertenecen a una skill.

Hay un tercer caso. Una regla que Claude no debe poder saltarse pertenece a un hook, no a ninguno de los dos anteriores. Eso es porque CLAUDE.md y las skills son ambas instrucciones que Claude sigue, mientras que un hook es código que realmente se ejecuta. Si saltarse la regla no es aceptable, no lo dejes en manos de seguir instrucciones.

El resumen

Una skill es una carpeta con un SKILL.md dentro: un nombre, una descripción que la activa, y el procedimiento en sí. Solo las descripciones se cargan en el contexto hasta que se necesita una skill, así que hay poco costo en empaquetar cada procedimiento que repites.

Empieza con la verificación. Construye la skill, agrégala a .claude/skills de tu proyecto, y ahora todo el equipo hereda el mismo movimiento. El trabajo de todos se revisa de la misma manera, automáticamente, sin que nadie tenga que acordarse de pedirlo.