Claude Code Skills: La Capa Profesional que la Mayoría Ignora

Ya estás en Claude Code. Conoces lo básico. Has visto lo que puede hacer. Pero cada nueva sesión empieza igual: los primeros cinco minutos los pasas reexplicando tu contexto, reescribiendo los prompts que has escrito cien veces, y reestableciendo las reglas del juego antes de que empiece el trabajo real.

Esa fricción no es un problema de Claude. Es un problema de infraestructura. Y la solución es una funcionalidad que la mayoría de los usuarios pasa de largo: los Skills.

Esta es la capa profesional. El punto donde Claude Code deja de ser una interfaz de chat poderosa y empieza a ser un sistema que tú mismo construiste.

Ilustración dividida: lado izquierdo muestra un desarrollador frente a una terminal de Claude Code en blanco, reescribiendo notas de contexto. Lado derecho muestra al mismo desarrollador con una terminal limpia y skills cargándose automáticamente — carpetas organizadas, contexto instantáneo, sin fricción de configuración.

Cada sesión desde cero vs. un sistema que recuerda. La diferencia es infraestructura.


1. Skills vs. Slash Commands: Aclarando la Confusión

Antes de construir nada, entiende con qué estás trabajando. La terminología ha cambiado.

El formato original era .claude/commands/ — archivos markdown que se convertían en slash commands. Ese formato todavía funciona. Pero es legacy. El estándar actual es .claude/skills/<nombre-del-skill>/SKILL.md. Los Skills soportan todo lo que hacían los commands, más invocación autónoma (Claude puede activarlos sin que escribas /), archivos de soporte (scripts, referencias, plantillas), y control más granular sobre qué puede hacer el skill.

[!info] Skills de Proyecto vs. Skills Personales Los skills en .claude/skills/ dentro de tu repo aplican solo a ese proyecto — y se commitean a git, lo que significa que todo tu equipo los recibe. Los skills en ~/.claude/skills/ son globales. Te siguen en cada proyecto de tu máquina. Elige según si el flujo de trabajo es tuyo solo o pertenece al equipo.

Cuando escribes /nombre-del-skill, Claude carga ese skill y sigue sus instrucciones. Cuando no escribes nada, Claude aún puede decidir cargar un skill relevante automáticamente — eso es lo que el formato .claude/commands/ no podía hacer.

Diagrama de árbol de archivos lado a lado: izquierda muestra la carpeta legacy .claude/commands/ con archivos markdown planos. Derecha muestra la carpeta moderna .claude/skills/ con subcarpetas nombradas, cada una con un SKILL.md y archivos de soporte opcionales — visualmente más estructurado y capaz.

Commands legacy vs. el formato de skills. La misma idea, fundamentalmente más poderosa.

Para el resto de este artículo, construimos en el formato de skills.


2. Para Qué Usan los Skills los Profesionales de Verdad

La comunidad alrededor de Claude Code ha estado construyendo y compartiendo skills desde que se lanzó el formato. El repo awesome-claude-code es la señal más clara de lo que la gente más utiliza. Tres patrones dominan: automatización de flujos de trabajo, control de calidad, y cebado de contexto.

Así se ve en la práctica por disciplina.

Desarrolladores

Los skills de desarrollador más populares codifican los pasos que sigues cada vez, sin pensar — pero que igual requieren esfuerzo hacerlos bien.

/commit — Lee git status y git diff, analiza qué cambió, escribe un mensaje de commit estructurado siguiendo tus convenciones. La versión incluida en Claude Code lo hace bien. La mayoría de los desarrolladores que construyen la propia la extienden con reglas específicas del proyecto (formato de mensaje, actualizaciones de changelog, linkeo de tickets Jira).

/review — Lanza agentes de revisión en paralelo para calidad de código, seguridad y eficiencia. El comando /simplify incluido hace una versión de esto. Los skills de revisión personalizados van más lejos: verifican anti-patrones específicos de tu equipo, hacen cumplir decisiones de arquitectura, marcan cobertura de tests faltante.

/security-scan — Ejecuta una revisión de vulnerabilidades estructurada sobre los archivos modificados. Vale la pena bloquearlo a model: claude-opus-4-6 (más sobre eso abajo) porque la profundidad de razonamiento importa aquí.

/test-gen — Toma una función o componente y genera casos de prueba siguiendo tu framework y convenciones. Ahorra 20 minutos por feature. Escala al tamaño de tu codebase.

Marketers

El marketing es el nicho donde los skills tienen el retorno más rápido porque el trabajo es profundamente repetitivo: mismas estructuras, contenido diferente, todos los días.

/email-draft — Toma un brief de campaña (objetivo, audiencia, CTA) y produce un email completo en tu voz de marca. El skill guarda las guías de voz para que no tengas que pegarlas cada vez.

