Scientific Agent Skills: 163 skills con contrato en CI

Abre tu carpeta de skills. Ahora mismo.

ls ~/.claude/skills/

Si eres de los que llevan meses instalando cosas, ahí dentro hay entre 10 y 40 carpetas. Algunas las escribiste tú un viernes por la tarde. Otras las copiaste de un repo que viste en X. ¿Cuántas de ellas tienen tests? ¿Cuántas siguen apuntando a una API que ya no existe? ¿Cuánto contexto te están comiendo solo por estar ahí?

No lo sabes. Yo tampoco lo sabía de las mías.

Existe un repositorio que sí lo sabe de las suyas. Se llama Scientific Agent Skills, lo mantiene la empresa K-Dense, y tiene 163 skills en un solo sitio. Skills de genómica, de cristalografía, de espectrometría de masas, de computación cuántica. Nada que vayas a usar para montar un CRUD en Next.js.

Y aun así lleva semanas abierto en una pestaña de mi navegador.

Lo que vale de ese repo no son las skills, es el contrato que las rodea. Un conjunto de reglas verificadas en CI que decide qué entra, cuánto puede ocupar, qué tiene que traer y qué se rechaza sin discusión. Es el manual de operaciones que a tu carpeta de skills le falta, escrito por gente que ha tenido que gobernar 163 de ellas sin que el agente colapse.

Esto es lo que vamos a mirar:

• Las cifras reales del repo, medidas sobre el código, no sacadas del README
• Cuánto contexto te cuesta instalar 163 skills (spoiler: unos 16.000 tokens antes de usar ninguna)
• Las 10 reglas que su CI comprueba en cada skill, una por una
• El bug de los 40 _common.py y cómo lo resolvieron negándose a ejecutar los tests
• Por qué publican un informe de seguridad con 34 hallazgos críticos en vez de esconderlo
• Las seis reglas que puedes copiar mañana a tu repo, aunque tu dominio sea el frontend

Si vienes del post sobre las 754 skills de ciberseguridad, aquello iba de cobertura: cuántos dominios cubre una colección enorme. Esto va de lo contrario. Va de qué le impide a una colección enorme convertirse en un vertedero.

¿Qué es Scientific Agent Skills y por qué tiene 163 skills? ¶

Es una colección de Agent Skills para investigación científica, publicada bajo licencia MIT y compatible con cualquier agente que entienda el estándar abierto agentskills.io: Claude Code, Cursor, Codex, Gemini CLI, Google Antigravity y compañía.

Antes se llamaba Claude Scientific Skills. Le cambiaron el nombre cuando dejó de ser específico de Claude, que es una señal bastante honesta de hacia dónde va el ecosistema.

Las cifras, medidas sobre el repo en la versión 2.65.0 (último commit del 29 de agosto de 2026):

Fíjate en las tres últimas filas de la tabla, porque ahí está el argumento entero del post: 105 skills envían scripts y hay 107 suites de test. No es casualidad ni buena voluntad. Es una regla de CI que bloquea el pull request.

El contenido cubre bioinformática, quimioinformática, proteómica, imagen médica, ciencia de materiales, física, astronomía, geoespacial y automatización de laboratorio. Una skill llamada database-lookup da acceso a 78 bases de datos públicas con contratos de recuperación explícitos. Otras cuatro (docx, pdf, pptx, xlsx) están hechas por Anthropic y se importan aquí dando crédito y siguiendo el upstream.

🔑 El repo es a la vez un paquete de Agent Plugins 1.0.0: un plugin.json en la raíz más el árbol skills/. Cualquier cliente compatible carga la colección entera como un solo plugin.

Si nunca has escrito una skill y esto te suena a chino, empieza por la guía de Agent Skills para programadores. Aquí doy por hecho que ya sabes qué es un SKILL.md.

¿Cuánto contexto te cuesta de verdad tener 163 skills instaladas? ¶

Unos 16.000 tokens. Y no los recuperas hasta que desinstalas.

Ese número no viene en ningún README, así que lo he medido yo. El mecanismo es sencillo: tu agente no carga el cuerpo de cada SKILL.md al arrancar, pero sí carga el name y el description de todas para poder decidir cuál activar. Ese catálogo vive en tu ventana de contexto durante toda la sesión.

Puedes reproducir la medición en cualquier repo de skills con esto:

import re, pathlib

total = 0
for skill in sorted(pathlib.Path("skills").iterdir()):
    fichero = skill / "SKILL.md"
    if not fichero.is_file():
        continue
    texto = fichero.read_text(encoding="utf-8")
    # El frontmatter va entre los dos primeros delimitadores
    frontmatter = re.search(r"^---\n(.*?)\n---", texto, re.S)
    if not frontmatter:
        continue
    campo = re.search(
        r"^description:\s*(.*?)(?=\n[a-z-]+:|\Z)",
        frontmatter.group(1), re.S | re.M
    )
    if campo:
        total += len(" ".join(campo.group(1).split()))

print(f"{total} caracteres, ~{total // 4} tokens")

Sobre Scientific Agent Skills devuelve 65.700 caracteres, unos 16.400 tokens. La descripción media ocupa 403 caracteres. La más corta es la de esm con 139. La más larga, experimental-design, se queda en 1.013.

Ese 1.013 no es casualidad. La especificación de Agent Skills limita description a 1.024 caracteres, y ninguna de las 163 se pasa. Están apurando el límite hasta el último byte, porque la descripción es lo único que el agente lee para decidir si activa la skill o no. Es el mismo principio que expliqué en buenas prácticas para escribir skills: el description no es documentación, es el criterio de selección.

El propio README lo dice sin rodeos: “Because 163 skills add up to a lot of standing context, consider installing a topical subset rather than the whole collection”. Un repo que te pide que no lo instales entero merece un mínimo de confianza.

⚠️ 16.400 tokens de catálogo no solo te ocupan sitio. Empeoran la selección: cuantas más descripciones compiten, más probable es que el agente active la equivocada. El coste de una skill de más no es el que ves en la factura.

Curso gratis · paso a paso

El método que le falta a tu agente cuando no hay contrato

Ocho lecciones para recorrer el ciclo completo de SDD con OpenSpec sobre un proyecto de juguete: propuesta, spec, diseño, tareas y archivar. En modo asistido, para verlo entero antes de coger tú el volante.

Entra en el curso gratis →

¿Qué comprueba su CI en cada una de las 163 skills? ¶

Diez reglas, definidas en un único fichero (tests/_contract/structure.py) y aplicadas a todas las skills a la vez desde tests/_meta. Aquí están, con lo que hace cada una:

Dos decisiones de implementación valen más que la lista entera.

Los scripts se parsean con ast, nunca se ejecutan. Eso permite pasar el contrato entero sobre las 163 skills dentro de un único intérprete, en segundos, sin instalar una sola dependencia científica. El comentario del fichero lo deja claro: “Nothing here imports skill code.”

Cada check devuelve una lista de problemas legibles en vez de lanzar un assert. El comentario explica por qué: así el mismo check sirve para el informe repo-wide y para una suite individual, y un enlace roto te dice el fichero y la línea en vez de reventar con un AssertionError opaco.

# Extracto real del contrato: el registro de reglas
CHECKS: dict[str, Callable[[Path], list[str]]] = {
    "frontmatter": frontmatter_problems,
    "skill_md_length": length_problems,
    "no_tests_under_skills": stray_test_problems,
    # ...
}

Añadir una regla nueva a las 163 skills es añadir una entrada a ese diccionario. Nada más.

El check de rutas personales detecta /home/loquesea/ y /Users/loquesea/, pero mantiene una lista de cuentas que sí son legítimas en documentación: dnanexus, ubuntu, runner, ec2-user, jovyan, vscode, airflow, nextflow. Porque /home/dnanexus/ no es el portátil de nadie, es donde ejecuta un worker de DNAnexus.

Esa clase de excepción no la escribes el primer día. La escribes después de que el check te dé el tercer falso positivo.

¿Por qué un SKILL.md no puede pasar de 500 líneas? ¶

Porque cada línea de más es contexto que el agente carga aunque no lo necesite.

La regla es simple: SKILL.md bajo 500 líneas, y todo lo largo se mueve a references/, que el agente lee solo cuando le hace falta. Divulgación progresiva, medida en líneas para que nadie tenga que opinar sobre si un fichero es largo.

Funciona. La media de las 163 es de 288 líneas, y el fichero más largo del repo (imaging-data-commons) se queda en 496. Nadie está pegado al techo por accidente. Mientras tanto, hay 1.235 ficheros Markdown en total: por cada SKILL.md hay unos seis ficheros de referencia esperando su turno.

Mira la anatomía de rdkit, la skill de quimioinformática:

skills/rdkit/
├── SKILL.md                 # 94 líneas: cuándo usarla, instalación, índice
├── references/
│   ├── api_reference.md
│   ├── core_capabilities.md
│   ├── descriptors_reference.md
│   ├── smarts_patterns.md
│   └── workflows_and_best_practices.md
└── scripts/
    ├── molecular_properties.py
    ├── similarity_search.py
    └── substructure_filter.py

94 líneas en el fichero que siempre se carga. Todo lo demás, bajo demanda. Y en el cuerpo, en vez de reproducir la documentación de RDKit, una línea que apunta al sitio:

“Twelve capability areas, each with worked code, are documented in references/core_capabilities.md”

El AGENTS.md del repo añade una regla que va en la misma dirección y que yo he incumplido más de una vez: “Give concrete workflows, commands, and worked examples rather than background explanation”. Nada de explicarle al modelo qué es un PDF. Ya lo sabe.

💡 Si tu SKILL.md pasa de 500 líneas, no tienes una skill grande. Tienes dos skills, o una skill y un references/ que todavía no has creado.

¿Qué pasa cuando 40 skills llaman igual a su módulo interno? ¶

Que tus tests pasan en verde mientras prueban el fichero equivocado. Y ese es el bug que más me ha gustado del repo.

En Scientific Agent Skills hay 40 skills que envían un scripts/_common.py. Son nombres de módulo de primer nivel, planos, sin namespace. Si pytest colecta dos de esas skills en el mismo intérprete, el import _common de la segunda resuelve al _common de la primera, que ya está en sys.modules.

No falla. Pasa. Verde. Probando otro fichero.

La solución no fue renombrar 40 ficheros ni inventarse un sistema de paquetes. Fue que tests/conftest.py se niega a arrancar una sesión que colecte más de una skill:

cannot collect N skills in one process: their scripts/ directories share
module names (_common.py and friends), so imports would resolve to the
wrong skill. Run one skill at a time with ...

Y un tests/run_all.py que hace fork por skill cuando quieres pasarlas todas. Cambiaron un fallo silencioso por un error ruidoso que te dice qué escribir en su lugar, sin tocar una sola línea de las 40 skills.

El comentario del conftest.py dice 32 skills con _common.py. Hoy son 40. La documentación envejece incluso en el repo que más disciplina tiene de los que he mirado. Por eso el check está en el código y no en el AGENTS.md.

¿Cómo testeas una colección donde las dependencias se pelean entre ellas? ¶

Con un entorno desechable por skill. Es la única salida cuando los pines son mutuamente excluyentes, y en este repo lo son de una forma casi cómica:

• opentrons necesita numpy<2
• esm limita transformers por debajo de la versión que documenta la skill transformers
• geniml y spikeinterface fijan zarr<3, justo contra el 3.x que documenta la skill zarr-python
• bioservices limita lxml<6, contra lo que necesita matchms
• pytdc, molfeat, deepchem, histolab, vaex y ete3 necesitan un intérprete anterior a 3.13

Instalar todo eso junto no es difícil. Es imposible: cada uno de esos paquetes obliga a otro a perder la pelea de versiones.

La solución es un tests/skill-requirements.toml donde cada skill declara sus paquetes y, si hace falta, su versión de Python. Luego uv construye un entorno de usar y tirar para cada una:

# Todas las suites, un entorno por skill
python tests/run_all.py --isolated

# Solo estas dos
python tests/run_all.py --isolated scanpy qiskit

Lo que más me gusta es la sección [unavailable] de ese TOML. Los paquetes que no se pueden instalar de ninguna manera —un SDK que solo vive en GitHub, una librería que solo está en conda-forge, una build que exige CUDA— se registran ahí con el motivo, y el runner los imprime al terminar.

Así el hueco aparece declarado en la salida de los tests, en vez de quedarse como una skill sin cobertura que nadie recuerda por qué no la tiene.

🛡️ La versión web de esta idea: si tienes un test que no puedes ejecutar en CI, no lo borres ni lo dejes en skip mudo. Déjalo con el motivo escrito y haz que el runner lo cante en cada ejecución.

Y ojo, el barrido completo con --isolated no se ejecuta en CI. Varias skills necesitan una toolchain CUDA, un JDK o una instalación local de MATLAB. Se ejecuta antes de una release o cuando alguien toca el contrato compartido. Lo que sí pasa en cada PR es tests/_meta: pura biblioteca estándar, un par de segundos, y bloquea el merge.

Esa separación entre lo que se ejecuta en cada PR y lo que se ejecuta antes de publicar vale para cualquier monorepo, tenga o no skills dentro.

Escribe las tuyas mejor

Las skills que escribes tú también merecen un contrato

Verás cómo montar un SKILL.md que el agente activa cuando toca: divulgación progresiva, referencias que solo se leen si hacen falta y scripts que no gastan contexto. Te llevas plantillas descargables para empezar hoy.

Abrir la guía →

Plantillas SKILL.md descargables · Con suscripción Web Reactiva Premium

¿Qué skills rechaza este repo y por qué te importa? ¶

Rechaza cuatro categorías, y las tiene escritas en el AGENTS.md para no tener que discutirlas en cada pull request:

1. Skills generales de ingeniería de software o de criterio al programar. Motivo: “they compete for selection on every task”. Una skill que puede activarse siempre compite con las 162 restantes en cada petición.
2. Infraestructura general con un ejemplo científico pegado encima. Una base de datos vectorial, un SDK de cloud. Motivo: aceptar una obliga a cargar con todas sus competidoras.
3. Skills “orquestadoras” que enrutan a otras skills. Motivo: solapan con todos los especialistas por diseño.
4. Un segundo proveedor para un servicio que ya cubre otra skill.

La regla 1 es la que deberías apuntar. Las skills genéricas —esas de “escribe buen código”, “revisa mis tests”, “sé riguroso”— parecen inofensivas porque no ocupan mucho. El daño no está en su tamaño, está en que entran en el sorteo de la activación siempre, y cada activación mala se lleva por delante a la skill que sí tocaba.

Es un problema de precisión, no de espacio en disco. Y se defiende con una política de alcance escrita antes de tener 40 skills, no después.

El repo se guarda una excepción declarada: sí acepta helpers de formato de salida muy estrechos (docx, pdf, pptx, generate-image, markdown-mermaid-writing). Y añade la frase que evita que la excepción se convierta en agujero: “They are not precedent for broadening scope.”

Si te interesa cómo Anthropic ordena su propio catálogo por categorías, lo desmenucé en cómo organiza Claude sus skills.

¿Qué dice el informe de seguridad que publican en abierto? ¶

Dice que 34 de sus 163 skills tienen hallazgos críticos. Y lo publican en el repo, en docs/security-report.md, con nombre y apellidos.

Los números del informe del 24 de agosto de 2026:

El escaneo se ejecuta cada lunes a las 09:00 UTC mediante GitHub Actions. Es incremental —las skills que no han cambiado arrastran sus hallazgos anteriores— con un rescaneo completo al menos cada 30 días y siempre que cambie el escáner o el modelo. En los pull requests, un workflow aparte escanea solo las skills tocadas y falla si sale algo HIGH o superior.

El AGENTS.md documenta además los falsos positivos sistemáticos del escáner, para que nadie “arregle” código sano por miedo.

• BEHAVIOR_*_EXFILTRATION y BEHAVIOR_ENV_VAR_HARVESTING saltan en cualquier skill que lea su propia API key y llame a su propio servicio
• MDBLOCK_PYTHON_SUBPROCESS salta con cualquier subprocess, incluida la forma segura con lista de argumentos
• *_EVAL_EXEC salta con subcadenas dentro de identificadores normales (retrieval, executor) y con model.eval()

