Modificado para DeepSeek Harness. Original: Anthropic's skill-creator (Apache-2.0, véase LICENSE.txt).

¿Qué hace Creador de Skills?

Una skill para crear nuevas skills y mejorarlas de forma iterativa.

A alto nivel, el proceso de creación de una skill es el siguiente:

Decide qué quieres que haga la skill y aproximadamente cómo debería hacerlo
Redacta un borrador de la skill
Crea algunas indicaciones de prueba y ejecuta el modelo con la skill instalada
Ayuda al usuario a evaluar los resultados tanto cualitativa como cuantitativamente
- Mientras se ejecutan las pruebas en segundo plano, redacta algunas evaluaciones cuantitativas si no las hay (si las hay, puedes usarlas tal cual o modificarlas si crees que algo necesita cambiar). Luego explícalas al usuario (o si ya existían, explica las que existen)
- Usa el script eval-viewer/generate_review.py para mostrar los resultados al usuario para que los examine, y también permítele ver las métricas cuantitativas
Reescribe la skill basándote en los comentarios de la evaluación del usuario sobre los resultados (y también si hay fallos evidentes que se hacen patentes en los benchmarks cuantitativos)
Repite hasta que estés satisfecho
Amplía el conjunto de pruebas y vuelve a intentarlo a mayor escala

Tu trabajo al usar esta skill es averiguar en qué punto del proceso se encuentra el usuario y luego intervenir y ayudarlo a avanzar a través de estas etapas. Por ejemplo, tal vez el usuario diga "Quiero hacer una skill para X". Puedes ayudar a precisar lo que quiere decir, redactar un borrador, escribir los casos de prueba, determinar cómo quiere evaluar, ejecutar todas las indicaciones y repetir.

Por otro lado, tal vez ya tengan un borrador de la skill. En ese caso, puedes ir directamente a la parte de evaluación/iteración del ciclo.

Por supuesto, siempre debes ser flexible y si el usuario dice "No necesito ejecutar un montón de evaluaciones, solo hazlo conmigo", puedes hacerlo.

Luego, una vez que la skill esté terminada (pero, de nuevo, el orden es flexible), también puedes ejecutar el mejorador de descripción de skills, para lo cual tenemos un script separado, para optimizar la activación de la skill.

¿Bien? Bien.

Comunicación con el usuario

Es probable que el creador de skills sea utilizado por personas con una amplia gama de familiaridad con la jerga de programación. Si no lo has oído (y ¿cómo podrías, si es algo muy reciente?), hay una tendencia ahora en la que el poder de DSH está inspirando a fontaneros a abrir sus terminales, padres y abuelos a buscar en Google "cómo instalar npm". Por otro lado, la mayoría de los usuarios probablemente tengan un nivel razonable de conocimientos informáticos.

¡Así que presta atención a las señales de contexto para saber cómo expresar tu comunicación! En el caso predeterminado, solo para darte una idea:

"evaluación" y "benchmark" están en el límite, pero están bien
para "JSON" y "aserción" debes ver señales claras del usuario de que sabe lo que son antes de usarlos sin explicarlos

Está bien explicar brevemente los términos si tienes dudas, y no dudes en aclarar términos con una definición corta si no estás seguro de que el usuario lo entienda.

Creación de una skill

Capturar la intención

Comienza por comprender la intención del usuario. La conversación actual podría contener ya un flujo de trabajo que el usuario quiera capturar (por ejemplo, dice "convierte esto en una skill"). Si es así, extrae las respuestas del historial de la conversación primero: las herramientas utilizadas, la secuencia de pasos, las correcciones que hizo el usuario, los formatos de entrada/salida observados. Es posible que el usuario necesite completar los vacíos, y debe confirmar antes de pasar al siguiente paso.

¿Qué debería permitir hacer esta skill a DSH?
¿Cuándo debería activarse esta skill? (qué frases/contextos del usuario)
¿Cuál es el formato de salida esperado?
¿Debemos configurar casos de prueba para verificar que la skill funciona? Las skills con salidas objetivamente verificables (transformaciones de archivos, extracción de datos, generación de código, pasos de flujo de trabajo fijos) se benefician de los casos de prueba. Las skills con salidas subjetivas (estilo de escritura, arte) a menudo no los necesitan. Sugiere el valor predeterminado apropiado según el tipo de skill, pero deja que el usuario decida.

Entrevista e investigación