/meta-seo — Toma una URL o título de página y genera title tags, meta descriptions y copy de Open Graph dentro de los límites de caracteres. Trabajo mecánico que desaparece en segundos.

/ad-variations — Toma un concepto y produce variaciones de copy para diferentes formatos (feed, stories, search), diferentes audiencias y distintos ángulos emocionales. Útil para A/B testing sin empezar desde una página en blanco cada vez.

/market-response — Más sofisticado. Simula cómo diferentes segmentos de clientes responderían a una campaña, cambio de precio o anuncio de producto. Más cercano a la planificación de escenarios que al copywriting, pero se ha convertido en un skill estándar para equipos enfocados en growth.

Diseñadores UX

Para diseñadores, los skills de mayor valor son los que eliminan la brecha entre una sesión de investigación y un documento accionable.

/research-synthesis — Toma notas brutas de entrevistas o bullets de observación y devuelve insights estructurados: temas, tensiones, áreas de oportunidad y la cita clave que prueba cada punto. El output está listo para presentación.

/microcopy — Toma un estado de UI (estado vacío, mensaje de error, paso de onboarding, diálogo de confirmación) y genera variaciones de copy con el razonamiento detrás de cada una. Incluye coincidencia de tono, control de extensión y frases amigables para accesibilidad.

/decision-doc — Documenta una decisión de diseño en formato estructurado: qué se decidió, qué alternativas se consideraron, qué evidencia respalda la elección y qué tendría que cambiar para revisarla. Los ingenieros lo leen. Los stakeholders lo leen. Tú del futuro lo lee seis meses después.

/accessibility-audit — Revisa una descripción de componente o spec de Figma para detectar problemas de cumplimiento WCAG antes de que nada llegue a ingeniería. Detecta problemas en el momento correcto.

Visual de tres columnas mostrando los principales skills por nicho profesional. Columna izquierda: Desarrolladores — commit, review, security-scan, test-gen. Columna central: Marketers — email-draft, meta-seo, ad-variations, market-response. Columna derecha: Diseñadores UX — research-synthesis, microcopy, decision-doc, accessibility-audit. Diseño de tarjetas limpias con íconos para cada nicho.

Los skills que los profesionales construyen primero, según disciplina.


3. Cómo Construir Tu Primer Skill Usando el Propio Claude

Aquí está la parte que la mayoría de tutoriales omite: no tienes que escribir skills desde cero. Claude puede construirlos por ti.

El proceso son tres pasos.

Paso 1: Describe el flujo de trabajo

Dile a Claude qué haces repetidamente. Sé específico sobre inputs, outputs y cualquier regla que sigas. No seas abstracto.

“Necesito un skill que tome notas de entrevistas de usuarios como input. Debe identificar los 3-5 temas principales, extraer una cita de soporte por tema, y marcar la mayor tensión o contradicción en los datos. El output debe estar estructurado con encabezados claros. Que no supere las 500 palabras.”

Paso 2: Pídele a Claude que genere el archivo del skill

Basándote en ese flujo de trabajo, genera un archivo SKILL.md que pueda colocar en ~/.claude/skills/research-synthesis/.
Incluye frontmatter YAML apropiado con name, description y allowed-tools.
El skill solo necesita acceso Read — sin escritura de archivos.

Claude generará un archivo completo. Revísalo. Las instrucciones en el cuerpo markdown son el prompt que Claude seguirá cuando invoques el skill — léelas como un prompt y edita lo que no coincida con cómo trabajas realmente.

Paso 3: Coloca el archivo y pruébalo

mkdir -p ~/.claude/skills/research-synthesis
# pega el archivo que Claude generó

Escribe /research-synthesis en tu próxima sesión de Claude Code. Pega algunas notas. Ve qué devuelve. Itera sobre las instrucciones en SKILL.md hasta que el output coincida con lo que tú mismo producirías.

[!important] El Loop de Iteración Tu primer skill no será tu mejor skill. Las instrucciones en SKILL.md son un prompt — trátalo como tal. Ejecútalo sobre inputs reales, identifica dónde el output falla, y ajusta el lenguaje. Tres rondas de iteración usualmente producen algo que usarías todos los días.

El repo de skills de Anthropic mantiene un skill llamado skill-creator específicamente para este propósito. Es un meta-skill que te ayuda a estructurar nuevos skills con el formato correcto de frontmatter y buenos patrones de instrucción. Vale la pena instalarlo antes de construir cualquier cosa personalizada.


4. Especificando Modelos Dentro de los Skills

No cada tarea merece tu modelo más poderoso. Correr Claude Opus en una tarea que Haiku maneja perfectamente desperdicia tokens y enlentece las cosas. Los skills te permiten especificar el modelo en el frontmatter — lo que significa que puedes enrutar de forma inteligente por defecto sin pensarlo en tiempo de ejecución.

