Cómo evaluar skills SEO de Claude Code con evals automáticos

#¿Qué significa evaluar un brief SEO, y por qué no es lo mismo que evaluar la skill

Cuando alguien dice "evaluamos nuestra skill de Claude Code" casi siempre se refiere a evaluar el código: si el trigger dispara en el momento correcto, si el sub-agente ejecuta bien los pasos, si no rompió nada de una versión a otra. Eso es necesario, pero es una capa distinta de evaluar el artefacto de contenido que esa skill produce antes de que un humano (o el mismo modelo) se ponga a redactar el artículo final.

Un brief SEO es esa pieza intermedia: el documento que junta intención de búsqueda, gap de contenido, competidores, subtemas obligatorios y la fuente de cada dato, antes de escribir una sola oración del artículo. Si el brief está mal (un gap inventado, una fuente no citada, un research de hace dos meses) todo lo que se escribe encima hereda ese error, sin importar cuán bien redactada quede la prosa. Evaluar la skill de código y evaluar el brief que esa skill entrega son dos gates distintos, y hoy casi nadie documenta el segundo.

Ver cómo aplicar esta guía a mi marca

#El gap: 5 recursos evalúan la skill, ninguno evalúa el brief que produce

Repasamos los recursos más citados sobre evals de skills de Claude Code: el skill-creator 2.0 de Anthropic con sus sub-agentes executor/grader/comparator/analyzer (tessl.io), el experimento de dbt con una rúbrica LLM-judge de 9 criterios (rmoff.net), el A/B testing con una confianza por encima de 0,90 sobre 50 o más ejemplos (MindStudio) y la librería de marketing skills de Ahrefs (ahrefs.com).

Los cuatro evalúan el proceso o el código de la skill. Ninguno define cómo evaluar el artefacto de contenido SEO que esa skill produce antes de redactar: ni fijan un umbral pass/fail para un brief editorial, ni aplican su metodología a contenido de marketing escrito. Ese es el hueco puntual que este gate cubre, no un "los demás no son lo bastante completos" genérico: cada fuente tiene una carencia específica y citable, no una queja vaga.

#Qué distingue un content gap específico y verificable (con evidencia y URL) de una queja genérica de tipo 'los competidores no son lo bastante completos'

La diferencia no es de tono, es de verificabilidad. "Los competidores no son lo bastante completos" no se puede confirmar ni refutar: es una opinión. Un gap específico cita, por cada competidor relevado, qué cubre (coverage) y qué le falta (missing) con el sourceUrl de esa página, de forma que cualquier tercero pueda entrar al link y comprobar la afirmación en un minuto. En este gate, el hard check gap bloquea directamente cualquier brief donde el statement no venga acompañado de al menos una evidencia con claim y URL válida: sin URL, no es gap, es queja.

#Judges basados en reglas (hard checks) vs LLM-judge

Los hard checks son código puro: sin placeholders, research con menos de 14 días, un interlink con motivo, fuentes declaradas. Corren en milisegundos y siempre dan el mismo resultado. El LLM-judge entra después, para lo que el código no puede medir solo: si el gap es específico o genérico, si el unique take tiene prueba real o es una afirmación de marketing. Tratarlos como el mismo paso es el error más común.

Este mismo principio (un blocker no se promedia, se resuelve puntual) aparece también en harnesses de evals de skills que auditan código en vez de contenido: el harness j-rig-skill-binary-eval evalúa en siete capas (entre ellas integridad del paquete, calidad del trigger y decisión de rollout) con criterios binarios, y aclara que un blocker no se puede compensar con el promedio. La diferencia con el gate de este artículo es el objeto que audita cada uno: j-rig audita el código y los triggers de la skill, este gate audita el brief editorial que esa skill produce antes de redactar.

#Estructura de evals.json / test cases con assertions verificables

Este gate no usa un evals.json de skill genérico: usa un script propio, eval-brief.mjs, que corre 16 checks binarios sobre el objeto JSON del brief. La lógica es la misma que describe el skill-creator de Anthropic (assertions binarias, deterministas, sin escala de "más o menos"), aplicada al objeto de contenido en vez de al código:

