177 Skills and 100 Databases: What an AI Scientist Actually Needs

Number five on GitHub's weekly trending list this week wasn't a model. It was a directory of skills for scientists: 177 of them, covering biology, chemistry, medicine, and drug discovery, wired to more than 100 scientific databases. The repo claims 250,000 scientists use it. That number comes from the project itself and should be read as a vendor claim, but the star count — north of 53,000 on a repository created in October 2025 — is public and checkable.

The pitch is one sentence: turn any AI agent into an AI scientist. Why that sentence needs 177 files to be true is the part nobody explains.

Because the bottleneck was never the reasoning

Ask a frontier model to explain a protein folding pathway and it will do a decent job. Ask it to pull the actual structure for a specific Uniprot ID, cross-reference the associated variants against ClinVar, align them to a reference genome, and then plot the conservation scores — and it will produce something that looks like all of that and is partly invented.

The gap isn't intelligence. It's plumbing. Scientific work runs on a few hundred specialized databases and file formats, most of which have idiosyncratic APIs, and each of which is a place where a language model will confidently hallucinate a column name.

A skill, in this context, is a small package that knows one of those interfaces. What arguments a tool takes, what the response looks like, which identifiers are valid, what a sensible default is. It's the difference between telling an agent "look up the protein" and handing it a function that fails loudly when the ID is malformed.

What's actually in the 177

The repository's topic list is the most honest description available: bioinformatics, chemoinformatics, genomics, proteomics, metabolomics, clinical research, materials science, drug discovery, scientific computing, scientific visualization. Read that as a map of where the friction lives, not a list of capabilities.

Genomics is a good example of why the friction is high. A single analysis might touch a reference assembly, a variant database, an annotation track, and a statistical package, each with its own coordinate convention. Off-by-one errors in genomics are a genre of bug, not an accident. A skill that encodes "this database is 1-based, this one is 0-based" prevents an entire class of wrong answer that no amount of model capability fixes.

Chemistry has the same shape with more danger attached. SMILES strings, InChI keys, molecular weights, and assay thresholds all look like plain text and none of them are. An agent that treats a SMILES string as prose will produce a molecule that doesn't exist, formatted perfectly.

So the value proposition is unglamorous and real: these skills are a memory of interface details, maintained in one place, instead of a prompt preamble rewritten by every lab.

The distribution problem nobody solves

There's a quieter issue with bundling 177 skills into one repository. Version pinning. If a skill wraps a database whose API changes on its own schedule, the skill is a compatibility shim that decays. A lab that pins version 1.4 of the library and gets a working pipeline in March may find it broken in September, and the failure will look like a model problem rather than a dependency problem.

The software world solved this with lockfiles and semantic versioning, over about fifteen years, badly. Scientific software has neither, and it's now importing a dependency graph it didn't ask for.

"Validated" is the word to press on

The repository describes its skills as validated. That's a strong word for a category with no shared standard, and it's worth asking what the validation consists of. Tested against known outputs? Reviewed by a domain expert? Or simply run once without crashing?

All three are reasonable, and they mean very different things. For a database connector, "returns the right record for a known query" is a real test. For an analysis skill that recommends a statistical method, no test settles it, because the correct method depends on the experimental design.

This is where domain skills differ from the coding skills that filled trending lists earlier this year. A skill that formats a diff can be checked mechanically. A skill that decides whether to use a t-test or a mixed model cannot, and shipping it inside a package with 176 validated siblings implies a level of assurance it may not have.

The compatibility list is the strategy

The repository says it works with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard. That list is more interesting than the feature set. A skills library that runs on one agent is a feature of that agent. A skills library that runs on six is infrastructure, and infrastructure gets adopted by people who don't want to bet on which agent wins.

It also puts the library in an awkward position. The open Agent Skills standard is young, and every host implements it slightly differently — where skills live, how they're discovered, what permissions they get. Maintaining 177 skills across six hosts is a support burden that scales faster than the skill count. That's usually where these projects either consolidate or quietly narrow to two platforms.

For a lab, though, the portability is the point. A postdoc who writes a skill for a mass-spec pipeline wants it to work in whatever tool the PI's grant pays for next year.

What this changes for a working scientist

Three things, in descending order of how soon they'll matter.

First, the boring win: literature and database lookup stops being a place where the model invents citations. If a skill queries the actual index, the reference is real or the call fails. That's a measurable improvement in a workflow that currently costs hours of verification.

Second, reproducibility gets a new artifact. A pipeline assembled from named skills with pinned versions is more reproducible than a chat log, because it can be rerun. Whether anyone actually pins versions is another matter, and the early evidence from software supply chains is not encouraging.

Third, and slowest: the division of labour changes. The scientist's job stops being "operate the tools" and becomes "decide which question is worth the compute." That's the version of AI-in-science everyone advertises. It arrives, if it arrives, through 177 unglamorous interface files rather than a breakthrough.

The thing to watch

Watch whether the skill count keeps growing or starts shrinking. A directory that adds skills forever is a content marketing operation. A directory that consolidates, deprecates, and publishes what broke is a tool that people depend on.

And watch whether any of these get cited in a paper's methods section. That's the moment a skill stops being a convenience and becomes part of the scientific record, with all the review obligations that implies. Nobody has had to solve that yet. Somebody will, probably within a year.