Después de meses acumulando skills en Claude Code, revisé cuáles seguían aportando a mi trabajo. Tenía procedimientos propios, recursos instalados y funciones de plugins que apenas utilizaba. La pregunta dejó de ser cuántas skills podía reunir y pasó a ser qué resultado justificaba conservar cada una.
En el video explico mi filtro de las 3R: repetible, requisito y repartible. Es una forma de distinguir instrucciones útiles de recetas heredadas que ya no encajan con el proyecto o con el modelo que estás utilizando.
Por qué revisé mis instrucciones
El punto de partida fue una entrevista de Y Combinator a Boris Cherny. Allí explica que el equipo reevalúa instrucciones y herramientas cuando cambia el modelo, retirando elementos y comprobando qué aportan. Mi video traslada esa idea al entorno de alguien que utiliza Claude Code para su negocio y contenido.
Una instrucción puede haber resuelto una dificultad real hace meses. Si el modelo o la herramienta cambia, también puede cambiar su utilidad. Mantenerla para siempre sin volver a probarla añade una decisión antigua a trabajos que quizá necesitan otra solución.
Eso no convierte todas las skills en un problema. En mi guía de skills y MCP explico su utilidad para reunir instrucciones y acciones. Aquí el foco es el mantenimiento de esa biblioteca: conservar lo que resuelve una necesidad y retirar lo que solo quedó instalado.
Qué aporta una skill y qué no hace
Una skill puede reunir procedimientos, contexto, ejemplos y recursos para una tarea. No modifica los pesos del modelo ni garantiza que cada ejecución produzca exactamente el mismo resultado. La repetibilidad requiere también entradas claras y verificación.
La documentación de skills de Claude Code distingue la información usada para descubrir una skill del contenido que se carga cuando se utiliza. Por eso, tener muchas skills no equivale necesariamente a incorporar todos sus archivos completos al inicio de cada conversación. Aun así, las descripciones irrelevantes y las instrucciones que sí se activan pueden añadir ruido.
El problema práctico aparece cuando una receta dicta decisiones que ya no necesitas fijar. Por ejemplo, un procedimiento que obliga a utilizar una herramienta antigua puede impedir que el agente elija otra disponible y más adecuada para ese encargo.
En cambio, explicar la voz de tu marca, un formato de entrega acordado o la ubicación correcta de los archivos aporta información que el modelo no puede deducir con fiabilidad. Esa diferencia es la base del filtro.
Primera R: ¿es repetible?
Pregúntate si necesitas ejecutar el mismo proceso de manera consistente. En el video utilizo como referencia personal hacerlo igual más de tres veces al mes. Es una regla práctica de mi trabajo, no un umbral técnico que determine cuándo funciona una skill.
Facturación, propuestas o una distribución de contenido con entregables definidos pueden beneficiarse de un procedimiento estable. Una exploración única, en cambio, quizá solo necesita un buen encargo y los materiales relevantes.
La señal más útil no es que dos tareas se parezcan por su nombre. Es que compartan condiciones, decisiones y criterios de salida suficientes para que el procedimiento ahorre trabajo sin limitar lo importante.
Segunda R: ¿contiene un requisito que no se puede adivinar?
Esta pregunta busca información propia: cómo escribes, qué nombres utiliza tu negocio, dónde debe quedar un entregable o qué formato necesita tu equipo.
En mi caso conservé el material que describe mi tono de voz con ejemplos reales. Su valor está en el contexto sobre mí. Pedir “escribe como Benja” sin ese material deja al modelo intentando rellenar demasiados vacíos.
También conviene separar lo estable de lo que cambia. La identidad de una marca puede vivir en una referencia mantenida; una fecha de campaña o un precio temporal necesita datos actuales del encargo. Mezclarlos en una receta permanente facilita que una instrucción vencida vuelva a aparecer meses después.
Para organizar ese contexto tienes la guía de Claude Code y Obsidian. Una biblioteca de conocimiento y un procedimiento de ejecución resuelven necesidades relacionadas, pero no idénticas.
Tercera R: ¿es repartible?
Una skill también puede servir para entregar un proceso a otra persona. Si tu equipo necesita producir el mismo tipo de documento o seguir un estándar compartido, empaquetar ese conocimiento reduce explicaciones repetidas.
Para que sea transferible, identifica qué datos necesita quien la ejecuta, qué depende de tu entorno y qué debe revisar al terminar. Una ruta que solo existe en tu computador o una conexión personal no se vuelve compartida porque hayas copiado el archivo.
Las tres preguntas no son una prueba que obligue a cumplir las tres condiciones. Una skill puede justificar su existencia por aportar un requisito importante aunque se use poco. Si no aporta en ninguna de ellas, es una buena candidata a revisión.
Cómo probar una biblioteca más simple sin perderla
La técnica que comento en el video es la ablación: retirar una parte y observar qué cambia. La aplicación útil requiere comparación, no una eliminación masiva seguida de una impresión subjetiva.
Puedes hacer esta prueba editorial en una copia del entorno:
- Guarda la versión de las instrucciones que utilizas y anota qué problema resuelve cada una.
- Elige una tarea representativa con un resultado que puedas comprobar.
- Registra el comportamiento con la configuración actual.
- Desactiva una instrucción o una skill candidata, manteniendo las mismas entradas y modelo.
- Compara el entregable, las correcciones necesarias y el consumo.
- Conserva, simplifica o restaura según la evidencia.
Los controles de acceso y los hooks que protegen recursos necesitan una revisión distinta. Que una instrucción de estilo ya no aporte no demuestra que puedas retirar un control que impide una operación peligrosa. Tampoco una instrucción en CLAUDE.md sustituye los permisos que aplica la herramienta.
Mi experiencia al conservar procedimientos propios no significa que las skills externas sean malas. Revisa su ajuste al encargo: una buena skill de otra persona puede ser una base útil, necesitar adaptación o no aportar a tu caso.
Tarea, límites y criterio de término
La otra aplicación del video es cambiar la forma del encargo. En vez de prescribir cada movimiento, explico qué resultado busco, qué debe respetarse y cómo comprobar que terminó.
| Parte | Pregunta que resuelve | Ejemplo editorial |
|---|---|---|
| Tarea | ¿Qué debe quedar hecho? | Preparar una página de recurso a partir del material aprobado |
| Límites | ¿Qué condiciones debe respetar? | Usar la marca y los enlaces indicados, sin inventar testimonios |
| Criterio de término | ¿Cómo se comprueba? | Página revisable, enlaces válidos y recorrido usable en móvil |
Dar libertad sobre el método no significa dejar el resultado indefinido. “Hazlo increíble” no explica qué falta para terminar. “Déjame una versión revisable que complete este recorrido” ofrece una referencia más concreta.
Una comprobación visual tampoco cubre todo. Si el encargo incluye un formulario, hay que probar qué ocurre al enviarlo; si genera un archivo, abrirlo; si modifica un sistema, comprobar el comportamiento relevante. El tipo de evidencia debe corresponder a la tarea.
Cuándo siguen sirviendo loops y workflows
Simplificar no obliga a abandonar herramientas que sí resuelven un problema. Un trabajo grande que se puede dividir, una tarea periódica y un objetivo de varias iteraciones son necesidades diferentes.
Tienes ejemplos específicos en la auditoría con workflows de Claude Code, las routines con Notion y Gmail y los loops con DAME. Elige el mecanismo después de entender la necesidad y sus condiciones de ejecución.
Para empezar, basta una tarea real y una forma de revisarla. Agrega estructura cuando detectes una repetición útil, un requisito que se pierde o una parte del proceso que otro necesita ejecutar.
Video completo y recursos
En el video de la regla de las 3R reviso mi biblioteca y desarrollo los ejemplos de instrucciones y verificación. Si todavía estás armando tu entorno, puedes seguir el curso completo de Claude Code.
Comparte en los comentarios qué skill te aporta más valor y suscríbete a YouTube para ver las siguientes pruebas. Los recursos de implementación de la comunidad están en Imperio Agéntico en Skool.
Preguntas frecuentes
¿Hay que borrar todas las skills de Claude Code?
No. La guía propone revisar qué aporta cada una, conservar procedimientos y contexto útiles y probar cambios de forma reversible. Los controles de acceso y hooks de protección requieren una evaluación específica antes de modificarse.
¿Cuáles son las 3R de Benjamín Cordero?
Repetible: estandariza una tarea recurrente. Requisito: contiene datos o condiciones que el modelo no puede adivinar. Repartible: permite compartir un proceso con otra persona. Son tres razones posibles para conservar una skill.
¿Una skill debe cumplir las tres condiciones?
No necesariamente. Puede aportar un requisito importante aunque se use poco. Si no aporta repetición útil, contexto necesario ni un proceso compartible, conviene revisar por qué sigue instalada.
¿Tener muchas skills carga todos sus archivos en cada sesión?
No necesariamente. Claude Code distingue las descripciones utilizadas para descubrir skills del contenido que se incorpora al activarlas. Aun así, instrucciones irrelevantes o redundantes pueden añadir ruido cuando se utilizan.
¿Qué es la ablación aplicada a instrucciones?
Consiste en retirar una parte de la configuración y observar su efecto. Para que la comparación sea útil, conserva una copia, usa tareas representativas y revisa resultado, correcciones y consumo antes de decidir.
¿Qué skill conservó Benjamín Cordero?
Entre las que describe en el video está el material de su tono de voz con ejemplos propios. Aporta contexto sobre cómo comunica, en vez de limitarse a imponer una secuencia genérica de pasos.
¿Cómo escribir un encargo sin detallar todos los pasos?
Define la tarea, las condiciones que debe respetar y el criterio de término. Después proporciona una forma de verificar el resultado, como probar un recorrido, abrir un archivo o comprobar datos contra sus fuentes.
¿Simplificar implica dejar de usar loops o routines?
No. Esas herramientas siguen siendo útiles para necesidades concretas. Elige primero si necesitas repetición periódica, dividir un trabajo o avanzar hacia un objetivo, y después selecciona el mecanismo adecuado.