La Pregunta Que Ningún Manual de Marca Responde
Hace tres meses, un diseñador junior en un equipo que conozco tardó 4 días en crear un post para redes sociales.
No porque no supiera diseñar.
Sino porque pasó 3 días buscando:
- El tono de voz correcto en 47 páginas de brand guidelines
- Los colores exactos entre 3 PDFs diferentes
- Si podía usar emojis (spoiler: había una regla específica enterrada en la página 23)
- Qué claims legales necesitaba incluir
El conocimiento existía. Pero estaba muerto.
Viví en documentos que nadie abre hasta que algo sale mal.
Skills: Cuando el Conocimiento Se Ejecuta, No Se Lee
Claude Skills no son otra herramienta de documentación.
Son una forma de empaquetar el conocimiento institucional como código ejecutable.
La diferencia es brutal:
Documentación tradicional:
- Escribes: "Nuestro tono es profesional pero cercano"
- El junior interpreta su versión de "cercano"
- Revisas, corriges, explicas
- Repites esto con cada persona nueva
Con Skills:
- Codificas: El prompt exacto que genera el tono correcto
- Cualquiera en el equipo lo ejecuta
- El output es consistente desde el primer día
- El conocimiento está vivo, no archivado
Qué Puedes Capturar en un Skill
Lo interesante de Skills es que funcionan para conocimiento que pensabas que era "demasiado específico" para automatizar:
1. Voz de Marca
```yaml name: "Brand Voice - Análisis Financiero" context: | Escribes para CFOs y Controllers en España. Nivel de formalidad: Profesional pero directo. NUNCA uses: "innovador", "disruptivo", "sinergia". SIEMPRE: Datos primero, interpretación después. Referencias culturales: OK mencionar regulaciones españolas.
instructions: | 1. Abre con el insight más relevante (no contexto) 2. Usa bullets para datos, párrafos para análisis 3. Incluye SIEMPRE la fuente de los datos 4. Termina con una pregunta que invite a la reflexión ```
Esto no es un "guideline". Es una máquina de generar contenido consistente.
2. Compliance y Legal
Un Skill puede empaquetar todas tus requirements legales:
```yaml name: "Legal Review - Marketing Copy" checklist: | - ¿Incluye disclaimer sobre rendimientos pasados? - ¿Menciona riesgos si habla de inversión? - ¿Cumple GDPR si menciona datos? - ¿Usa términos que requieren licencia financiera?
autocorrect: | Si detectas claims absolutos ("garantizado", "seguro", "siempre"), reformula en términos probabilísticos o elimina. ```
El junior ya no puede olvidar el disclaimer. El Skill lo fuerza.
3. Workflows de QA
Mira este Skill para revisar PRs:
```yaml name: "Code Review - Next.js Apps" context: | Revisas PRs en proyectos Next.js 14+ con App Router. Usamos Supabase para auth, Vercel para deploy.
checklist: | ## Performance - ¿Usa dynamic imports para components pesados? - ¿Las imágenes usan next/image con sizes? - ¿Los fetches usan cache tags apropiados?
## Seguridad - ¿Valida inputs del usuario? - ¿Usa RLS en Supabase? - ¿Expone credenciales en el código?
## Standards - ¿Sigue naming conventions del proyecto? - ¿Tests para lógica de negocio? ```
Este Skill captura lo que un tech lead repetiría 50 veces al año.
El Patrón Que Hace Skills Útiles
Después de crear varios Skills, he notado un patrón:
Los buenos Skills no son genéricos.
No escribes "sé profesional". Escribes:
``` NUNCA uses pronombres de segunda persona. Dirígete al lector como "el CFO" o "el equipo financiero". Si mencionas una métrica, incluye periodo y fuente: ✓ "En Q1 2024, según datos de Banco de España..." ✗ "Los datos muestran que..." ```
La especificidad es lo que hace que funcione.
Cómo Empezar a Capturar Conocimiento
1. Identifica lo que explicas repetidamente
¿Qué preguntas contestas una y otra vez?
- "¿Cómo escribimos los titles para SEO?"
- "¿Qué estructura usamos para emails de onboarding?"
- "¿Cómo revisamos código antes de mergear?"
Esas son tus primeras Skills.
2. Convierte explicaciones en instrucciones
No escribas *sobre* el proceso. Escribe *el proceso* como lo ejecutarías:
Mal: "Nuestros emails son claros y accionables."
Bien: ``` 1. Subject line: 40 caracteres máx, incluye beneficio específico 2. Párrafo 1: Un solo problema, en una frase 3. Párrafo 2: Cómo tu producto lo resuelve 4. CTA: Un solo botón, texto accionable (no "Leer más") ```
3. Testa con gente nueva
La mejor validación de un Skill:
Dáselo a alguien que nunca ha hecho esa tarea.
¿Puede ejecutarlo sin hacerte preguntas?
Si sí → el Skill funciona. Si no → le falta especificidad.
El Shift Mental
Skills cambian cómo piensas sobre el conocimiento de empresa:
Antes: "Necesitamos mejor onboarding para explicar nuestros procesos."
Ahora: "¿Qué procesos podemos codificar para que no requieran explicación?"
No se trata de reemplazar humanos.
Se trata de liberar el cerebro de tu equipo para problemas que sí requieren pensamiento original.
Lo Que Estoy Construyendo Con Esto
Estoy convirtiendo los procesos de mis proyectos en Skills:
- Cómo escribo posts técnicos (estructura, voz, links)
- Cómo valido ideas antes de construir (checklist de CENTS)
- Cómo optimizo para SEO local (patterns que funcionan)
Cada Skill es conocimiento que antes vivía solo en mi cabeza.
Ahora cualquiera (o cualquier AI) puede ejecutarlo.
El Takeaway
Skills no son documentación 2.0.
Son conocimiento institucional como código.
Y como todo código: puedes versionarlo, testearlo, mejorarlo, y compartirlo.
La pregunta no es "¿necesitamos más documentación?"
Es: "¿Qué conocimiento podemos ejecutar en lugar de explicar?"
Empieza con uno. El proceso que explicas más veces al mes.
Conviértelo en un Skill.
Y mira cuánto tiempo recuperas.
