01 La idea: usar el modelo caro para escribir el procedimiento
Gran parte de lo que hace bueno a un modelo potente no es lo que sabe, sino cómo trabaja: en qué orden revisa, qué preguntas hace antes de empezar, qué considera prueba suficiente. Ese método se puede escribir. En Claude Code, el formato para guardarlo es una skill: una carpeta con un archivo SKILL.md que contiene instrucciones y que Claude carga cuando la tarea coincide con su descripción.
El planteamiento es invertir una sesión de Fable (o de Opus, si no tienes Fable) en redactar ese procedimiento adaptado a tu proyecto, y luego dejar que Sonnet u Opus lo ejecuten a diario con un consumo mucho menor.
02 Cómo es una skill
| Ubicación | Alcance |
|---|---|
| .claude/skills/nombre/SKILL.md | Solo ese proyecto; se puede versionar con Git y compartir con el equipo |
| ~/.claude/skills/nombre/SKILL.md | Todos tus proyectos, solo en tu ordenador |
El archivo empieza con una cabecera YAML entre líneas ---. Solo la description es realmente recomendable: es lo que Claude lee para decidir cuándo usar la skill, así que debe decir qué hace y en qué situaciones aplicarla. Si quieres que solo se ejecute cuando escribas /nombre, añade disable-model-invocation: true. Debajo de la cabecera van las instrucciones en Markdown.
03 Qué procedimientos merece la pena extraer
Elige tareas que repites, en las que la calidad depende del método y en las que ahora notas diferencia entre modelos. Algunas ideas para un equipo de desarrollo y para el resto de la empresa:
Auditoría de seguridad
Orden fijo de revisión y la regla de reportar solo lo que se puede demostrar, con archivo, línea y cómo se explota.
Diagnóstico de bugs
Reproducir antes de tocar, aislar la causa, escribir la prueba que falla y no aceptar «ya está» sin evidencia.
Inicio de proyecto
Las preguntas imprescindibles antes de escribir código y lo mínimo que debe existir el primer día.
Crítica de una propuesta
Reformular la idea en su mejor versión, atacarla desde varios ángulos y terminar con un veredicto claro.
Propuesta comercial
Cómo analizar el caso del cliente, estructurar la oferta y revisar precios y plazos antes de enviarla.
Revisión de textos
Criterios de tono de marca, comprobación de datos y lista de expresiones a evitar.
04 Paso a paso
-
1
Abre el proyecto y elige el modelo
En Claude Code, ejecuta /model fable (o /model opus). Una skill por conversación para que el contexto no se mezcle.
-
2
Pide que explore antes de escribir
Una skill genérica aporta poco. Lo valioso es que use los comandos, rutas y riesgos reales de tu proyecto.
-
3
Revisa el SKILL.md
Léelo entero. Si hay pasos vagos («revisa la seguridad»), pide que los concrete. Si hay suposiciones, corrígelas.
-
4
Pruébala con otro modelo
Cambia a /model sonnet, abre una sesión nueva y pide la tarea. Comprueba que sigue los pasos y que el resultado es útil.
-
5
Ajusta y versiona
Pide al modelo potente que corrija lo que falló en la prueba y guarda la skill en Git.
Quiero convertir tu forma de hacer [tarea] en una skill que otros modelos puedan seguir en este proyecto.
1. Explora primero el proyecto: tecnologías, estructura, cómo se ejecuta y qué partes son delicadas.
2. Escribe .claude/skills/[nombre]/SKILL.md con una cabecera que tenga name y una description que explique qué hace y cuándo usarla.
3. En el cuerpo, describe el procedimiento como lo harías tú: pasos en orden, qué compruebas en cada uno, qué cuenta como prueba suficiente, errores frecuentes que debe evitar y el formato exacto del resultado.
4. Usa comandos, rutas y archivos reales de este proyecto. Si algo depende de información que no tienes, pregúntamelo en lugar de inventarlo.
5. Escribe las instrucciones para un modelo competente pero menos capaz que tú: concretas, sin ambigüedades y sin pasos implícitos.
Al terminar, enséñame el archivo y propón una prueba corta para validarlo con otro modelo.05 Ejemplo: skill de corrección de bugs con evidencia
---
name: corregir-bug
description: Procedimiento para diagnosticar y corregir un bug con evidencia. Usar cuando se informe de un error, un test que falla o un comportamiento inesperado.
---
# Corregir un bug con evidencia
## 1. Reproducir
- Escribe los pasos exactos que provocan el fallo y ejecútalos.
- Si no consigues reproducirlo, detente e informa de lo que probaste.
## 2. Aislar la causa
- Formula una hipótesis y compruébala con logs, un test o una ejecución mínima.
- No cambies código hasta poder explicar la causa en una frase.
## 3. Fijar el fallo en un test
- Escribe un test que falle por este bug antes de corregirlo.
## 4. Corregir lo mínimo
- Cambia solo lo necesario. Nada de refactorizaciones de paso.
## 5. Demostrar
- Ejecuta el test nuevo y la suite relacionada. Pega la salida.
- Comprueba el caso original a mano si es posible.
## Formato del informe
Causa (una frase) · Archivos cambiados · Prueba (comando y salida) · Riesgos pendientes.
## Prohibido
- Dar el bug por resuelto sin salida de tests.
- Desactivar o borrar tests para que pasen.Preguntas frecuentes
No. Funciona con Opus y también con Sonnet. Usar el modelo más capaz que tengas mejora la calidad del primer borrador, pero lo importante es revisar y probar la skill.
Sí, si su description encaja con lo que pides. Si prefieres invocarla solo a mano con /nombre, añade disable-model-invocation: true en la cabecera.
Sí. Las que están en .claude/skills/ del proyecto se versionan con el repositorio y cualquiera que lo clone las tendrá.
Pocas y buenas. Empieza por las dos o tres tareas en las que más se nota la diferencia de calidad y añade más cuando las uses con regularidad.
Sobre el autor
Equipo editorial de appyweb
Marketing, SEO y desarrollo con IA
Especialistas de appyweb en SEO, publicidad, desarrollo web y automatización con IA.