Claude Code: guía para devs, hooks, skills, SDK y CLI

Un evals.json vive adentro de la carpeta de la skill y guarda test cases: cada uno define un input (prompt o archivo de entrada) y una o más assertions binarias que evalúan a pass o fail, sin escalas de "más o menos bien". El skill-creator 2.0 de Anthropic corre estos casos con sub-agentes executor, grader, comparator y analyzer en paralelo, en 4 modos (Create, Eval, Improve, Benchmark). Para arrancar alcanza con 3 casos (positivo, negativo, edge case); para cobertura real, 20 a 50 casos priorizando diversidad de inputs por sobre volumen. La razón de usar binarias y no un score 1 a 10 es que son deterministas: mismo input, mismo resultado, sin necesidad de una segunda llamada a un LLM para arbitrar. Más sobre el skill-creator en tessl.io y el catálogo completo en 50 Claude Skills 2026.

Un judge basado en reglas corre código determinista (regex, largos mínimos, URLs válidas) y siempre da el mismo resultado; un LLM-judge lee el contenido y puntúa criterios subjetivos como el ángulo o la profundidad del gap, con algo de varianza entre corridas. Lo binario pass/fail es más difícil de "hackear" con verbosidad que una escala 0 a 3, según la documentación de Promptfoo, que además permite fijar un threshold mínimo sobre el score 0 a 1 que devuelve el LLM. La combinación que funciona en producción es hard checks de reglas primero (bloquean rápido y gratis) y recién si pasan esos, un rubric semántico con LLM-judge y un piso mínimo por eje, no un promedio total que puede tapar un eje débil.

Corriendo el mismo brief varias veces contra el judge y exigiendo acuerdo entre corridas antes de tratarlo como gate definitivo, en vez de confiar en una sola pasada. El eval de dbt de rmoff.net documenta esto de forma honesta: su rúbrica de 9 criterios en escala 0 a 3 reconoce varianza entre jueces y no resuelve un umbral fijo. La práctica que sí funciona es tratar el resultado como un test compuesto, no un score único: combinar varios criterios (intent, gap, evidencia) y exigir que cada uno supere su propio piso, más una revisión humana periódica del juez para detectar cuándo se desvía. Fijar el gate sobre un solo run de un LLM-judge sin ese chequeo es apostar a que no hubo un día de mala suerte en el sampling.

Tiene que anclarse a algo que la competencia no pueda replicar sin acceso a los mismos datos: código propio, analítica propietaria de la marca o un ángulo verificado con evidencia externa, no solo "somos más completos". El artículo de Ahrefs sobre Claude Skills cubre la librería de skills de marketing (gap de contenido, brand sentiment) pero no explica cómo blindar ese take contra la generalidad. Un unique take fuerte cita su propia prueba (por ejemplo, un script que cualquiera puede correr y verificar) y un dato real de Search Console o analytics de la marca, no una promesa sin fuente. Mirá cómo se arma un catálogo evaluado de skills en las mejores Claude Skills 2026.

El riesgo real es que un rubric mal calibrado rechace un brief bueno porque un solo eje quedó débil por una razón menor, no porque el brief sea malo. Se mitiga con rubrics de 3 a 7 criterios (más criterios generan "criterion bleed" y score inflation, según Galtea) y con un piso por eje bajo pero real (16 sobre 20, no 19) combinado con un total mínimo más alto (85), de forma que un brief flojo en un solo punto pueda repararse ahí puntualmente en vez de reescribirse entero. El costo de mantenimiento se controla versionando la rúbrica junto al código del gate y corriendo un test suite fijo (fixtures good/bad) cada vez que se toca un check, para confirmar que el piso sigue bloqueando lo que tiene que bloquear sin volverse más estricto de lo pensado.