177 skills y 100 bases de datos: lo que un científico con IA realmente necesita

El quinto puesto de las tendencias semanales de GitHub esta semana no era un modelo. Era un directorio de skills para científicos: 177, que cubren biología, química, medicina y descubrimiento de fármacos, conectados a más de 100 bases de datos científicas. El repo afirma que lo usan 250.000 científicos. Esa cifra viene del propio proyecto y hay que leerla como una declaración del proveedor, pero el número de estrellas —más de 53.000 en un repositorio creado en octubre de 2025— es público y verificable.

El argumento cabe en una frase: convierte cualquier agente de IA en un científico de IA. Por qué esa frase necesita 177 archivos para ser cierta es la parte que nadie explica.

Porque el cuello de botella nunca fue el razonamiento

Pídele a un modelo de frontera que explique una ruta de plegamiento de proteínas y lo hará decentemente. Pídele que traiga la estructura real de un ID de Uniprot concreto, que cruce las variantes asociadas con ClinVar, que las alinee contra un genoma de referencia y que luego grafique los scores de conservación: producirá algo que se parece a todo eso y que está en parte inventado.

Lo que falta no es inteligencia. Es fontanería. El trabajo científico corre sobre unos cientos de bases de datos y formatos de archivo especializados, la mayoría con APIs idiosincrásicas, y cada uno es un lugar donde un modelo de lenguaje alucinará un nombre de columna con total confianza.

Un skill, en este contexto, es un paquete pequeño que conoce una de esas interfaces. Qué argumentos toma una herramienta, cómo se ve la respuesta, qué identificadores son válidos, cuál es un valor por defecto sensato. Es la diferencia entre decirle a un agente «busca la proteína» y entregarle una función que falla ruidosamente cuando el ID está mal formado.

{{INLINE1}}

Qué hay realmente en los 177

La lista de topics del repositorio es la descripción más honesta disponible: bioinformática, quimioinformática, genómica, proteómica, metabolómica, investigación clínica, ciencia de materiales, descubrimiento de fármacos, computación científica, visualización científica. Léela como un mapa de dónde vive la fricción, no como una lista de capacidades.

La genómica es un buen ejemplo de por qué la fricción es alta. Un solo análisis puede tocar un ensamblado de referencia, una base de variantes, una pista de anotación y un paquete estadístico, cada uno con su propia convención de coordenadas. Los errores off-by-one en genómica son un género de bug, no un accidente. Un skill que codifica «esta base cuenta desde 1, esta otra desde 0» evita toda una clase de respuestas incorrectas que ninguna capacidad del modelo arregla.

La química tiene la misma forma con más peligro. Las cadenas SMILES, las claves InChI, los pesos moleculares y los umbrales de ensayo parecen texto plano y ninguno lo es. Un agente que trate una cadena SMILES como prosa producirá una molécula que no existe, perfectamente formateada.

Así que la propuesta de valor es poco glamurosa y real: estos skills son una memoria de detalles de interfaz, mantenida en un solo sitio, en lugar de un preámbulo de prompt reescrito por cada laboratorio.

El problema de distribución que nadie resuelve

Hay un asunto más silencioso al empaquetar 177 skills en un solo repo. El pinneo de versiones. Si un skill envuelve una base de datos cuya API cambia a su propio ritmo, el skill es una capa de compatibilidad que se degrada. Un laboratorio que fija la versión 1.4 de la librería y tiene un pipeline funcionando en marzo puede encontrarlo roto en septiembre, y el fallo parecerá un problema del modelo más que un problema de dependencias.

El mundo del software resolvió esto con lockfiles y versionado semántico, en unos quince años, y mal. El software científico no tiene ni lo uno ni lo otro, y ahora está importando un grafo de dependencias que no pidió.

«Validado» es la palabra sobre la que hay que insistir

El repositorio describe sus skills como validados. Es una palabra fuerte para una categoría sin estándar compartido, y vale la pena preguntar en qué consiste la validación. ¿Probados contra salidas conocidas? ¿Revisados por un experto de dominio? ¿O simplemente ejecutados una vez sin romperse?

Las tres son razonables y significan cosas muy distintas. Para un conector de base de datos, «devuelve el registro correcto para una consulta conocida» es una prueba real. Para un skill de análisis que recomienda un método estadístico, ninguna prueba lo zanja, porque el método correcto depende del diseño experimental.

Aquí es donde los skills de dominio se separan de los skills de código que llenaron las listas de tendencias a principios de año. Un skill que formatea un diff se puede comprobar mecánicamente. Uno que decide si usar una t de Student o un modelo mixto, no. Y publicarlo dentro de un paquete con 176 hermanos «validados» implica un nivel de garantía que quizá no tiene.

La lista de compatibilidad es la estrategia

El repositorio dice que funciona con Cursor, Claude Code, Codex, Pi, Antigravity y el estándar abierto Agent Skills. Esa lista es más interesante que el conjunto de funciones. Una librería de skills que corre en un solo agente es una función de ese agente. Una que corre en seis es infraestructura, y la infraestructura la adoptan quienes no quieren apostar a qué agente ganará.

También deja a la librería en una posición incómoda. El estándar abierto Agent Skills es joven, y cada host lo implementa algo distinto: dónde viven los skills, cómo se descubren, qué permisos reciben. Mantener 177 skills en seis hosts es una carga de soporte que crece más rápido que el número de skills. Ahí es donde estos proyectos suelen consolidarse o reducirse discretamente a dos plataformas.

Para un laboratorio, sin embargo, la portabilidad es justamente el punto. Un postdoc que escribe un skill para un pipeline de espectrometría de masas quiere que funcione en la herramienta que pague la beca del PI el año que viene.

Qué cambia para un científico que trabaja

Tres cosas, en orden de cuán pronto importarán.

Primero, la victoria aburrida: la búsqueda de literatura y bases de datos deja de ser un lugar donde el modelo inventa citas. Si un skill consulta el índice real, la referencia es real o la llamada falla. Es una mejora medible en un flujo que hoy cuesta horas de verificación.

Segundo, la reproducibilidad gana un artefacto nuevo. Un pipeline armado con skills con nombre y versiones fijadas es más reproducible que un registro de chat, porque se puede volver a ejecutar. Que alguien fije versiones de verdad es otra cosa, y la evidencia temprana de las cadenas de suministro de software no es alentadora.

Tercero, y lo más lento: cambia la división del trabajo. El trabajo del científico deja de ser «operar las herramientas» y pasa a ser «decidir qué pregunta merece ese cómputo». Esa es la versión de la IA en la ciencia que todos anuncian. Llega, si llega, a través de 177 archivos de interfaz sin glamour y no de un descubrimiento.

Lo que hay que vigilar

Vigila si el número de skills sigue creciendo o empieza a encogerse. Un directorio que añade skills para siempre es una operación de content marketing. Un directorio que consolida, deprecia y publica qué se rompió es una herramienta de la que la gente depende.

Y vigila si alguno de estos acaba citado en la sección de métodos de un paper. Ese es el momento en que un skill deja de ser una comodidad y pasa a formar parte del registro científico, con todas las obligaciones de revisión que eso implica. Nadie ha tenido que resolverlo todavía. Alguien lo hará, probablemente en un año.