Haz preguntas de manera proactiva sobre casos extremos, formatos de entrada/salida, archivos de ejemplo, criterios de éxito y dependencias. Espera a escribir las indicaciones de prueba hasta que tengas esta parte resuelta.

Verifica los MCPs disponibles; si son útiles para la investigación (buscar documentación, encontrar skills similares, consultar mejores prácticas), investiga en paralelo a través de subagentes si están disponibles, o en línea de lo contrario. Llega preparado con contexto para reducir la carga sobre el usuario.

Escribe el SKILL.md

Basándote en la entrevista con el usuario, completa estos componentes:

name: Identificador de la skill
description: Cuándo activarse, qué hace. Este es el mecanismo de activación principal: incluye tanto lo que hace la skill como los contextos específicos para usarla. Toda la información de "cuándo usar" va aquí, no en el cuerpo. Nota: actualmente el modelo tiene tendencia a "subactivar" las skills, es decir, a no usarlas cuando serían útiles. Para combatir esto, haz que las descripciones de las skills sean un poco "insistentes". Por ejemplo, en lugar de "Cómo construir un panel simple y rápido para mostrar datos internos de la empresa", podrías escribir "Cómo construir un panel simple y rápido para mostrar datos internos de la empresa. Asegúrate de usar esta skill siempre que el usuario mencione paneles, visualización de datos, métricas internas, o quiera mostrar cualquier tipo de datos de la empresa, incluso si no pide explícitamente un 'panel'."
whenToUse / metadata / disable-model-invocation / user-invocable: las claves frontmatter opcionales que DSH reconoce. DSH lee name, description, whenToUse, metadata, disable-model-invocation y user-invocable del frontmatter; pon cualquier otra cosa que quieras registrar (una licencia, una versión) bajo metadata en lugar de como una clave de nivel superior.
el resto de la skill :)

Guía de escritura de skills

Anatomía de una skill

nombre-de-la-skill/
├── SKILL.md (obligatorio)
│   ├── Frontmatter YAML (name y description obligatorios)
│   └── Instrucciones en Markdown
└── Recursos empaquetados (opcional)
    ├── scripts/    - Código ejecutable para tareas deterministas/repetitivas
    ├── references/ - Documentos cargados en el contexto según sea necesario
    └── assets/     - Archivos utilizados en la salida (plantillas, iconos, fuentes)

Divulgación progresiva

Las skills utilizan un sistema de carga de tres niveles:

Metadatos (nombre + descripción) - Siempre en contexto (~100 palabras)
Cuerpo de SKILL.md - En contexto siempre que se activa la skill (<500 líneas idealmente)
Recursos empaquetados - Según sea necesario (ilimitado, los scripts pueden ejecutarse sin cargarse)

Estos recuentos de palabras son aproximados y puedes sentirte libre de alargarlos si es necesario.

Patrones clave:

Mantén SKILL.md por debajo de 500 líneas; si te acercas a este límite, agrega una capa adicional de jerarquía junto con indicaciones claras sobre a dónde debe ir el modelo que usa la skill para continuar.
Referencia los archivos claramente desde SKILL.md con orientación sobre cuándo leerlos
Para archivos de referencia grandes (>300 líneas), incluye una tabla de contenido

Organización por dominio: Cuando una skill admite múltiples dominios/frameworks, organízala por variante:

cloud-deploy/
├── SKILL.md (flujo de trabajo + selección)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

DSH lee solo el archivo de referencia relevante.

Principio de ausencia de sorpresa

Esto va sin decir, pero las skills no deben contener malware, código de explotación ni ningún contenido que pueda comprometer la seguridad del sistema. El contenido de una skill no debe sorprender al usuario en su intención si se describe. No aceptes solicitudes para crear skills engañosas o skills diseñadas para facilitar el acceso no autorizado, la exfiltración de datos u otras actividades maliciosas. Cosas como "juego de roles como un XYZ" están bien.

Patrones de escritura

Prefiere usar la forma imperativa en las instrucciones.

Definición de formatos de salida - Puedes hacerlo así:

## Estructura del informe
SIEMPRE usa esta plantilla exacta:
# [Título]
## Resumen ejecutivo
## Hallazgos clave
## Recomendaciones

Patrón de ejemplos - Es útil incluir ejemplos. Puedes formatearlos así (pero si "Entrada" y "Salida" están en los ejemplos, quizás quieras desviarte un poco):

