Cómo organizar tus skills de Claude Code como un equipo de marketing

Las skills de Claude Code se explican casi siempre desde el lado técnico: dónde va el archivo, qué campos lleva la cabecera. Lo que no se cuenta es cómo organizarlas cuando tienes veinte y varias personas usándolas, que es justo cuando empiezan los problemas.

La analogía del equipo funciona bien: una skill es un procedimiento que alguien de tu equipo sabría ejecutar. Y como en cualquier equipo, el problema no es contratar, es repartir responsabilidades sin solaparlas.

Qué es una skill y en qué se diferencia del resto

Merece la pena fijarlo antes de organizar nada:

• CLAUDE.md: siempre presente en el contexto. Para lo que aplica a todo.
• Comando (/algo): se ejecuta cuando tú lo invocas. Para lo que pides explícitamente.
• Skill: se carga sola cuando la tarea encaja con su descripción. Para procedimientos que deberían aplicarse aunque a nadie se le ocurra pedirlos.

Esa última diferencia es la clave organizativa. Una skill bien escrita se activa cuando hace falta aunque quien la necesite no supiera que existía. Por eso son perfectas para el conocimiento que se pierde cuando alguien se va de vacaciones.

El principio: una skill, una responsabilidad

El error más común es la skill saco: «marketing», que contiene redacción, publicación, informes y atención al cliente. Falla por dos motivos: se activa cuando no debe y, cuando se activa, mete en contexto un montón de instrucciones irrelevantes.

Repártelo como repartirías el trabajo entre personas:

« .claude/skills/ ├── redactar-newsletter/ ├── revisar-tono-marca/ ├── planificar-calendario/ ├── analizar-campana/ ├── responder-resenas/ └── informe-mensual-cliente/ «

Cada una hace una cosa y se sabe cuándo toca. Si al describir una skill necesitas la palabra «y» dos veces, probablemente sean dos skills.

La descripción es lo que más importa

De todo el archivo, el campo description es el que decide si la skill se usa o se queda muerta en la carpeta. No lo escribas para ti: escríbelo con las palabras que usará quien tenga el problema.

«`markdown

name: revisar-tono-marca description: > Revisa si un texto suena a nuestra marca antes de publicarlo. Úsala cuando pidan revisar copy, validar un texto, comprobar el tono, o antes de publicar cualquier pieza en redes, newsletter o web.

«`

Fíjate en que enumera formas distintas de pedir lo mismo: «revisar copy», «validar un texto», «comprobar el tono». Nadie pide las cosas con el nombre técnico del procedimiento.

Una descripción mala típica: *«Aplica las directrices editoriales del manual v3»*. Nadie va a escribir eso jamás.

Qué poner dentro

El cuerpo de la skill debe contener lo que un compañero nuevo necesitaría para hacerlo igual que vosotros. Sobre todo, lo que no es evidente.

«`markdown

Revisión de tono de marca

Cómo suena la marca

• Tuteo siempre, también en B2B.
• Frases cortas. Si una frase pasa de 25 palabras, pártela.
• Nada de superlativos («increíble», «revolucionario»).
• Números concretos antes que adjetivos: «baja un 30 %»,

no «baja muchísimo».

Prohibido

• Signos de exclamación en textos corporativos.
• «Solución» como sinónimo de producto.
• Emojis fuera de redes sociales.
• Anglicismos con equivalente claro: usa «público objetivo»,

no «target».

Cómo entregar la revisión

1. Señala cada problema con la frase original y la propuesta.
2. No reescribas la pieza entera: propón cambios puntuales.
3. Termina con un veredicto: publicable / retocar / rehacer.

«`

Compara eso con «revisa que el texto siga la guía de estilo». La segunda versión no sirve para nada porque no contiene la guía.

Organizar cuando ya sois varios

Cuando la carpeta la comparte un equipo aparecen tres problemas concretos.

Solapamiento. Dos skills que podrían activarse ante la misma petición. Se resuelve delimitando en la propia descripción: «Úsala para newsletter; para redes usa redactar-post».

Skills zombis. Nadie recuerda quién las creó ni si siguen valiendo. Se resuelve con una línea de mantenimiento en cada archivo:

«markdown <!-- Responsable: María · Última revisión: 2026-05 --> «

Sin responsable, nadie las actualiza. Con responsable, al menos hay a quién preguntar.

Deriva. La skill dice una cosa y el equipo hace otra. Suele pasar cuando cambia el proceso real y nadie actualiza el archivo. Revisión trimestral y fuera.

Qué merece ser skill y qué no

Una prueba sencilla: ¿lo haría igual otra persona del equipo sin preguntarte nada? Si la respuesta es no, es candidata a skill.

Sí merecen serlo:

• Procesos con pasos que la gente se salta (revisiones, comprobaciones previas a publicar).
• Criterios de marca que viven en la cabeza de una sola persona.
• Formatos de entrega concretos (cómo es un informe de cliente vuestro).
• Cualquier cosa que hayas explicado tres veces.

No merecen serlo:

• Tareas de una sola vez.
• Cosas que el modelo ya hace bien solo. Una skill que dice «escribe con buena ortografía» solo gasta contexto.
• Conocimiento que cambia cada semana; ahí es mejor un documento que se consulta.

Cómo empezar sin liarte

No diseñes el sistema entero de golpe. El camino que funciona:

1. Trabaja normal durante una semana y anota cada vez que expliques algo por segunda vez.
2. Convierte en skill lo que aparezca tres veces. Empezarás con dos o tres, no con quince.
3. Cuando una skill no se active aunque debía, arregla la descripción, no el cuerpo. Nueve de cada diez veces el problema está ahí.
4. Cuando se active de más, delimita en la descripción qué queda fuera.

Al cabo de un par de meses tendrás entre cinco y diez skills que se usan de verdad, que vale mucho más que treinta que nadie invoca.

Cómo saber si funciona

Tres señales de que el sistema está vivo:

• Gente nueva produce como los veteranos sin tutela. Es el objetivo real.
• Dejas de repetirte. Si sigues explicando lo mismo, falta una skill o su descripción está mal.
• Los resultados son consistentes entre personas distintas.

Y la señal de alarma: skills que llevan meses sin activarse. O están mal descritas, o resuelven un problema que ya no tenéis. En ambos casos, tócalas o bórralas.