---
name: security-scan
description: Ejecuta un análisis estructurado de vulnerabilidades de seguridad sobre los archivos modificados. Usar al revisar PRs o antes de desplegar.
model: claude-opus-4-6
allowed-tools: Read, Glob, Grep
---
---
name: meta-seo
description: Genera metadata SEO (title, description, OG) para una página. Usar al publicar o actualizar contenido.
model: claude-haiku-4-5-20251001
allowed-tools: Read
---

La lógica para elegir:

  • Opus para tareas que requieren razonamiento multi-paso, análisis de seguridad, revisión de arquitectura, o síntesis de información ambigua donde las respuestas incorrectas tienen costos reales.
  • Sonnet para tareas que requieren buena calidad de output pero con menos riesgo — redacción de contenido, generación de código, síntesis de investigación.
  • Haiku para tareas mecánicas con estructura clara — generación de metadata, formateo, variaciones de copy, mensajes de commit.

[!danger] El Costo Oculto de Ignorar Esto Si no especificas un modelo, Claude Code usa cualquiera que sea el default de la sesión. En sesiones largas, eso suele ser Sonnet u Opus. Correr generación de metadata por Opus 100 veces al mes es dinero real por una calidad de output que obtendrías de Haiku. El enrutamiento de modelos en skills es la optimización de costos de mayor apalancamiento disponible.

Diagrama de árbol de decisión para selección de modelo en skills. Nodo superior: '¿Qué tipo de tarea?' Tres ramas: 'Razonamiento multi-paso / seguridad / análisis ambiguo' → Opus (ícono de engranaje pesado). 'Generación de contenido / código / síntesis' → Sonnet (engranaje mediano). 'Mecánico / estructurado / formateo' → Haiku (ícono de rayo ligero). Cada rama incluye un nombre de skill de ejemplo.

Ajusta el modelo a la tarea. La diferencia de costo se acumula rápido.


5. No Pierdas Tus Skills Nunca Más: Estrategias de Backup

Tus skills globales viven en ~/.claude/skills/. Formatea tu computadora, y desaparecen. Este es un problema que la mayoría descubre solo una vez.

Hay tres enfoques, ordenados por confiabilidad.

Opción 1: Repo de dotfiles (recomendado)

Crea un repositorio dotfiles en GitHub. Commitea tu directorio ~/.claude/skills/ en él. Cuando configures una nueva máquina, clona el repo y ejecuta un script de configuración que cree un symlink de la carpeta de skills de vuelta a ~/.claude/skills/.

# En tu repo de dotfiles
ln -s ~/dotfiles/.claude/skills ~/.claude/skills

Esto te da control de versiones, historial y sincronización entre máquinas. Si rompes una actualización de skill, puedes revertir. Si agregas un skill en tu máquina de trabajo, puedes jalarlo a tu máquina personal.

Opción 2: Carpeta sincronizada en la nube

Mueve tu directorio ~/.claude/ a una ubicación sincronizada (iCloud, Dropbox o similar) y crea un symlink de vuelta. Esto sincroniza automáticamente sin commits manuales.

mv ~/.claude ~/Dropbox/.claude
ln -s ~/Dropbox/.claude ~/.claude

Más simple de configurar. Menos control de versiones. Funciona bien si estás en una o dos máquinas.

Opción 3: Mantén todo en repos de proyecto

Si la mayoría de tus skills son específicos del proyecto, mantenlos en .claude/skills/ dentro del proyecto. Ya viven en git. La contrapartida es que estos skills no te siguen fuera de ese proyecto — pero para flujos de trabajo de equipo, eso es exactamente lo que quieres.

[!quote] “Un skill que no puedes restaurar después de una instalación limpia no es un activo profesional. Es una nota que reescribirás de memoria.”

La recomendación práctica: usa el repo de dotfiles para skills globales personales, y .claude/skills/ del proyecto para flujos de trabajo compartidos del equipo. Deja que git maneje ambos.


6. Seguridad: Lo Que Debes Saber Antes de que Tus Skills Vayan a Cualquier Parte

Los skills son archivos de texto. Esa es su fortaleza — fáciles de leer, fáciles de editar, fáciles de compartir. También es donde ocurren la mayoría de los errores de seguridad.

Nunca pongas credenciales en archivos de skill

Esto suena obvio. No lo es. Los skills frecuentemente necesitan interactuar con servicios externos — Jira, Notion, Slack, APIs de analytics. La tentación es hardcodear la API key directamente en el SKILL.md para que el skill “simplemente funcione.”

No lo hagas. Cualquier skill en una carpeta .claude/skills/ de proyecto se commitea a git. Cualquiera con acceso al repo puede leerlo. Cualquiera que haga fork del repo lo obtiene.

Usa variables de entorno en su lugar. Referencialas como $JIRA_API_KEY en tus instrucciones del skill y establécelas en tu perfil de shell o .env (gitignoreado). El skill se mantiene limpio; las credenciales se quedan donde pertenecen.