## Formato del mensaje de commit
**Ejemplo 1:**
Entrada: Se añadió autenticación de usuario con tokens JWT
Salida: feat(auth): implementar autenticación basada en JWT

Estilo de escritura

Intenta explicar al modelo por qué las cosas son importantes en lugar de usar imperativos estrictos y pesados. Utiliza la teoría de la mente y trata de hacer la skill general y no demasiado específica para ejemplos concretos. Comienza escribiendo un borrador y luego míralo con ojos frescos y mejóralo.

Casos de prueba

Después de escribir el borrador de la skill, propón 2-3 indicaciones de prueba realistas, el tipo de cosa que un usuario real diría. Compártelas con el usuario: [no tienes que usar este lenguaje exacto] "Aquí hay algunos casos de prueba que me gustaría probar. ¿Te parecen correctos, o quieres añadir más?" Luego ejecútalos.

Guarda los casos de prueba en evals/evals.json. No escribas aserciones todavía, solo las indicaciones. Redactarás las aserciones en el siguiente paso mientras las ejecuciones están en progreso.

{
  "skill_name": "ejemplo-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "Indicación de tarea del usuario",
      "expected_output": "Descripción del resultado esperado",
      "files": []
    }
  ]
}

Consulta references/schemas.md para ver el esquema completo (incluyendo el campo assertions, que añadirás más tarde).

Ejecución y evaluación de casos de prueba

Esta sección es una secuencia continua: no te detengas a medio camino. NO uses /skill-test ni ninguna otra skill de prueba.

Coloca los resultados en <nombre-de-la-skill>-workspace/ como un directorio hermano del directorio de la skill. Dentro del workspace, organiza los resultados por iteración (iteration-1/, iteration-2/, etc.) y dentro de cada una, cada caso de prueba obtiene un directorio (eval-0/, eval-1/, etc.). No crees todo esto de antemano, solo crea directorios a medida que avanzas.

Paso 1: Inicia todas las ejecuciones (CON skill Y línea base) en el mismo turno

Para cada caso de prueba, inicia dos subagentes en el mismo turno: uno con la skill y otro sin ella. Esto es importante: no inicies primero las ejecuciones con la skill y luego vuelvas para las líneas base más tarde. Lanza todo a la vez para que termine aproximadamente al mismo tiempo.

Ejecución con skill:

Ejecuta esta tarea:
- Ruta de la skill: <ruta-a-la-skill>
- Tarea: <indicación de evaluación>
- Archivos de entrada: <archivos de evaluación si los hay, o "ninguno">
- Guarda las salidas en: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Salidas a guardar: <lo que le importa al usuario — por ejemplo, "el archivo .docx", "el CSV final">

Ejecución de línea base (misma indicación, pero la línea base depende del contexto):

Creación de una nueva skill: ninguna skill. Misma indicación, sin ruta de skill, guarda en without_skill/outputs/.
Mejora de una skill existente: la versión anterior. Antes de editar, haz una instantánea de la skill copiando el directorio con shutil.copytree (por ejemplo <workspace>/skill-snapshot/ desde <ruta-de-la-skill>), luego apunta el subagente de la línea base a la instantánea. Guarda en old_skill/outputs/.

Escribe un eval_metadata.json para cada caso de prueba (las aserciones pueden estar vacías por ahora). Dale a cada evaluación un nombre descriptivo basado en lo que está probando, no solo "eval-0". Usa este nombre también para el directorio. Si esta iteración usa indicaciones de evaluación nuevas o modificadas, crea estos archivos para cada nuevo directorio de evaluación; no asumas que se heredan de iteraciones anteriores.

{
  "eval_id": 0,
  "eval_name": "nombre-descriptivo-aquí",
  "prompt": "La indicación de tarea del usuario",
  "assertions": []
}

Paso 2: Mientras las ejecuciones están en progreso, redacta aserciones

No esperes simplemente a que las ejecuciones terminen; puedes usar este tiempo de manera productiva. Redacta aserciones cuantitativas para cada caso de prueba y explícalas al usuario. Si ya existen aserciones en evals/evals.json, revísalas y explica lo que verifican.

Las buenas aserciones son objetivamente verificables y tienen nombres descriptivos; deben leerse claramente en el visor de benchmarks para que alguien que eche un vistazo a los resultados entienda inmediatamente lo que cada una verifica. Las skills subjetivas (estilo de escritura, calidad de diseño) se evalúan mejor cualitativamente: no fuerces aserciones en cosas que requieren juicio humano.

Actualiza los archivos eval_metadata.json y evals/evals.json con las aserciones una vez redactadas. También explica al usuario lo que verá en el visor: tanto las salidas cualitativas como el benchmark cuantitativo.

Paso 3: A medida que las ejecuciones se completan, captura los datos de tiempo

Cuando cada tarea de subagente se completa, recibes una notificación, pero no lleva ni recuentos de tokens ni tiempo transcurrido. Toma la duración tú mismo del reloj de pared y lee los totales de tokens del registro de la sesión hija en ~/.dsh/storages/session_projcache/sessions/<childId>.json (tokenUsage.val.totals — uncachedInputTokens, outputTokens, cacheReadTokens, cacheWriteTokens). Guarda estos datos inmediatamente en timing.json en el directorio de ejecución:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

Si ese registro de sesión falta o no tiene uso de tokens, omite los campos de tokens en lugar de inventar números. Procesa cada notificación a medida que llega en lugar de intentar agruparlas.

Paso 4: Califica, agrega e inicia el visor

Una vez que todas las ejecuciones hayan terminado:

Califica cada ejecución: inicia un subagente calificador (o califica en línea) que lea agents/grader.md y evalúe cada aserción con respecto a las salidas. Guarda los resultados en grading.json en cada directorio de ejecución. La matriz de expectativas en grading.json debe usar los campos text, passed y evidence (no name/met/details u otras variantes); el visor depende de estos nombres de campo exactos. Para las aserciones que se pueden verificar mediante programación, escribe y ejecuta un script en lugar de hacerlo a ojo; los scripts son más rápidos, más fiables y se pueden reutilizar entre iteraciones.
Agrega en un benchmark: ejecuta el script de agregación desde el directorio dsh-skill-creator:
```
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
```
Esto produce benchmark.json y benchmark.md con tasa de aprobación, tiempo y tokens para cada evaluación.
Inicia el visor: ejecuta el script del visor desde el directorio dsh-skill-creator:
```
python skills/eval-viewer/start_viewer.py --dir <workspace>/iteration-N
```
Diles al usuario que abran la URL que se muestra y anímalos a que te digan lo que piensan. Pregúntales: "¿Qué te parece? ¿Qué deberíamos cambiar?" Escucha sus comentarios antes de pasar a la siguiente iteración.

Mejora de la skill

Usa exactamente el mismo proceso que la creación de una skill, con estos cambios:

La línea base es la instantánea de la skill anterior
Cuando tengas dudas sobre qué cambiar, ejecuta evaluaciones primero para ver qué falla, y luego decide qué arreglar basándote en los datos
Cuando realices cambios, enfócate en la skill en sí; SKILL.md es el punto de partida. No es necesario que registres cada cambio, pero escribe un resumen de lo que cambió

Cambios en el prompt del sistema

Los cambios en el prompt del sistema a menudo se pueden manejar actualizando solo un archivo: prompts/system_prompt.md. Cuando modifiques este archivo, actualiza también el SKILL.md para que los usuarios entiendan el cambio. No es necesario que registres cada cambio en el prompt del sistema, pero sé transparente sobre los cambios significativos.

Mejorador de descripción de skills

Cuando una skill esté razonablemente madura, usa el script scripts/generate_description.py para encontrar mejores descripciones para la skill. Este script iterará sobre las descripciones, ejecutará evaluaciones para cada una y escalará la mejor.

No ejecutes este script hasta que la skill esté en un estado estable. Ejecutarlo conlleva un costo computacional.

Organización general

Tu directorio principal debería verse así:

dsh-skill-creator/
├── skills/             # Skills de usuario (cada subdirectorio es un paquete de skill)
├── agents/             # Prompts de sistema para subagentes (calificador, etc.)
├── scripts/            # Código de utilidad (mejorador de descripciones, agregador de evaluaciones)
├── evals/              # Conjuntos de evaluación (almacenados como evals.json)
├── prompts/             # Prompts del sistema
└── references/         # Esquemas, documentación y ejemplos

No estás limitado a este diseño, pero es la estructura de proyecto DSH estándar actual. Siéntete libre de innovar dentro de lo razonable.

Creador de Skills

¿Qué es Creador de Skills?

Preguntar en tu IA favorita

Documentación