SOP: Skills as Assets in AI Loops — Por Qué las Skills Bien Diseñadas Son el Asset que Compone

Si leíste el SOP de Loop Engineering, ya sabés que un loop tiene cinco bloques: automatizaciones, worktrees, skills, conectores MCP y sub-agentes. Ese SOP te enseñó a armar el loop. Este SOP te enseña algo distinto: por qué el loop sin skills de calidad es un while-true alrededor de un extraño, y cómo construir skills que compongan valor en vez de quemar tokens.

La tesis central, que viene de Matt Van Horn (June.so) y Peter Steinberger (Codex), es brutalmente simple:

> "The loop is plumbing. The asset is the skill it calls."

El loop es la cañería. La skill es el agua. Podés tener la mejor cañería del mundo — si lo que circula es barro, lo único que estás haciendo es mover barro más rápido.

Steinberger lo dice con otra frase que ya es dogma operativo: "Si hacés algo más de una vez, convertilo en una skill automatizada." La skill no es un lujo de organización. Es el vehículo de la intención que sobrevive a la sesión. Es cómo dejás de pagar por re-derivar el mismo conocimiento una y otra vez.

Este SOP cubre lo que el SOP de Loop Engineering no cubre:

Para entender por qué las skills son el asset, hay que entender de dónde venimos:

` 2022 — ReAct (Reasoning + Acting) │ El agente piensa, elige una herramienta, actúa, observa, repite. │ Problema: cada ciclo es from scratch. Cero memoria procedural. ▼ 2023 — AutoGPT / BabyAGI │ "Dale un goal y que itere solo." │ Problema: loops infinitos. Quemaba tokens hasta que te quedabas sin plata. │ Uber quemó su presupuesto anual de AI en 4 meses con este approach. ▼ 2024 — Ralph (Steinberger), /goal (Codex, Claude Code) │ Goals con condiciones de parada verificables. Un juez externo decide "terminamos". │ Problema: sigue siendo un loop de un solo uso. El conocimiento no se acumula. ▼ 2025-2026 — Skills as Assets + Orchestration (Steinberger, Cherny, Van Horn) │ El loop es plumbing. Lo que compone es la skill. │ Skills versionadas, testeadas, con cost control y verification loops. │ La diferencia entre un loop que compone y uno que degenera. ▼ `

El salto de 2023 a 2025 no fue tecnológico — fue de mentalidad. Pasamos de "el agente puede hacerlo solo" a "el agente puede hacerlo solo si le das las skills correctas y controls para que no se suicide económicamente."

### La intuición equivocada

Cuando armás tu primer loop, la dopamina viene de verlo correr solo. "¡Funciona! ¡No tuve que tocar nada!" Esa es la versión romántica. La versión de producción es más sobria:

Un loop que corre 90 iteraciones sin skills es un agente re-derivando todo tu proyecto desde cero en cada ciclo. Cada tool call es una apuesta a que el modelo infiera tus convenciones, tu stack, tus reglas de la casa. A las 20 iteraciones está confiado pero equivocado. A las 50 está alucinando comandos que no existen. A las 90 te quemó USD 3.47 y produjo algo que no pasa un code review.

Ese mismo loop con 3 skills bien escritas — project-context, code-conventions, testing-standards — gasta 30 iteraciones y produce algo que pasa el checker en la primera pasada.

La skill no es un accesorio del loop. Es el multiplicador de eficiencia. El loop sin skills es un taxi dando vueltas sin pasajero. El loop con skills es un tren sobre rieles.

### La analogía financiera

Pensá las skills como activos fijos en la contabilidad de tu operación con agentes:

Una skill bien diseñada es un asset que se aprecia: cada vez que la usás, el retorno sobre la inversión inicial (el tiempo que tardaste en escribirla) aumenta. Un loop sin skills es un liability que se deprecia: cada ejecución es marginalmente más cara que la anterior porque el contexto acumulado no se capitaliza.

### Steinberger's Razor

Peter Steinberger (creador de Codex) tiene una regla que debería estar tatuada en todo el que opera agentes:

> "If you do something more than once, turn it into an automated skill."

No "considerá convertirlo en skill." No "si tenés tiempo." Hacelo. La segunda vez que le explicás al agente cómo correr los tests de tu proyecto, ya perdiste plata.

Traducción operativa:

• 1 vez: Prompt manual. OK.
• 2 veces: Escribí la skill. Aunque sea un SKILL.md de 6 líneas.
• 3+ veces: La skill ya debería existir. Si no existe, estás quemando plata que ya pagaste.

No toda skill es un asset. Una skill mal diseñada es peor que no tener skill — porque el agente la carga, gasta tokens leyéndola, y después ejecuta instrucciones incorrectas con la confianza de quien "ya leyó la documentación."

Una skill que es un verdadero asset tiene cinco propiedades:

### 1. Es verificable

La skill incluye un criterio de éxito concreto que un agente checker puede evaluar sin ambigüedad. No "el código debería ser bueno." Sí "todos los tests en tests/ pasan con pytest -x y ruff check no reporta errores."

`yaml

• [ ] pytest tests/ -x --tb=short sale con exit code 0
• [ ] ruff check src/ no reporta errores
• [ ] El archivo de output existe en ~/MD-HTML/YYYY-MM-DD-.md
• [ ] El frontmatter YAML tiene title, date, stack, complexity

### 2. Es autocontenida

La skill no asume conocimiento que el agente no tiene. Si necesita un path, lo explicita. Si necesita un comando, lo escribe completo. Si hay una convención, la explica — no la insinúa.

`markdown

• Corré los tests como siempre.

• Corré los tests: cd ~/work/main-checkout && python -m pytest tests/ -x --tb=short
• Si fallan, NO modifiques los tests. Reportá el error y frená.

### 3. Tiene un solo dueño semántico

Cada skill hace una cosa. Si una skill cubre "cómo escribimos código" Y "cómo deployamos" Y "cómo manejamos incidents", es tres skills fingiendo ser una. El agente va a mezclar contextos.

Estructura recomendada:

` ~/.hermes/skills/ ├── admp-project-context/ → Stack, convenciones, reglas de la casa ├── admp-code-conventions/ → Type hints, formato, commits, branches ├── admp-testing-standards/ → Cómo correr tests, coverage mínimo, qué no tocar ├── admp-output-format/ → Formato de archivos MD-HTML, frontmatter requerido ├── admp-deploy-checklist/ → Pasos de deploy, verificación post-deploy └── admp-incident-response/ → Qué hacer si la sheet no responde, rollback, notificación `

Cada una es chica, enfocada, y componible. El loop carga solo las que necesita para la tarea concreta — no un monolito de 4,000 tokens.

### 4. Está versionada y tiene un lifecycle

Una skill sin versión es una landmine temporal. Cambiás algo, el loop de mañana corre con instrucciones nuevas que el checker de hoy no conoce, y todo se desincroniza.

`yaml

name: admp-code-conventions description: Convenciones de código del proyecto ADMP version: 2.1.0 # ← versionado semántico changelog: | 2.1.0: Agregada regla de no usar Any en TypeScript 2.0.0: Migración de flake8 a ruff 1.0.0: Versión inicial metadata: hermes: tags: [admp, conventions, code] category: operations

`

El lifecycle de una skill-asset:

` CREATE → TEST (con /goal o delegate_task) → VERIFY (checker aprueba) → DEPLOY (cron jobs la referencian) → MONITOR (costos, efectividad) → UPDATE (nueva versión) → DEPRECATE (vieja versión en readonly) → RETIRE (nadie la referencia más) `

### 5. Es barata de cargar

La skill usa el menor contexto posible para lograr su objetivo. Si una skill de 200 líneas podría ser de 40, las 160 extra son tokens que pagás en cada ejecución del loop.

Hermes Agent tiene progressive disclosure para esto:

` Level 0: skills_list() → [{name, description, category}] (~3k tokens total) Level 1: skill_view(name) → Contenido completo (variable) Level 2: skill_view(name, path) → Archivo específico (variable) `

Una skill-asset aprovecha esto: el description en el frontmatter es suficiente para que el agente decida si cargarla. El contenido completo solo se carga cuando realmente se necesita.

El loop de producción no es el loop romántico. El loop romántico es el que armaste un sábado a la tarde, viste correr 3 veces, y te fuiste a dormir confiado. El loop de producción es el que sobrevivió un martes a las 3 AM cuando la API rate-limiteó 429, el agente entró en un loop de reintentos, y a las 7 AM te despertaste con USD 340 quemados.

Las tres defensas no son opcionales. Son lo que separa "estoy experimentando" de "esto corre en producción."

