Conceptos básicos de diseño y empaquetado de Skills

10 ejemplos para empezar con el diseño y empaquetado de Skills: 7 básicos y 3 intermedios.

Prerrequisitos

• Una tarea repetida que ya le pides a Claude que haga de la misma manera más de una vez: este es el material bruto, no una página en blanco.
• Un lugar para guardar una carpeta: un archivo SKILL.md y, opcionalmente, algunos archivos de soporte junto a él.
• Ningún software especial más allá de un editor de texto: SKILL.md es un archivo Markdown plano con un bloque YAML frontmatter en la parte superior.

Ejemplos básicos

1. El archivo SKILL.md mínimo viable

Cada Skill necesita exactamente dos cosas en su frontmatter: un name y una description.

---
name: pr-review-checklist
description: >-
  Reviews a pull request diff against a fixed checklist. Use when the user
  asks for a PR review, code review, or to check a diff before merging.
---

• name es un identificador corto en formato kebab-case para la carpeta y el archivo de la Skill.
• description es lo que Claude compara con una nueva tarea para decidir si esta Skill aplica; está haciendo más trabajo que cualquier otro campo.
• Todo lo que está debajo del frontmatter es el cuerpo de la instrucción que Claude sigue una vez que decide usar la Skill.
• Una Skill con solo estos dos campos más un cuerpo es un paquete completo y válido.

2. Declarar lo que hace la Skill

La primera mitad de una buena descripción nombra la tarea en términos concretos.

description: >-
  Summarizes a customer support transcript into a structured ticket:
  issue, steps taken, and resolution status.

• Nombra el resultado real, no una categoría vaga: "ticket estructurado" es mejor que "ayuda con soporte".
• Evita describir la Skill en términos que solo su autor reconocería; escríbelo como lo describiría un compañero de equipo.
• Esta mitad responde a "¿qué hace esto?", lo cual es necesario pero no suficiente por sí solo.
• Mantenlo en una o dos frases: una descripción es metadato, no documentación.

3. Declarar cuándo debe activarse la Skill

La segunda mitad nombra las situaciones que deben activar la Skill.

description: >-
  Summarizes a customer support transcript into a structured ticket. Use
  when the user pastes a support conversation or asks for a ticket summary.

• "Úsalo cuando..." es un patrón confiable y explícito para la mitad de activación de una descripción.
• Nombra las señales concretas que mostraría una tarea real: una transcripción pegada, una frase de solicitud específica, no una categoría abstracta.
• Una descripción que solo dice lo que hace la Skill, sin decir cuándo, es la razón más común por la que una Skill pasa desapercibida.
• Prueba la mitad de activación preguntando: ¿esta redacción también coincidiría con una tarea para la que la Skill NO está pensada?

Relacionado: Escribir una descripción de Skill eficaz que Claude activará - una inmersión completa en este campo exacto.

4. Escribir el primer paso numerado

Las instrucciones pertenecen al cuerpo como pasos ordenados, no como un párrafo largo.

## Instructions
 
1. Lee la transcripción completa proporcionada por el usuario.
2. Identifica el problema principal del cliente en una frase.
3. Enumera los pasos de solución de problemas ya intentados, en orden.

• La numeración te obliga a decidir el orden real de las operaciones, algo que puedes omitir en prosa suelta.
• Cada paso debe ser realizable por sí solo, sin necesidad de releer todo el párrafo para saber qué hacer a continuación.
• Los pasos cortos y específicos son más fáciles de seguir para Claude de la misma manera cada vez que un párrafo denso único.
• Redacta los pasos primero en lenguaje claro; puedes ajustar la redacción una vez que el orden sea correcto.

5. Terminar la lista de pasos

Una lista de pasos útil termina con una salida concreta, no con un resumen vago.

4. Anota el estado actual de la resolución: abierto, pendiente o resuelto.
5. Muestra los cuatro campos anteriores como un resumen estructurado corto.

• El último paso debe describir exactamente lo que se produce, para que no haya ambigüedad sobre cuándo la Skill está "terminada".
• Evita pasos finales abiertos como "concluye apropiadamente" - invitan a resultados inconsistentes entre ejecuciones.
• Una lista de pasos con un final claro también es más fácil de probar: sabes cómo se ve una ejecución correcta.
• Cinco pasos es un tamaño razonable para una primera Skill; las tareas más largas pueden tener más, pero cada una aún debe ser una acción única y concreta.

6. Elegir un nivel (tarea básica vs. avanzada)

No todas las Skills necesitan maquinaria adicional; la mayoría empieza de forma sencilla.

---
name: weekly-status-draft
description: >-
  Drafts a weekly status update from raw meeting notes or bullet points.
  Use when the user asks for a status update, recap, or standup summary.
