🎯 Precisión de activación: la señal invisible
Los principiantes se fijan en si la skill se activa. Los expertos se fijan en si se activa en los casos adecuados y no en los near-misses. Una skill que se activa para una tarea parecida, pero equivocada, inyecta contexto irrelevante y degrada la respuesta: es peor que no activarla.
✓ Activación precisa
- ✓Se activa con los should-trigger (alta cobertura)
- ✓No se activa en casos cercanos (alta precisión)
- ✓postgres-skill NO se activa con "mongo query"
✗ Activación imprecisa
- ✗Se activa con cualquier mención de "database"
- ✗Un falso positivo consume contexto y confunde
- ✗Falso negativo: nunca aparece cuando hace falta
💡 Consejo profesional
Crea un conjunto de should-trigger y should-NOT-trigger (los near-misses). Una description solo está bien cuando acierta en ambos casos. Optimiza contra los near-misses, no solo contra los aciertos obvios.
🪙 Economía de tokens y contexto
La description permanece siempre en el contexto (nivel 1). El cuerpo entra cuando se activa (nivel 2). Los recursos incluidos solo bajo demanda (nivel 3). Una skill que consume muchos tokens les quita espacio a todas las demás; los expertos miden eso.
| Nivel | Qué lleva | Cuándo |
|---|---|---|
| 1 | name + description (~100 palabras) | siempre en el contexto |
| 2 | cuerpo del SKILL.md (<500 líneas) | cuándo se activa |
| 3 | scripts / references / assets | bajo demanda |
El costo oculto de las skills siempre activas
Cada descripción instalada consume contexto todo el tiempo. 30 skills con descripciones infladas = miles de tokens gastados antes de cualquier tarea. Por eso una descripción densa y breve no es una cuestión estética: es presupuesto.
💡 Consejo profesional
Lleva todo lo que no sea un disparador al nivel 3 (bundled). Si el detalle no se lee en cada invocación, no pertenece al cuerpo: se convierte en un archivo que se carga bajo demanda.
📜 Leer transcripts para encontrar trabajo desperdiciado
La señal que nadie ve en skills.sh está en el tu propio transcript. Relee una sesión real: ¿dónde repitió el agente lo mismo, pidió confirmación sin motivo o ignoró la skill que debería haber usado? Ahí está el trabajo desperdiciado.
Busca repeticiones
¿El agente reescribió el mismo código boilerplate tres veces? Conviértelo en un script bundled de la skill.
Busca casos en los que no se activa
¿La skill adecuada existía y no se activó? La description es débil en el CUÁNDO: ajusta el trigger.
Busca activaciones incorrectas
¿Apareció una skill sin necesidad? Near-miss: ajusta la description para excluirla.
💡 Consejo profesional
El transcript es el mejor eval gratis que existe. Antes de instalar más skills, lee una sesión y pregúntate: ¿qué se repitió? ¿Qué falló en silencio? Cada patrón es un ajuste de skill.
📊 Pass-rate de evals y assertions no discriminantes
Un eval que siempre pasa no mide nada. La señal de expertise es la assertion discriminante: una que fallo sin la skill y pasa con ella. Si el baseline ya pasa, la assertion no está midiendo la contribución de la skill.
✗ Assertion no discriminante
assert output.contains("function")
# passa com OU sem a skill → inútilUn pass-rate del 100% que no distingue entre el baseline y el resultado con skill da una falsa sensación de seguridad.
✓ Assertion discriminante
assert migration.has_down_step() # falha sem a skill, passa com ela ✓
Mide exactamente el comportamiento que la skill debería aportar.
la prueba de evaluación honesta:
baseline (sem skill) → pass-rate 30% com a skill → pass-rate 90% delta = 60pp → a skill comprovadamente ajuda baseline 95% / com-skill 96% → assertion não discrimina
💡 Consejo profesional
Ejecuta siempre el baseline. Un pass-rate alto solo importa si el baseline es bajo. El número que cuenta es el delta entre con skill y sin skill.
🎲 Variabilidad e inestabilidad
Una ronda de eval no basta. El modelo es estocástico: la misma skill puede pasar en una ejecución y fallar en la siguiente. Los expertos ejecutan el eval varias veces y observan la variabilidad: una tasa de aprobados del 90% con mucha inestabilidad es menos confiable que una del 80% estable.
la misma skill, 5 ejecuciones:
skill A: 90 88 91 89 90 → média 89,6 σ baixo → confiável skill B: 100 60 95 55 90 → média 80,0 σ alto → flaky
✓ Cómo reducir la flakiness
- ✓Instrucciones imperativas e inequívocas
- ✓Explicar el porqué (el agente generaliza de forma más estable)
- ✓Ejecutar N veces e informar el promedio + la desviación
✗ Señales de inestabilidad
- ✗El resultado cambia mucho entre ejecuciones
- ✗Instrucciones ambiguas o contradictorias
- ✗Evaluar en una sola ronda
💡 Consejo profesional
Reporta siempre el promedio ± desviación, nunca un número aislado. La estabilidad es calidad: prefiere la skill consistente a la que a veces destaca y a veces se desploma.
⚠️ Cuando una skill popular sigue siendo mala
Un número alto de instalaciones no es una prueba. Recuerda la ley de potencias: las top 100 = 43,7% de todas las instalaciones y solo 0,3% (131 skills) superan los 100k — hay sesgo de pionero y efecto de marca. Una skill popular puede ser mala para ti.
✗ Popular pero problemática
- ✗100k instalaciones, pero sin commits desde hace un año (abandonada)
- ✗Alcance inflado que se activa en el flujo equivocado
- ✗Para otro stack — popular en React, inútil en tu Vue
- ✗Hype de early-mover, no calidad sostenida
✓ Qué revisar además de la instalación
- ✓Último commit reciente, issues respondidos
- ✓Compatibilidad con TU stack y flujo
- ✓Triggering preciso en tu caso real
- ✓Delta de eval en tu transcript, no en el hype
El cambio de mentalidad del experto
Un principiante instala por el número alto. Un experto instala según la evidencia en el propio flujo: activación precisa, bajo costo de contexto, mejora real en las evaluaciones, mantenimiento activo y compatibilidad con el stack. El número de instalaciones es donde tú empieza a investigar; nunca dónde termina.
✅ Resumen del módulo
Próximo:
Trilha 3 — 🧬 Anatomía de una Skill. Ya sabes evaluar, crear y reconocer las señales sutiles; ahora abriremos el SKILL.md por dentro: frontmatter, cuerpo y progressive disclosure.