### Defensa 1: Cap de iteraciones (max_iterations)

La más obvia pero la más frecuentemente ignorada. En Hermes Agent:

`python AIAgent(max_iterations=90) # default

`

Regla de producción: Para loops autónomos (sin supervisión humana en el loop), max_iterations no debería superar 30. Si una tarea necesita más de 30 tool calls para resolverse, probablemente está mal definida, el agente está dando vueltas, o necesitás partirla en sub-tareas más chicas con skills más específicas.

En ~/.hermes/config.yaml:

`yaml agent: max_iterations: 30 # Loops autónomos: 30. Sesiones interactivas: 90.

delegation: max_iterations: 20 # Sub-agentes: aún más restrictivo `

Por qué 30 y no 90: Un agente en un loop autónomo que llegó a la iteración 40 ya demostró que no sabe resolver la tarea. Cada iteración extra es plata que estás quemando en un camino sin salida. El default de 90 existe para sesiones interactivas donde un humano puede desatascar al agente. En un loop sin supervisión, 30 es generoso.

### Defensa 2: No-Progress Detection

Esta es la defensa que el 90% de los loops no tienen. El agente puede estar técnicamente "trabajando" — llamando herramientas, generando output — pero no estar progresando. Gira sobre el mismo archivo, reescribe lo mismo de formas distintas, o peor: arregla y rompe el mismo test en ciclos.

Cómo implementarlo en Hermes Agent:

Opción A — Vía skill en el loop orquestador:

`markdown

Después de cada iteración del maker, comparar el hash del output file:

`bash INITIAL_HASH=$(shasum -a 256 ~/MD-HTML/output.md 2>/dev/null || echo "NEW_FILE")

CURRENT_HASH=$(shasum -a 256 ~/MD-HTML/output.md) if [ "$INITIAL_HASH" = "$CURRENT_HASH" ]; then NO_PROGRESS_COUNT=$((NO_PROGRESS_COUNT + 1)) else NO_PROGRESS_COUNT=0 INITIAL_HASH=$CURRENT_HASH fi

if [ $NO_PROGRESS_COUNT -ge 5 ]; then echo "STALLED: No progress in 5 iterations" # Actualizar admp_triage: status='stalled', checker_notes='No progress detected' exit 1 fi `

Opción B — Vía el config de Hermes Agent:

`yaml iteration: no_progress_threshold: 5 # Iteraciones sin cambio en el output → stall no_progress_window: "files" # Qué monitorear: "files", "tool_results", "all" `

Opción C — Vía el cron watchdog (ya cubierto en el SOP de Loop Engineering):

`bash hermes cron create "0 /2 " \ "Revisá la sheet admp_triage. Items con status='in_progress' hace más de 2 horas, y cuyo output_file no cambió de hash en la última hora → marcar stalled." \ --name "No-Progress Watchdog" \ --skill admp-triage-loop \ --deliver telegram `

La regla de oro del no-progress detection: Si un agente autónomo pasó 5 iteraciones sin modificar el archivo de output, no va a modificarlo en la iteración 6. Lo que va a hacer en la iteración 6 es gastar más tokens. Cortalo.

### Defensa 3: Dollar Budget Ceiling

Esta es la que Uber no tenía cuando quemó su presupuesto anual de AI en 4 meses. Un cap de iteraciones frena el loop por cantidad de tool calls. Un dollar budget frena el loop por plata gastada — que es lo que realmente te importa.

Hermes Agent tiene iteration_budget:

`python class IterationBudget: def __init__(self, max_total: int): self.max_total = max_total self._used = 0

def consume(self) -> bool: # Retorna False si se acabó el presupuesto ...

@property def remaining(self) -> int: return max(0, self.max_total - self._used) `

Pero iteration_budget es un cap de iteraciones, no de dólares. Para un dollar budget real, necesitás una capa extra:

Implementación de dollar budget en el loop:

`bash mkdir -p ~/.hermes/skills/budget-guard

cat > ~/.hermes/skills/budget-guard/SKILL.md << 'SKILLEOF'

name: budget-guard description: Monitorea y enforcea el dollar budget del loop version: 1.0.0 metadata: hermes: tags: [budget, cost-control, production] category: operations config: - key: budget.daily_limit_usd description: "Límite diario de gasto en USD para loops autónomos" default: "5.00" - key: budget.monthly_limit_usd description: "Límite mensual de gasto en USD" default: "50.00" - key: budget.cost_per_1k_tokens description: "Costo estimado por 1000 tokens (promedio input+output)" default: "0.003"

Al inicio de cada ciclo del loop orquestador, ANTES de delegar sub-agentes.

### 1. Leer estado actual del presupuesto - Consultar la sheet admp_triage, columna daily_token_usage y monthly_token_usage. - Si no existen, inicializar en 0.

### 2. Estimar costo de la tarea pendiente - Multiplicar selected_output por un factor de complejidad: - sop → ~15,000 tokens → ~USD 0.045 - articulo → ~8,000 tokens → ~USD 0.024 - investigacion → ~30,000 tokens → ~USD 0.09

### 3. Decidir - Si daily_token_usage + estimado > daily_limit → NO ejecutar. Marcar item como budget_blocked. - Si monthly_token_usage + estimado > monthly_limit → NO ejecutar. Notificar por Telegram. - Si hay presupuesto → ejecutar. Después actualizar daily_token_usage y monthly_token_usage.

### 4. Reportar - Al final de cada día, calcular total gastado y reportar por Telegram: "📊 Budget Report: USD X.XX gastados hoy (límite: USD Y.YY). Mensual: USD Z.ZZ / USD M.MM."

• La estimación es aproximada. El costo real puede variar ±30%.
• Si el presupuesto diario se agotó, los items quedan para mañana. No forzar.

Configuración recomendada de dollar budget:

`yaml

budget: daily_limit_usd: 5.00 # Un loop autónomo no debería gastar más de USD 5/día monthly_limit_usd: 50.00 # USD 50/mes es generoso para un loop de contenido alert_at_percent: 80 # Notificar cuando llegás al 80% del límite mensual hard_stop: true # true = frenar todo. false = solo notificar. `

La regla de producción: El dollar budget no es una sugerencia. Es un kill-switch. Si el loop llega al límite, frena. No "termina esta tanda y frena." Frena ya. La diferencia entre "terminar esta tanda" y "frenar ya" es lo que separa un sobrecosto de USD 12 de un sobrecosto de USD 340.

Escribiste la skill. La probaste una vez. Funcionó. La pusiste en producción. Tres semanas después, el loop está generando basura y no sabés por qué.

El problema no es la skill. Es que nunca tuviste un verification loop.

### El verification loop es distinto del checker del maker

El checker del SOP de Loop Engineering verifica el output de una ejecución específica. El verification loop verifica la skill misma — si sigue siendo efectiva, si sus instrucciones son correctas, si los supuestos que asumió siguen siendo válidos.

` ┌──────────────────────────────────────────────────────┐ │ VERIFICATION LOOP (semanal) │ │ │ │ 1. Cargar la skill a verificar │ │ 2. Seleccionar 3 outputs aleatorios de esa skill │ │ (de la sheet admp_triage, últimos 7 días) │ │ 3. Para cada output: │ │ a. ¿Pasó el checker original? │ │ b. ¿El output es realmente bueno? │ │ (revisión humana de una muestra) │ │ c. ¿La skill sigue siendo relevante? │ │ 4. Calcular métricas: │ │ - Aceptación del checker: X/Y │ │ - Calidad real (humana): A/B │ │ - Drift: ¿la skill necesita actualización? │ │ 5. Si drift > threshold → flaggear skill para update │ │ 6. Reportar por Telegram │ └──────────────────────────────────────────────────────┘ `

### Implementación del verification loop en Hermes

`bash mkdir -p ~/.hermes/skills/skill-verifier

cat > ~/.hermes/skills/skill-verifier/SKILL.md << 'SKILLEOF'

name: skill-verifier description: Verification loop semanal para auditar la efectividad de las skills en producción version: 1.0.0 metadata: hermes: tags: [verification, quality, audit] category: operations

Semanalmente (domingo a las 10 AM) vía cron. O manualmente con /skill-verifier .

### 1. Seleccionar skill a auditar - Si se invoca con nombre de skill → auditar esa skill específica. - Si se invoca sin argumentos → seleccionar la skill con mayor tiempo sin verificación.

### 2. Buscar outputs recientes - Leer admp_triage, filtrar output_file no vacío de los últimos 7 días donde se usó la skill. - Tomar 3 outputs aleatorios. Si hay menos de 3, tomar todos los disponibles.

### 3. Verificación automática (checker standard) Para cada output: - ¿El archivo existe en el path registrado? - ¿Tiene frontmatter YAML válido? - ¿Pasa las reglas de verificación de la skill original? - ¿checker_verdict = 'APPROVED' en la sheet?

### 4. Verificación de drift Comparar el output contra la skill actual: - ¿El output sigue las instrucciones actuales de la skill? - ¿Hay patrones en los rechazos del checker que sugieran que la skill está mal calibrada? - ¿Las convenciones del proyecto (en admp-project-context) cambiaron desde que se generó este output?

### 5. Métricas Calcular y escribir en admp_triage (o en una sheet separada skill_audit): - skill_name: nombre de la skill - audit_date: fecha de auditoría - outputs_checked: cuántos outputs se revisaron - checker_pass_rate: % de outputs que pasaron el checker original - drift_detected: true/false - recommendation: keep / update / deprecate / retire

### 6. Notificar "🔍 Skill Audit: {skill_name} Outputs revisados: {n} Tasa de aprobación del checker: {x}% Drift detectado: {yes/no} Recomendación: {keep/update/deprecate/retire}"

• No auditar skills que no tienen outputs en los últimos 7 días (no hay datos).
• Si drift_detected = true, no modificar la skill automáticamente. Flaggear para revisión humana.

hermes cron create "0 10 0" \ "Ejecutá el skill-verifier sobre todas las skills activas del proyecto ADMP. Empezá por las skills con más tiempo sin verificación." \ --name "Weekly Skill Audit" \ --skill skill-verifier \ --deliver telegram `

### El feedback loop cierra el círculo

El verification loop produce una de tres señales:

Esto cierra el ciclo: crear → testear → deployar → verificar → actualizar → volver a verificar. Sin este ciclo, las skills se pudren silenciosamente. El loop sigue corriendo, los costos siguen acumulándose, pero el valor neto es negativo.

El loop romántico y el loop de producción son dos animales distintos. Acá está la tabla que nadie te muestra:

### La Versión Romántica (lo que hacés el sábado a la tarde)

### La Versión de Producción (lo que sobrevive el martes a las 3 AM)

### Las 5 reglas de Boris Cherny para loops autónomos (traducidas a Hermes)

Boris Cherny (head de Claude Code en Anthropic) destiló 5 reglas para loops que corren sin supervisión. Acá están, mapeadas a Hermes Agent:

1. "Always have a judge that isn't the doer."

1. "The stopping condition must be concrete and verifiable."

1. "Cap everything: iterations, time, money."

1. "Test your loop with the worst model you plan to use."

1. "If you wouldn't trust it at 3 AM, don't run it autonomously."

### Crear una skill

`bash mkdir -p ~/.hermes/skills//

hermes chat -q "Después de terminar esta tarea, creá una skill que documente el proceso" `

### Estructura de directorios recomendada

`text ~/.hermes/skills/ ├── admp/ # Skills específicas del proyecto ADMP │ ├── admp-project-context/ # Stack, convenciones, reglas │ │ ├── SKILL.md │ │ └── references/ │ │ └── stack-details.md # Info más densa que no carga siempre │ ├── admp-code-conventions/ # Código: type hints, linting, commits │ │ └── SKILL.md │ ├── admp-testing-standards/ # Tests: cómo, coverage, qué no tocar │ │ └── SKILL.md │ ├── admp-output-format/ # Formato de archivos MD-HTML │ │ ├── SKILL.md │ │ └── templates/ │ │ └── sop-template.md # Template reutilizable │ └── admp-deploy-checklist/ # Deploy y verificación post-deploy │ └── SKILL.md ├── loop-ops/ # Skills operativas del loop │ ├── admp-triage-loop/ # Triage diario │ │ └── SKILL.md │ ├── admp-loop-orchestrator/ # Orquestador principal │ │ └── SKILL.md │ ├── budget-guard/ # Dollar budget enforcement │ │ └── SKILL.md │ └── skill-verifier/ # Verification loop semanal │ └── SKILL.md └── content/ # Skills de generación de contenido ├── sop-generator/ # Generador de SOPs │ └── SKILL.md └── article-writer/ # Escritor de artículos └── SKILL.md `

### Versionar skills con git

`bash cd ~/work mkdir admp-skills && cd admp-skills git init

cp -r ~/.hermes/skills/admp/ . cp -r ~/.hermes/skills/loop-ops/ . cp -r ~/.hermes/skills/content/ .

git add -A && git commit -m "feat: initial skills library for ADMP loop"

`

### Comandos esenciales de Hermes para gestión de skills

`bash hermes chat --toolsets skills -q "Listá mis skills, mostrame nombres y descripciones"

hermes chat --toolsets skills -q "Mostrame la skill admp-code-conventions"

/admp-project-context

/reload-skills

hermes skills browse # Navegar skills disponibles hermes skills search "loop" # Buscar skills relacionadas hermes skills install openai/skills/k8s # Instalar desde GitHub

hermes bundles create admp-full \ --skill admp-project-context \ --skill admp-code-conventions \ --skill admp-testing-standards \ --skill admp-output-format \ -d "Contexto completo del proyecto ADMP — cargar al inicio de cada sesión"

/admp-full generá un SOP sobre testing en Python

hermes skills reset admp-code-conventions # Limpiar flag de user-modified hermes skills reset admp-code-conventions --restore # Volver a la versión bundled original `

### Deprecar y retirar una skill

`bash cat >> ~/.hermes/skills/admp/old-skill/SKILL.md << 'EOF'

Esta skill fue reemplazada por admp-new-skill en versión 2.0.0. Mantenida en readonly hasta YYYY-MM-DD. No usar en nuevos loops. EOF

hermes cron list | grep old-skill hermes cron edit --skill admp-new-skill

rm -rf ~/.hermes/skills/admp/old-skill /reload-skills `

Lo que no se mide no se mejora. Estas son las métricas mínimas que todo loop con skills debería trackear:

### Métricas por skill

### Tracking de costos en Hermes Agent

Hermes no expone costo en USD nativamente (depende del modelo y provider), pero podés estimarlo:

`bash cat > ~/scripts/hermes-cost-estimator.sh << 'EOF' #!/bin/bash

LOG="${1:-$HOME/.hermes/logs/agent.log}" DATE="${2:-$(date +%Y-%m-%d)}"

INPUT_CHARS=$(grep "$DATE" "$LOG" | grep -o '"prompt_tokens": [0-9]*' | awk '{sum+=$2} END {print sum}') OUTPUT_CHARS=$(grep "$DATE" "$LOG" | grep -o '"completion_tokens": [0-9]*' | awk '{sum+=$2} END {print sum}')

COST_PER_1M=3.00 TOTAL_TOKENS=$((INPUT_CHARS + OUTPUT_CHARS)) COST=$(echo "scale=4; $TOTAL_TOKENS * $COST_PER_1M / 1000000" | bc)

echo "📊 $(date +%Y-%m-%d) Cost Estimate" echo " Input tokens: $(printf "%'d" $INPUT_CHARS)" echo " Output tokens: $(printf "%'d" $OUTPUT_CHARS)" echo " Total tokens: $(printf "%'d" $TOTAL_TOKENS)" echo " Est. cost: \$$COST (at \$${COST_PER_1M}/1M tokens)" EOF

chmod +x ~/scripts/hermes-cost-estimator.sh `

### Dashboard mínimo (vía skill)

`bash mkdir -p ~/.hermes/skills/loop-dashboard

cat > ~/.hermes/skills/loop-dashboard/SKILL.md << 'SKILLEOF'

name: loop-dashboard description: Dashboard mínimo del loop — métricas clave en un solo vistazo version: 1.0.0 metadata: hermes: tags: [dashboard, metrics, monitoring] category: operations

Manual: /loop-dashboard. O automático vía cron al final del día.

Un resumen estructurado con las métricas clave del loop:

### Health - Loop uptime: {última ejecución exitosa vs ahora} - Items en queue: {count de status='pending' o 'triaged'} - Items stalled: {count de status='stalled'} - Budget: ${gastado_hoy} / ${limite_diario} (${porcentaje}%)

### Quality - Checker pass rate (7 días): {porcentaje}% - Retry rate (7 días): {porcentaje}% - Human spot-check approval (último muestreo): {porcentaje}%

### Top Skills (por uso) 1. {skill_name}: {n} ejecuciones, {pass_rate}% pass rate 2. {skill_name}: {n} ejecuciones, {pass_rate}% pass rate 3. ...

### Alerts - {cualquier item stalled, budget接近 límite, checker pass rate < 70%}

### Cost - Hoy: ${costo_diario} - Esta semana: ${costo_semanal} - Este mes: ${costo_mensual} / ${limite_mensual}

• Los datos vienen de admp_triage. Si la sheet está desactualizada, el dashboard miente.

Así como hay propiedades de una skill-asset, hay anti-patrones que convierten una skill en un liability:

### Anti-patrón 1: La Skill Enciclopedia

`markdown

`

Por qué es un liability: El agente carga 400 líneas de contexto para una tarea que necesita 40. Las 360 extra son tokens desperdiciados que además diluyen la atención del modelo.

Fix: Partir en skills atómicas. El loop carga solo las que necesita.

### Anti-patrón 2: La Skill Aspiracional

`markdown

• Siempre escribimos tests antes del código (TDD estricto)
• Cobertura mínima: 95%
• Todos los tests son property-based con Hypothesis

Por qué es un liability: El agente intenta seguir reglas aspiracionales que ni los humanos del equipo siguen. Falla. Reintenta. Quema tokens persiguiendo un estándar que no existe en la práctica.

Fix: La skill describe lo que REALMENTE hacemos. Si querés cambiar el estándar, cambiá la práctica primero, después actualizá la skill.

### Anti-patrón 3: La Skill Sin Verificación

`markdown

1. Leer el item de la sheet
2. Escribir el SOP
3. Guardar en ~/MD-HTML/

• No inventar comandos

Por qué es un liability: El agente generó un output. ¿Está bien? No hay forma automática de saberlo. El checker no tiene criterios concretos. El verification loop no tiene métricas.

Fix: Toda skill termina con ## Verification — una checklist concreta que un script o un agente checker puede evaluar.

### Anti-patrón 4: La Skill Fantasma

`bash `

Por qué es un liability: Ocupa espacio mental, aparece en skills_list(), y un agente podría cargarla y ejecutar instrucciones obsoletas.

Fix: Si una skill no se usó en 30 días y su checker pass rate es <50%, deprecala o retirala. Una skill que no se usa es deuda, no activo.

### Anti-patrón 5: La Skill Hardcodeada en el Cron

`bash

hermes cron create "0 9 1-5" \ "Leé la sheet admp_triage. Para cada item con status='pending': 1. Si el campo selected_output='sop', generá un SOP con el formato del proyecto ADMP. El formato es: título en H1, metadata YAML con title/date/stack/complexity, secciones con ##, comandos en bash, checklist de verificación con checkboxes, troubleshooting en tabla, referencias al final. Escribilo en ~/MD-HTML/ con nombre de archivo YYYY-MM-DD-sop-.md. Usá español argentino. No inventes comandos. Etc, etc, etc..." \ --name "Morning SOP Generator" \ --deliver telegram `

Por qué es un liability: Las instrucciones viven en el cron job, no en una skill. Si cambiás el formato de SOP, tenés que editar N cron jobs. Si creás un segundo cron que también genera SOPs, tenés que copypastear las instrucciones. Eventualmente divergen.

Fix: El cron job referencia una skill. La skill es la fuente de verdad.

`bash