---
## Instructions
1. Read the raw notes or bullet points provided.
2. Group items into: shipped, in progress, blocked.
3. Draft three to five sentences per group.

• Una Skill con solo frontmatter y una lista numerada corta es un paquete completo; no necesitas allowed-tools ni archivos empaquetados para empezar.
• Añade complejidad solo cuando la tarea realmente lo requiera, no por defecto.
• Esta es la forma que deberían tener la mayoría de las primeras Skills: dos campos de frontmatter y un puñado de pasos.
• Siempre puedes añadir alcance o recursos empaquetados más tarde sin reescribir lo que ya funciona.

7. Guardar el paquete como una carpeta

Una Skill vive en su propia carpeta, nombrada para que coincida con su campo name.

pr-review-checklist/
  SKILL.md

• El nombre de la carpeta y el campo name deben coincidir, para que el paquete sea fácil de identificar de un vistazo.
• Una Skill de un solo archivo, solo SKILL.md en su propia carpeta, es un paquete normal y terminado, no uno incompleto.
• No se requiere nada más hasta que una tarea necesite genuinamente archivos de referencia empaquetados, scripts o alcance de herramientas.
• Este es el punto en el que "idea" se ha convertido en "paquete": la carpeta está completa y lista para ser probada contra una tarea real.

Ejemplos intermedios

8. Probar el disparador antes de confiar en la salida

Antes de depender de una nueva Skill, comprueba que se activa en las tareas correctas y permanece en silencio en las incorrectas.

Prueba 1 (debería activarse):
  "Aquí está la transcripción de la llamada con el cliente, ¿puedes
  resumirla en un ticket?"
 
Prueba 2 (NO debería activarse):
  "¿Puedes resumirme este artículo de noticias?"

• Ejecuta al menos una tarea que esperas que active la Skill y otra que esperas que no, y confirma que Claude toma la decisión correcta en ambos casos.
• Una Skill que produce un gran resultado una vez invocada solo está medio terminada si también se dispara en tareas no relacionadas, o nunca se dispara.
• Si la Prueba 2 activa accidentalmente la Skill, la descripción es demasiado amplia y necesita un lenguaje de activación más específico y conciso.
• Si la Prueba 1 no se activa, es probable que la descripción no declare el "cuándo" con suficiente claridad, incluso si el "qué" es preciso.

Relacionado: Errores comunes que dificultan que Claude encuentre o use una Skill - una lista más completa de fallos de activación a comprobar.

9. Revisar una descripción después de un disparador perdido

Cuando una Skill no se activa en una tarea que debería haberlo hecho, la solución casi siempre está en la descripción, no en las instrucciones.

# Before: too abstract to match real phrasing
description: >-
  Helps with support tickets.
 
# After: concrete outputs and concrete trigger language
description: >-
  Summarizes a customer support transcript into a structured ticket with
  issue, steps taken, and resolution status. Use when the user pastes a
  support conversation or asks to turn a conversation into a ticket.

• Compara la redacción exacta de la solicitud perdida con la descripción: la brecha suele señalar directamente la solución.
• Ampliar ligeramente una descripción suele ser más seguro que reescribirla desde cero, ya que las partes que funcionan permanecen intactas.
• Mantén un registro corto de disparadores perdidos o falsos mientras refinas una nueva Skill: los patrones aparecen más rápido que las correcciones puntuales.
• Una descripción nunca está realmente "terminada" la primera vez; espera al menos una revisión después del uso real.

10. Combinar dos tareas relacionadas en una sola Skill

Cuando dos tareas comparten la mayoría de sus pasos, una Skill con una rama suele ser mejor que dos paquetes separados.

## Instructions
1. Lee las notas proporcionadas.
2. Si las notas son de una sola reunión, redacta una actualización de estado
   (ver paso 3a).
3a. Agrupa en enviados, en progreso, bloqueados; redacta 3-5 frases por grupo.
3b. Si las notas abarcan una semana completa en múltiples reuniones, redacta un
    resumen semanal en su lugar: un párrafo por proyecto, ordenado por prioridad.

• Una sola Skill con ramificación es más fácil de descubrir y mantener que dos Skills con descripciones casi idénticas compitiendo por el mismo disparador.
• Las ramas deben basarse en algo concretamente detectable en la entrada, como "reunión única" vs. "abarca una semana", no en una llamada subjetiva.
• Si las ramas divergen genuinamente en la mayoría de sus pasos en lugar de solo en el final, eso es una señal de que deberían ser Skills separadas después de todo.
• Este patrón escala: una Skill bien organizada puede contener algunas ramas estrechamente relacionadas sin volverse poco clara sobre cuándo aplica cada una.

Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026: Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5. Los nombres de los modelos, los precios y las características del producto cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.