Y una advertencia que vale para cualquier herramienta de análisis con LLM detrás: “Findings sometimes cite files a skill does not contain — check against find skills/<name> -type f before acting.”

⚠️ Un escáner de skills con modelo detrás alucina ficheros. Verifica el hallazgo contra el código antes de tocar nada. Un arreglo a ciegas de un falso positivo deja el repo peor que el falso positivo.

Conviene decir la parte incómoda: este repo tiene skills con hallazgos críticos abiertos. Lo saben, lo publican y lo repiten en el README, junto a la recomendación de no instalarlo entero y de leer el SKILL.md antes de instalar nada. Prefiero eso a un repo que no escanea y por tanto no tiene nada que reportar.

Puedes ejecutar el escáner tú mismo sobre cualquier skill de terceros antes de instalarla:

uv pip install cisco-ai-skill-scanner
skill-scanner scan /ruta/a/la/skill --use-behavioral

¿Cómo lo instalas sin tragarte las 163 skills? ¶

Instalando las que necesitas, una a una. Hay tres caminos según tu agente.

Con npx, para hosts compatibles con el estándar (Claude Code, Codex, Gemini CLI, Cursor, Antigravity):

npx skills add K-Dense-AI/scientific-agent-skills

Con la CLI de GitHub (v2.90.0 o superior), que es la opción fina porque te deja elegir skill y destino:

# Navegar e instalar de forma interactiva
gh skill install K-Dense-AI/scientific-agent-skills

# Solo una skill concreta
gh skill install K-Dense-AI/scientific-agent-skills scanpy

# Y para tu agente concreto
gh skill install K-Dense-AI/scientific-agent-skills --agent cursor

Fijando la versión, que es lo que deberías hacer si esto entra en un flujo de trabajo del que dependen otras personas:

gh skill install K-Dense-AI/scientific-agent-skills --pin v2.65.0
gh skill update --all

gh skill instala en la ruta correcta según el host y registra metadatos de procedencia para la cadena de suministro. Que es exactamente lo que quieres cuando estás metiendo instrucciones ejecutables de un tercero en tu agente.

Y como el repo es un paquete de Agent Plugins válido, en Cursor puedes enlazarlo entero:

mkdir -p ~/.cursor/plugins/local
ln -s "$(pwd)" ~/.cursor/plugins/local/scientific-agent-skills

Aunque después de todo lo anterior, ya sabes que enlazar las 163 de golpe es justo lo que el propio repo te pide que no hagas.

¿Qué seis reglas puedes copiar mañana a tu repo de skills? ¶

Ninguna de estas seis depende de que trabajes con genomas. Todas caben en un repo de skills de frontend, de backend o de lo que tengas.

1. Pon un techo de líneas al SKILL.md y verifícalo. 500 es un buen número de partida. Todo lo que se pase va a references/. Son diez líneas de test y te ahorra que una skill se coma tu ventana de contexto en silencio.

2. Si la skill envía scripts/, envía tests. Y que el CI lo compruebe, no el revisor. Es la única regla del repo que tiene su propio test dedicado, y es la que mantiene 105 carpetas de scripts con 107 suites detrás.

3. Parsea, no ejecutes. Comprobar 163 skills con ast cuesta segundos y cero dependencias. Si tu check necesita importar el código de la skill, no es un check estructural, es un test de integración y va en otro sitio.

4. Escribe la política de alcance antes de la skill número 10. Qué aceptas, qué rechazas y por qué. Sobre todo: nada de skills genéricas que compiten por activarse en todas las peticiones.

5. Declara lo que no puedes probar. Una sección [unavailable] con el motivo, impresa en cada ejecución, vale más que un skip mudo que nadie mira desde hace ocho meses.

6. Mide tu catálogo, no lo estimes. Ejecuta el script de más arriba sobre tu carpeta de skills. Si el resultado te sorprende, ya sabes qué desinstalar esta tarde.

Ese último punto es el que te va a dar el retorno más rápido. Yo lo ejecuté sobre mi propia carpeta después de escribir este post y desinstalé cuatro skills que no había usado desde marzo.