Bloquea los skills a lo que realmente necesitan

El campo allowed-tools restringe lo que un skill puede hacer. Un skill de generación de contenido que solo necesita escribir a un archivo no necesita acceso a Bash. Un skill de síntesis de investigación que solo lee notas no necesita Write.

---
name: research-synthesis
description: Sintetiza notas de entrevistas de usuarios en insights estructurados.
allowed-tools: Read
---

Bloquear las herramientas sigue el principio de mínimo privilegio. También te protege de construir accidentalmente un skill que puede ejecutar comandos de shell cuando solo quisiste que analizara texto.

Los skills de proyecto son visibles para todo tu equipo — planifica en consecuencia

Cuando commiteas un skill a un repo de proyecto, cada colaborador lo recibe. Eso es el punto para skills de flujo de trabajo. Pero si un skill contiene lógica de prompting sensible al negocio — posicionamiento competitivo, supuestos de precios, terminología interna — trátalo con el mismo proceso de revisión que darías a cualquier otro archivo commiteado.

Algunos equipos mantienen un subdirectorio /private/ en .claude/skills/ que está gitignoreado, para skills que contienen instrucciones sensibles. Otros mantienen skills sensibles en el ~/.claude/skills/ global para que nunca toquen el repo.

Piensa en lo que pasa a través del skill

Cuando un skill se ejecuta, Claude ve lo que sea que le pases — notas, documentos, código, datos. Si corres un skill /research-synthesis sobre transcripciones de entrevistas que contienen PII, estás enviando esos datos por la API. La mayoría de las organizaciones que usan Claude Code vía API están cubiertas por los acuerdos de manejo de datos de Anthropic, pero conoce tu contexto. No pases datos confidenciales de clientes por un skill construido sobre una cuenta personal sin acuerdo de procesamiento de datos vigente.

[!warning] Skills en Repos Públicos Algunas librerías de skills de la comunidad son repos públicos. Si haces fork de una y le agregas tus propios skills, ten cuidado con lo que commiteas antes de hacer push de vuelta al origin. Un simple git status antes de hacer push no es opcional — es el hábito que previene el tipo embarazoso de filtración.

Diagrama de dos caminos mostrando el manejo de credenciales en skills. Camino malo (rojo): API key hardcodeada directamente dentro del SKILL.md → commiteada a git → visible en el historial del repo → expuesta. Camino bueno (verde): API key guardada en archivo .env (gitignoreado) → referenciada como $ENV_VAR en SKILL.md → el skill lee la variable de entorno en tiempo de ejecución → la clave nunca toca git. Estilo de diagrama de flujo limpio y simple.

Hardcodeado vs. variable de entorno. Un camino lleva a una mañana muy mala.


7. El Stack de Skills que Vale la Pena Construir Primero

Si estás partiendo desde cero, construye estos cuatro antes que cualquier otra cosa.

  1. Un skill de commit — Lee tu diff, escribe un mensaje de commit siguiendo tus convenciones. Ahorra 3 minutos en cada commit. El tipo de ahorro de tiempo que se acumula.

  2. Un skill de cebado de contexto — Carga el contexto clave de tu proyecto (decisiones de arquitectura, convenciones de nombres, objetivos del sprint actual) al inicio de una sesión. disable-model-invocation: false para que Claude pueda cargarlo automáticamente cuando sea relevante.

  3. Un skill de escritura — Si produces contenido, sé dueño de la voz. Un solo skill que contenga tus guías de voz de marca, frases prohibidas y formato de output elimina la reexplicación cada vez.

  4. Un skill de revisión — Lo que sea que revisas repetidamente (código, copy, diseños, briefs) merece un skill estructurado. Define qué verificas. Deja que el skill corra el checklist para que puedas enfocarte en el juicio, no en el proceso.

Estos cuatro cubren la mayor parte de lo que la gente pierde tiempo reconstruyendo en sesiones. Todo lo demás es especialización.


Construye Tu Primer Skill Esta Semana

La brecha entre los usuarios de Claude Code y los profesionales de Claude Code no es talento. Es infraestructura.

Los profesionales no empiezan cada sesión desde una pizarra en blanco. Han construido el sistema: skills que codifican sus flujos de trabajo, modelos ajustados a la complejidad de cada tarea, archivos respaldados y con control de versiones, y permisos acotados a lo que cada skill realmente necesita.

Elige un flujo de trabajo que hagas más de tres veces a la semana. Descríbelo a Claude. Pídele que genere un SKILL.md para él. Coloca el archivo en ~/.claude/skills/ y pruébalo contra un input real antes de que termine esta semana.

El primer skill es el más difícil. Después de eso, el sistema se construye solo.


Recursos mencionados en este artículo: