In my graduate seminar on generative AI for engineering research last semester, we spent a good deal of time on agent skills. They arrived at a natural point in the course sequence, after we had worked through AI-assisted coding and the ecosystem that is now rapidly maturing, with million-token context windows, and open standards like the Model Context Protocol (MCP). Simply put, skills capture expert workflows in a structured Markdown file, with metadata set in a standard frontmatter. But as I prepared to discuss their more technical core—the principle of progressive disclosure, how they can use scripts and references, the directory structure—I realized skills are not a product feature. They are computational artifacts in their own right. Indeed, they make up a new artifact class that people are sharing in the open-source model. I ended up dedicating a whole class to the topic of agent skills as shared infrastructure.
Packaging expertise into persistent, shareable, improvable SKILL.md files professionalizes AI-assisted work and contrasts with the ephemeral and casual nature of standard prompts. At the same time, the rapid proliferation of skills in open repositories, and the ease with which they can be installed and called, raise a familiar set of questions about quality, peer review, licensing, curation, and maintenance.
Three skills with nothing in common
Consider the following three examples, from widely separated fields.
The first example is one I built in class, from Kristin Sainani's course on writing in the sciences. Thirty video lectures from years ago encoded expert knowledge about how to cut clutter, when the passive voice is not a crutch, why terminology must stay consistent even when variety is tempting. In a workflow that chained several AI tools, I distilled and packaged that expertise so that an agent applies the same standards when asked to review a passage or manuscript. The agent then returns a structured report with findings tagged by severity, each with the original sentence and a suggested revision. A scholarly method, captured in a machine-actionable form.
The second example comes from a public repository of computational materials science skills. It encodes numerical stability analysis: when the stability condition dictated by the CFL number is at risk, what to do when a mesh quality metric sits just outside tolerance, when to reduce a time step rather than halt a run. The arithmetic happens in Python scripts that ship alongside the instructions, because a CFL number should be computed, not estimated. The skill supplies the reasoning, while the scripts supply the numbers.
The third example was written by Prof. Duncan Brown, Vice President for Research at Syracuse University, and it builds sponsored-research budgets. It knows Syracuse's fringe rates and its federally negotiated F&A agreement, the NIH salary cap, the NSF two-month rule, and how tuition remission differs by college. A principal investigator describes a proposal in plain English and gets back a populated budget Excel spreadsheet, checked against sponsor policy.
The examples cover scientific writing methodology, a numerical stability protocol of computational physics, and federal grant administration. These are three bodies of knowledge that have nothing in common: different disciplines, different communities, different kinds of expertise, accumulated over different decades by people who may never meet. Yet they are the same kind of file, published in public repositories, licensed, installable in a single step, and callable by any AI agent that implements the standard. That is the mark of an artifact class.
Not a product feature: an open-source artifact
My scientific writing skill already has more than a hundred forks. Duncan Brown created one fork that adds physics-specific writing discipline, drawing on Kip Thorne's and John Wheeler's advice to their students, along with conventions for handling equations as prose. He also documented the derivation in a HISTORY.md file recording how the new version was designed and what changed. That is real open-source practice. A general skill was specialized for a discipline, the license traveled with it, the provenance was written down, and the derived work carries a version number. In Duncan's words, the natural-language code was treated exactly as it would have been if it were a Python program he had forked and modified.
Skills are already being shared using open-source mechanisms: they are on GitHub, they carry a license, they invite contributions. In some cases, their authors are applying a versioning system; they are, after all, plain text files that are easily versioned. But is anyone reviewing them, or maintaining them? Can we establish the provenance, and can we trust them? The known process to address these questions is the open-source process, which establishes skills as open-source artifacts. Yet, I haven’t seen them formally treated as such.
Anthropic introduced agent skills in October 2025 and published the specification that December, shortly after donating the Model Context Protocol to the Linux Foundation's new Agentic AI Foundation. The specification and its reference tooling are on GitHub under Apache-2.0, and the documentation is under CC-BY. This is not a proprietary format that might disappear without warning. A few dozen products already implement the format, among them OpenAI's Codex, GitHub Copilot, Cursor, Gemini CLI, and VS Code. A skill written for one agent runs in the others.
To be precise about what was and was not given away: MCP was donated to a foundation with a governing board, a technical committee, and a published process. Agent Skills was published as an open standard, which is a different act: the specification is openly licensed and anyone may implement it, but stewardship remains with its originator. Proposals are made in a GitHub discussion thread; there is no technical charter, no release cadence, and no multi-stakeholder process of the kind that matures a specification over time. Whether the standard eventually moves to a foundation is, at present, an open question.
Those precisions are not an argument for caution. Conventions that are forming are conventions that can still be shaped, and the institutions with the deepest experience of open-source governance need to engage in shaping them.
These are familiar questions
We arrive here at a place often visited in the open source world. Skills raise questions about governance, maintenance, and licensing a repository that is part prose and part executable scripts. Even “dependency hell” reappears, in this case in the form of skills whose correctness depends on third-party documents that expire (like the research-administration skills from our example above). Other thorny issues are not new either: who reviews the artifact, who maintains it when the author moves on, and how anyone can tell whether it is any good, or even safe to run.
All of these are questions the open source community has been grappling with for decades, now attached to a new class of artifact. As with software, an OSPO is where we look for guidance on licensing, versioning practice, registries, security review, and governance. We are prepared to tackle the challenge, with our lessons from the trenches. In fact, research software was in a similar place a few decades ago: eager practitioners wrote code, and used it with no review, uneven sharing, haphazard licensing, and no credit. Now we have FAIR4RS, the Journal of Open Source Software (JOSS, of which I was a founding editor), the US Research Software Sustainability Institute (URSSI), and widespread adoption of software citation and sustainability efforts.
That transformation in research software took three decades, while skills are about a year old. Because conventions have not yet been established, we can play a role in shaping them. Implementing these standards today will be simpler than trying to retrofit them across millions of existing files in the future. There is some urgency to it, because the artifacts are already being produced much faster than anyone is checking them.
Most skills are not very good
The evidence on this is now reasonably firm. Community directories have indexed on the order of 1.9 million public skills scraped from GitHub. The first benchmark to evaluate them systematically, SkillsBench, scored more than 47,000 and found a mean quality of 6.2 out of 12. The same study found that well-built skills raised agent pass rates by an average of 16 percentage points. In sum, skills work, but most of those found in the wild are not built well.
The failure mode is specific. When my students and I read real SKILL.md files from public engineering repositories, many were structurally immaculate—clean frontmatter, sensible sections, confident headings—and had, as far as we could tell, never been tested against a real problem by anyone who could recognize an error. What we found instead were plausible-sounding protocols that a practitioner would naturally question. Structure is indeed a poor proxy for quality. A beautifully organized skill that encodes an incorrect protocol is worse than no skill at all, because it produces incorrect results with the appearance of rigor.
The structural reason why this is a hard problem is that the people who write skills and the people who use them are different populations. The author holds the domain expertise; the user, by design, needs less of it. That is the point of packaging expertise this way, and it is also the risk, because the user cannot evaluate what they could not have derived in the first place. The interaction with a skill gives no sign when something has gone wrong. Its output arrives formatted, confident, and fast. Curation, in other words, is the scarce good.
Where an OSPO comes in
An OSPO is where you come to ask these questions early: what license, what version, who maintains it, who reviews it, and what happens when the maintainer moves on. Those questions decide whether an artifact is trustworthy infrastructure.
The research-administration example makes a special point about maintenance and governance. A budget skill encoding rates with effective dates and a solicitation that closes does not fail loudly when it goes stale; it keeps producing confident, well-formatted output against last year's rules. Skills that encode policy degrade dangerously rather than quietly. That argues for naming a maintainer and a review cadence when a skill is published, not after something has gone wrong.
I had a good conversation about this with Duncan Brown, who established the Syracuse OSPO, at a conference last month. We envisaged a joint effort to develop publication conventions, provenance practices for skills that encode expiring rules, and evaluation literacy (teaching people to read skills critically). Because these practices should be developed in the open, by a community, we will reach out to our fellow academic OSPOs via the CURIOSS network and organize broader conversations. A year from now, conventions on publishing and maintaining agent skills will have taken shape. Those of us who spent a decade learning to steward research software can help write them.
Content licensed under Creative Commons Atribution International 4.0