TL;DR ¶

• 🧬 Scientific Agent Skills reúne 163 skills científicas bajo licencia MIT, compatibles con Claude Code, Cursor, Codex y cualquier host del estándar agentskills.io
• ⚡ Tener las 163 instaladas cuesta ~16.400 tokens de contexto permanente solo en descripciones, antes de activar ninguna: mide tu carpeta con el script del post
• 🔧 Su CI verifica 10 reglas estructurales en cada skill parseando con ast, sin ejecutar código, en segundos y sin dependencias científicas
• 🧪 La regla que sostiene todo: si una skill envía scripts/, tiene que traer su suite en tests/<nombre>/, y el merge se bloquea si falta
• 🛡️ Publican su informe de seguridad completo (988 hallazgos, 34 críticos) y documentan los falsos positivos del escáner para que nadie arregle código sano

Preguntas frecuentes sobre Scientific Agent Skills ¶

¿Scientific Agent Skills funciona solo con Claude Code?
No. Antes se llamaba Claude Scientific Skills, pero ahora sigue el estándar abierto de agentskills.io y funciona con Cursor, Codex, Gemini CLI, Google Antigravity y cualquier host compatible. El repo es además un paquete Agent Plugins 1.0.0 válido.

¿Puedo instalar solo una skill del repo?
Sí, y es lo recomendado. Con gh skill install K-Dense-AI/scientific-agent-skills scanpy instalas una sola. El propio README desaconseja instalar la colección completa por el coste de contexto.

¿Cuánto contexto consumen 163 skills instaladas?
El catálogo de nombres y descripciones que tu agente mantiene cargado suma unos 65.700 caracteres, alrededor de 16.400 tokens. El cuerpo de cada SKILL.md solo se carga cuando la skill se activa.

¿Por qué limitan los SKILL.md a 500 líneas?
Para forzar divulgación progresiva: lo esencial en SKILL.md, el material largo en references/ que el agente lee bajo demanda. La media real del repo es de 288 líneas y ningún fichero llega a 500.

¿Qué campos admite el frontmatter de una Agent Skill?
Solo seis: name, description, license, compatibility, allowed-tools y metadata. Cualquier otra clave de primer nivel es un error de validación que tumba el documento entero, incluidos name y description.

¿Por qué allowed-tools da problemas tan a menudo?
Porque es una cadena separada por espacios (Read Write Edit Bash), no una lista YAML ni valores separados por comas. El validador de referencia usa strictyaml, que además rechaza el estilo JSON en línea para metadata.

¿Es seguro instalar skills de terceros?
Solo si las revisas. Una skill puede ejecutar código, instalar paquetes y hacer peticiones de red. Lee el SKILL.md antes de instalar y escanea con skill-scanner scan <ruta> --use-behavioral si viene de fuera.

¿Qué significa que una skill tenga hallazgos críticos en el informe?
Que el escáner con LLM detectó patrones compatibles con inyección de prompts, exfiltración o código malicioso. No todos son reales: el repo documenta falsos positivos sistemáticos, como que model.eval() dispare la regla de ejecución dinámica.

¿Cómo evito que dos skills con scripts homónimos rompan mis tests?
Ejecutando una skill por proceso. Si varias envían un scripts/_common.py, el import de la segunda resuelve al módulo de la primera y el test pasa en verde probando el fichero equivocado.

¿Sirve algo de este repo si programo para web y no hago ciencia?
Las skills no, pero el andamiaje sí: el contrato estructural en CI, el techo de líneas, la regla de tests obligatorios para skills con scripts y la política de qué skills se rechazan son aplicables a cualquier colección de skills.

Fuentes ¶

• Scientific Agent Skills en GitHub — repositorio, README y AGENTS.md (v2.65.0)
• Informe de seguridad del repo — escaneo semanal publicado en abierto
• Especificación de Agent Skills — estándar abierto de frontmatter y estructura
• Estándar Agent Plugins 1.0.0 — manifiesto plugin.json y clientes compatibles
• Cisco AI Defense Skill Scanner — escáner de seguridad para Agent Skills
• gh skill en la CLI de GitHub — instalación y fijado de versiones

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter