SOP: Cómo escribir un skill para Hermes Agent

Un skill es un archivo SKILL.md que el agente lee y ejecuta. No es un prompt (muere con la sesión). No es un config file (se inyecta siempre). Es un workflow reutilizable que se carga bajo demanda.

1. Frontmatter YAML (Tier 1 — 30-50 tokens)

`yaml

name: nombre-del-skill description: "Use cuando . " tags: [] related_skills: []

`

Reglas del description: - Primeros 57 caracteres definen si se carga o no — poner el trigger al inicio - "Use cuando necesites hacer X" → funciona mejor que descripciones vagas - Si no aplica → no poner "Use cuando" y que el nombre describa el propósito

2. Cuerpo Markdown (Tier 2 — instrucciones completas)

`markdown

1. ...
2. ...
3. ...

• ⚠️ Error común que pasa seguido

3. Archivos de referencia (Tier 3 — bajo demanda)

• templates/ — plantillas reutilizables
• scripts/ — scripts ejecutables
• references/ — documentación adicional

1. Misalignment — El agente no entendió lo que querías

Síntoma: Acepta la task, arranca a codear, y vuelve con otra cosa.

Fix en el skill: `markdown

1. Leé las instrucciones completas
2. Si hay ambigüedad, preguntá antes de actuar
3. Confirmá entendimiento con el usuario antes de ejecutar

2. Verbosidad — El agente reinventa tu vocabulario cada sesión

Síntoma: Explica conceptos de 24 palabras cuando tu código usa 2.

Fix en el skill: - Referenciar glossary compartido (CONTEXT.md) al inicio - Usar nombres consistentes en todo el skill - Especificar la jerga del proyecto

3. Código roto — Sin feedback loop, codea a ciegas

Síntoma: El código se ve bien pero explota en runtime.

Fix en el skill: `markdown

1. Test primero (debe fallar) — RED
2. Implementación mínima para pasar — GREEN
3. Refactor — limpiar duplicación
4. Verificar que el test original ahora pase

4. Entropía — Skills que se vuelven frágiles con el tiempo

Síntoma: Skills viejos que ya no se actualizan, referencias rotas.

Fix: - Revisión semanal de skills activos (curator) - Skills pinneados no se borran - Backup de skills antes de podar

Estructura mínima (30 líneas o menos)

`yaml

name: code-review description: "Use cuando necesites revisar código antes de merge. Checklist de 6 pasos."

1. Leé el diff completo antes de comentar
2. Verificá tipos (no any, no as unknown)
3. Buscá side effects no declarados
4. Confirmá que los tests existen y pasan
5. Revisá nombres de variables (consistentes con el proyecto)
6. Aprobá o pedí cambios con el diff específico

Una skill, un trabajo

• Si tu skill tiene más de 2 páginas impresas → dividilo
• Skills cortos (3-10 pasos) → mejor tasa de adopción
• Skills largos → requieren mantenimiento constante

Stateless primero, stateful después

Antes de instalar un skill de la comunidad:

• [ ] Leé el SKILL.md completo (no solo el nombre y descripción)
• [ ] Abrí scripts/ y leé cada archivo — si descarga algo de internet o accede a env vars, entendé por qué
• [ ] Verificá quién publicó — cuenta anónima con 1 repo ≠ dev establecido
• [ ] Probá en un proyecto descartable primero
• [ ] Nunca instalar skills no verificados en producción

`bash skill_view(name="mi-skill")

gbrain add --key "skill:mi-skill" --value "creado $(date +%Y-%m-%d)" `

Cada vez que un skill se usa y se encuentra un error o mejora, se parchea inmediatamente con skill_manage(action='patch'). Esto crea un efecto compuesto: skills que se vuelven más precisos y completos con cada uso.

> "Skills son portables entre herramientas, componibles entre workflows, y se componen con el tiempo. Esa es la diferencia entre usar AI y construir con AI."