// cada check devuelve { id, pass, message }, sin promedios ni escalas
add("freshness", ageMs <= 14 * 86_400_000, "research debe tener <=14 días")
add("gap", statement.length >= 40 && evidence.every(hasUrl), "gap exige evidencia con URL")
add("interlinks", interlinks.length >= 1 && interlinks.every(hasReason), "al menos un interlink con motivo")

Si un solo check falla, el brief entero queda en blockers con el id y el mensaje exacto de qué corregir. No hay "aprobado con observaciones": o los 16 pasan, o el brief no avanza a la siguiente capa.

#Checklist de implementación paso a paso: cómo montar hard checks estructurales + un rubric de 5 ejes con piso por dimensión sobre tu propio brief SEO

1. Escribí los hard checks primero. Empezá por lo verificable sin ambigüedad: schema válido, cero placeholders, research con fecha y antigüedad máxima, cada competidor con coverage y missing, cada fuente (GSC, Ahrefs) con un estado declarado.
2. Corré el script y mirá el output real, no confíes en que "debería pasar":

3. Probá que el piso bloquea de verdad, no solo que aprueba. Corré el mismo fixture con el gap invalidado (statement placeholder, evidencia vacía) y confirmá que el script lo rechaza con el id exacto del check que falló:

4. Sumá el rubric semántico recién si los hard checks pasan. 5 ejes (intent_format, content_gap, unique_take, coverage, evidence), cada uno puntuado 0 a 20 por un LLM-judge, con un piso de 16 por eje sobre un total mínimo de 85.
5. Versioná un test suite con fixtures good/bad (eval-brief.test.mjs) para que cada cambio al script se valide contra casos conocidos antes de tocar producción.
6. Conectá el gate al pipeline: el redactor (la skill que escribe el artículo) recibe el brief solo si pass: true, y verifica que el briefHash que recibió coincide con el que evaluó el gate, para no redactar sobre una versión vieja o alterada del brief.

#Umbral de pass/fail y blockers accionables para un gate editorial

Un blocker sirve si le dice al que repara exactamente qué tocar, no "el brief necesita mejorar". Cada check de eval-brief.mjs devuelve un id (gap, interlinks, freshness) y un mensaje puntual ("gap exige statement específico y evidencia con URL"). El rubric semántico suma un piso de 16 sobre 20 por eje y un total mínimo de 85 sobre 100, de modo que ningún eje puede quedar débil aunque el promedio general apruebe: un brief con evidencia en 19 pero unique take en 10 no pasa, aunque el promedio dé 14.5 sobre 20 en esos dos ejes.

#Cómo mitigar la varianza entre corridas de un LLM-judge (multi-sample voting, calibración, umbral de desacuerdo) antes de fijarlo como gate pass/fail

Ningún LLM-judge da exactamente el mismo score en dos corridas separadas. Una forma directa de no depender de una sola pasada es el multi-sample voting: correr el mismo brief contra el judge 3 o 5 veces y quedarte con la mediana, o exigir mayoría de acuerdo antes de tratar el veredicto como definitivo; si el desacuerdo entre corridas supera un umbral fijo, el brief va a revisión humana en vez de resolverse solo. La otra pata es tratar el resultado como un test compuesto: combinar los 5 ejes en vez de un score único, exigir que cada uno supere su piso de forma independiente, y calibrar el juez cada tanto comparando su veredicto contra criterio humano. El estudio de dbt de rmoff.net es honesto sobre esto: reconoce la varianza entre jueces sin resolverla del todo, y concluye textualmente que "ninguno de los tests produjo un proyecto de dbt lo bastante bueno para llevar a producción", y que Claude Code sigue necesitando a alguien con experiencia que lo guíe y revise. Ese hallazgo aplica igual acá: el gate automático reduce el volumen de revisión humana, no la elimina.

#Riesgo de falsos positivos (bloquear un brief válido) y costo de mantenimiento de un gate semántico automático: cómo mitigarlo sin bajar el umbral de aprobación

