SkillCorpus: Turning Scattered SKILL.md Files Into a Retrieval Layer
Open-source infrastructure that turns scattered SKILL.md files into curated, retrieval-ready agent-skill corpora—with retrieval and evaluation tooling included.
At a glance
- What is it?
- SkillCorpus is EverMind's Apache-2.0 pipeline for aggregating SKILL.md files, gating them on safety and license, and serving retrieved procedures to agent hosts. The retrieval idea is sound; the open question is how much of the curation you have to own yourself.
- Who is it for?
- Adopt SkillCorpus if you already maintain SKILL.md files across several repositories and want retrieval, license gating and evaluation in one pipeline you can self-host. Do not adopt it if you only need a handful of static instructions in one prompt, or if you cannot run the retrieval models locally and will not use the hosted SkillHub API.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SkillCorpus addresses: SKILL.md files that never reach the agent
Procedural knowledge for agents tends to accumulate as loose SKILL.md files in public repositories. The README frames the pipeline as turning those scattered files into "reliable agent context" by aggregating sources, applying safety and license gates, evaluating quality, and matching task-specific skills before the agent answers. That is a curation problem before it is a retrieval problem. Anyone who has copied instructions between agent hosts knows the failure mode: each host keeps its own collection, and the same procedure gets rewritten three times with different edge cases. SkillCorpus is aimed at teams running more than one agent host, or at anyone who wants the skill layer to be a build artifact rather than a prompt fragment. The README also states the repository is the open-source layer behind the hosted SkillHub product, so the intended audience splits in two: people who want the machinery, and people who just want the hosted result.
Aggregation, gating, retrieval: the pipeline as the README describes it
The mechanism visible in the material is a four-stage pipeline: aggregate sources, apply safety and license gates, evaluate quality, then match skills to the task. The README's latest updates add detail. Multi-source retrieval, dated 2026-08-27, covers local skills, EverMind SkillHub, ClawHub and skillhub.cn, with filtering, deduplication, and a final 0 to 2 selection. That last number matters: the retrieval stage is not returning a ranked list of twenty candidates for the model to sift. It narrows to at most two skills, which keeps context cost bounded but puts the whole burden of precision on the retrieval recipe. The README also describes two delivery modes, on demand and automatic, with a `skill_search` tool exposed to the agent in the on-demand case so the model decides when to pay for retrieval. The README text is truncated mid-sentence at `mode: aut`, so the exact config key spelling for the automatic mode cannot be confirmed from the supplied material.
The benchmark table and what it actually claims
The README reproduces a results table from the paper (arXiv 2607.15557) comparing pass rates with no skills against pass rates with SkillCorpus, same harness and same backbone. The pooled deltas are +7.5 on SkillsBench, +1.51 on GDPVal, and +2.79 on QwenClawBench. The README's own reading of this is the most useful part: the gain is largest where the task needs procedural knowledge the model does not already have, and smallest on open-ended economic tasks it can already do. That is a narrow claim, and it is the right one to make. If your workload looks like GDPVal, a +1.51 point movement is within the range where you would want your own evaluation before attributing anything to the skill layer. The repository ships evaluation tooling for exactly this reason, and the README mentions three agent benchmarks and a public 1,000-skill demo as the visible result.
Getting it running, and where the documentation thins out
The README does not give an install command, a requirements file, or a quickstart in the supplied text. What it does give is the shape of the work: point the pipeline at your own source registry, apply curation, safety and license gates, and export a corpus. Configuration surfaces named in the material include the taxonomy, quality and dedup rules, the retrieval recipe, the export schema, evaluation suites, and host plugins. Two concrete config items appear: the `skill_search` tool name for on-demand retrieval, and a `mode` setting whose automatic value is cut off in the README. PathGuard placeholder resolution and host-aware paths for skill files and agent workspaces are mentioned in the 2026-08-26 update, which implies path handling is configurable rather than hardcoded. Anyone evaluating this should read the plugin READMEs under `skillcorpus_plugin/` for the host-specific setup, since the top-level README defers to them. Treat the absence of a quickstart in the supplied material as a gap to check, not as evidence one does not exist.
The licence split and the per-skill licence you inherit
Licensing here has two layers. The repository states the core code is Apache-2.0, with `match/` and `evaluate/` under MIT. Those two directories are the retrieval and evaluation halves, so a team that only wants the matching logic is working in MIT code. The second layer is more consequential: each skill retains its upstream license. SkillCorpus aggregates third-party SKILL.md files and the README describes license gates as part of the pipeline, which suggests the tooling can classify and filter on licence terms. It does not follow that the output corpus is uniformly redistributable. If you export a corpus, the licence obligations travel with the individual skills, and the gate is a filter, not a relicense. This is not legal advice; check the specific upstream terms for the skills you actually ship.
Where SkillCorpus is the wrong tool
The clearest mismatch is scale. If you have a dozen instructions that fit in a system prompt, a retrieval layer adds a dependency, a model to host, and a failure mode where the wrong skill gets selected. The final 0 to 2 selection means a retrieval miss is not a ranking degradation, it is an empty or wrong context window, and the agent proceeds without the procedure. The second mismatch is deployment. The README lists keeping control of deployment as a reason to clone the repository, which means self-hosting the released retrieval models and connecting your own agent host. If you will not run those models and you will not use the hosted SkillHub API, the open-source path does not get you a working retrieval layer on its own. Third, the repository is young. Releases v0.1.0 and v0.3.0 are dated within days of each other in late August and early September 2026, and the update log shows plugin support and multi-source retrieval landing in the same window. Expect configuration surfaces to move.
How this differs from a plain vector store over your own documents
The obvious alternative is putting your SKILL.md files into a vector database and retrieving top-k by embedding similarity. The difference is everything around the embedding. A vector store gives you similarity and nothing else; SkillCorpus adds safety and license gates before indexing, quality evaluation, deduplication across sources, a taxonomy, and a final selection step that caps output at two skills. The dedup and cap are the parts a naive pipeline lacks: without them, four near-identical copies of the same procedure can occupy the whole retrieved context. The cost of that structure is that you inherit EverMind's taxonomy, quality rules and retrieval recipe, or you modify them. A plain vector store is easier to stand up and easier to get wrong in ways you will not notice until the agent follows a stale procedure. The trade is curation and constraints against flexibility and setup time.
Maintenance cost and what to verify in your own checkout
The maintenance surface named in the README is wide by design: taxonomy, quality and dedup rules, retrieval recipe, export schema, evaluation suites, and host plugins. Each is something you can change, which also means each is something you own once you fork the pipeline. Plugin coverage currently spans DeepSeek Harness, Hermes, OpenClaw (1.x and 2.0), Raven and WorkBuddy, with OpenClaw 2.0 support added on 2026-09-02 and a new plugin engine in TypeScript under `skillcorpus_plugin/engine-typescript/`. If your host is not on that list, the integration work is yours. Upgrade cost is tied to how tightly you couple to the export schema and retrieval recipe; teams that only consume the exported corpus can absorb pipeline changes, while teams that patch the matcher cannot. Verify the MIT carve-out paths, run the evaluation suites against your own task set before trusting the pooled deltas, and check what the license gate does with the upstream repositories you depend on.
Editorial conclusion
Adopt SkillCorpus if you already maintain SKILL.md files across several repositories and want retrieval, license gating and evaluation in one pipeline you can self-host. Do not adopt it if you only need a handful of static instructions in one prompt, or if you cannot run the retrieval models locally and will not use the hosted SkillHub API. Before committing, verify three things in your own checkout: which files fall under the MIT carve-out in match/ and evaluate/ versus the Apache-2.0 core, how the safety and license gates classify the upstream repositories you actually depend on, and whether the retrieval recipe returns anything useful for your task distribution, since the reported benchmark gains are largest on procedural tasks and smallest on open-ended ones.
Community notes