hermes cron create "0 9 1-5" \ "Ejecutá el loop de triage diario" \ --name "ADMP Morning Triage" \ --skill admp-triage-loop \ --deliver telegram `

Las skills no viven aisladas. Forman un ecosistema donde cada una tiene un rol:

` ┌──────────────────────────────┐ │ admp-project-context │ │ (Stack, convenciones, reglas) │ └──────────────┬───────────────┘ │ es cargada por ┌──────────────▼───────────────┐ │ admp-loop-orchestrator │ │ (Coordina el ciclo completo) │ └──────────────┬───────────────┘ │ delega a ┌────────────────────────┼────────────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ sop-generator │ │ article-writer │ │ budget-guard │ │ (Genera SOPs) │ │ (Genera artículos)│ │ (Enforcea $) │ └────────┬────────┘ └────────┬────────┘ └─────────────────┘ │ │ │ es verificada por │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ sub-agente │ │ sub-agente │ │ checker │ │ checker │ └────────┬────────┘ └────────┬────────┘ │ │ │ alimenta a │ ▼ ▼ ┌─────────────────────────────────────────┐ │ admp_triage (Google Sheet) │ │ (Memoria externa: estado, métricas) │ └────────────────────┬────────────────────┘ │ es auditada por ▼ ┌─────────────────────────────────────────┐ │ skill-verifier │ │ (Verification loop semanal) │ └────────────────────┬────────────────────┘ │ actualiza si hay drift ▼ ┌─────────────────────────────────────────┐ │ skill updates │ │ (Versionado, changelog, redeploy) │ └─────────────────────────────────────────┘ `

Regla de arquitectura: Una skill nunca debería referenciar a otra skill por nombre en su SKILL.md. La orquestación (qué skills cargar y en qué orden) es responsabilidad del admp-loop-orchestrator, no de las skills individuales. Una skill debe poder cargarse sola y funcionar — el orquestador le da el contexto adicional que necesita.

No intentes pasar de cero a producción en un día. Esto es un plan realista para migrar un loop romántico a uno de producción:

### Semana 1: Auditar y Medir

• [ ] Ejecutar skill-verifier sobre todas las skills existentes
• [ ] Medir costo diario real del loop (con hermes-cost-estimator.sh)
• [ ] Identificar la skill con peor checker pass rate
• [ ] Identificar la skill más costosa (costo por output)
• [ ] Revisar manualmente 5 outputs aleatorios para calibrar expectativas

### Semana 2: Refactorizar Skills

• [ ] Partir skills monolíticas (>150 líneas) en skills atómicas (<80 líneas)
• [ ] Agregar sección ## Verification a toda skill que no la tenga
• [ ] Agregar version y changelog al frontmatter de cada skill
• [ ] Crear budget-guard skill
• [ ] Migrar instrucciones hardcodeadas en cron jobs a skills referenciadas

### Semana 3: Implementar Cost Controls

• [ ] Configurar max_iterations=30 para loops autónomos
• [ ] Activar dollar budget diario (empezar con USD 10/día, bajar a USD 5/día en semana 4)
• [ ] Implementar no-progress watchdog (cron cada 2 horas)
• [ ] Crear cron de skill-verifier semanal
• [ ] Configurar alertas de presupuesto al 80%

### Semana 4: Estabilizar y Documentar

• [ ] Tres ejecuciones manuales completas del loop sin intervención humana
• [ ] Ajustar dollar budget basado en datos reales de la semana
• [ ] Escribir runbook de incidentes: qué hacer si el loop se va de presupuesto
• [ ] Escribir runbook de rollback: cómo volver atrás una skill
• [ ] Activar loop en modo autónomo completo (cron jobs activos 24/7)
• [ ] Programar revisión mensual de métricas

Usá esta checklist antes de deployar una skill a producción:

### Estructura - [ ] El SKILL.md tiene frontmatter YAML con name, description, version - [ ] La skill está en el directorio correcto (~/.hermes/skills///) - [ ] La skill no excede 80 líneas (si excede, considerar particionar) - [ ] La skill no referencia otras skills por nombre

### Contenido - [ ] Las instrucciones son explícitas (comandos completos, paths absolutos) - [ ] No asume conocimiento implícito del proyecto - [ ] Tiene sección ## When to Activate con condiciones claras - [ ] Tiene sección ## Procedure con pasos numerados - [ ] Tiene sección ## Verification con criterios medibles - [ ] Tiene sección ## Pitfalls con fallos conocidos y fixes

### Seguridad - [ ] No contiene secrets (API keys, tokens, passwords) - [ ] No contiene instrucciones destructivas sin confirmación explícita - [ ] Los paths son de solo lectura cuando corresponde

### Ciclo de Vida - [ ] La skill está versionada (semver) - [ ] El changelog está actualizado - [ ] Hay un plan de deprecación (¿cuándo debería retirarse esta skill?) - [ ] Los cron jobs que la referencian están documentados

### Testing - [ ] La skill se probó manualmente al menos 3 veces - [ ] Se probó con el modelo más barato que vas a usar (regla de Cherny #4) - [ ] El checker aprobó los outputs de prueba - [ ] Se midió el costo promedio por ejecución

### Producción - [ ] max_iterations está configurado apropiadamente (≤30 para autónomo) - [ ] El dollar budget está activo - [ ] El no-progress watchdog está configurado - [ ] La skill está en el verification loop semanal - [ ] Las alertas están configuradas (Telegram mínimo)