Un gate mal calibrado castiga briefs válidos por detalles menores. La forma de evitarlo sin bajar el umbral es acotar el rubric a 5 ejes con criterios claros, puntuados por separado para que uno no contamine a los otros, fijar el piso por eje en un número bajo pero real (16 sobre 20, no 19) y versionar un test suite de fixtures conocidos que corra cada vez que se toca el script. Si el test suite sigue devolviendo pass: true en el fixture bueno y pass: false en el malo después de un cambio, el gate sigue calibrado. Si empieza a fallar el fixture bueno, el problema es el gate, no el brief.

#Declarar fuentes GSC/Ahrefs como used/unavailable/not_applicable sin inventar datos

Cada fuente externa (Google Search Console, Ahrefs) se declara con un estado: used si hay datos reales con fecha de consulta, unavailable si la integración no está instalada, not_applicable si no corresponde al caso. Nunca se rellena con un número estimado que parezca real. El hard check source_gsc / source_ahrefs bloquea cualquier brief que no declare esto explícitamente, así el gate impide tanto inventar datos como esconder que faltan.

#Integración del gate de evals en el pipeline editorial antes de publicar

El orden importa: research → brief → gate (hard checks + rubric) → redacción → eval del artículo final contra el mismo briefHash. Si el redactor recibe un brief sin pass: true o con un briefHash que no coincide con el que evaluó el gate, el paso correcto es detenerse y devolver el brief a reparación, no completar los huecos por su cuenta. Esa frontera (quién repara el brief vs. quién redacta encima) es la que evita que un modelo termine aprobando su propio trabajo sin evidencia verificable.

#Cómo aplicar esto hoy

1. Definí primero los hard checks que tu brief necesita (schema, placeholders, antigüedad de research, fuentes declaradas) y escribilos como funciones puras que devuelvan { id, pass, message }.
2. Corré el script contra un brief real y contra una variante rota a propósito, para confirmar que el piso bloquea y no solo aprueba.
3. Sumá el rubric semántico con piso por eje recién cuando los hard checks ya pasan, nunca antes.
4. Versioná el test suite (fixtures good/bad) junto al script del gate.
5. Conectá el gate al pipeline para que el paso de redacción verifique pass: true y el briefHash antes de escribir una línea.

#Links útiles

• Catálogo evaluado de skills de Claude: 50 Claude Skills 2026
• Selección de skills recomendadas: Las mejores Claude Skills 2026
• Guía de Higgsfield conectado a Claude por MCP: Higgsfield + Claude para generar videos de campañas
• Skill-creator 2.0 de Anthropic: tessl.io
• Eval de dbt desde cero: rmoff.net
• A/B testing de skills: MindStudio
• Claude Skills para SEO y marketing: Ahrefs
• Harness binario de evals para skills (código, no contenido): j-rig-skill-binary-eval
• Misma regla de "no sé" aplicada a instrucciones personalizadas de ChatGPT: cómo hacer que ChatGPT deje de mentirte

Quiero aplicar a mi caso la guía "Cómo evaluar skills SEO de Claude Code con evals automáticos" de Claura.
Guía: https://claura-ai.com/resources/como-evaluar-skills-claude-code-seo-evals-automaticos

Mi caso: [a qué me dedico, qué herramientas uso y qué quiero lograr]

La guía cubre:
- ¿Qué significa evaluar un brief SEO, y por qué no es lo mismo que evaluar la skill
- El gap: 5 recursos evalúan la skill, ninguno evalúa el brief que produce
- Qué distingue un content gap específico y verificable (con evidencia y URL) de una queja genérica de tipo…
- Judges basados en reglas (hard checks) vs LLM-judge
- Estructura de evals.json / test cases con assertions verificables
- Checklist de implementación paso a paso
- Umbral de pass/fail y blockers accionables para un gate editorial
- Cómo mitigar la varianza entre corridas de un LLM-judge (multi-sample voting, calibración, umbral de…

Lee la guía (si no puedes abrir el link, trabaja con los temas de arriba). Si te falta información sobre mi caso, hazme hasta 3 preguntas antes de empezar. Después arma un plan para aplicar la guía paso a paso a mi caso y dime qué puedo hacer hoy en menos de una hora.

También te puede interesar50 Claude skills 2026 · de diseño, código y marketing por categoría

• evals claude code
• evaluar brief seo
• llm judge seo
• claude code skills eval
• pass fail brief editorial
• evals.json claude code