1 Introduction↩︎

When a developer asks an AI agent to “implement the authentication module,” the agent can usually produce a result that runs. Whether that result is correct, secure, and maintainable is a separate matter. As large language models (LLMs) and autonomous agents take over tasks that practitioners once performed by hand, a quality gap emerges: agents gain autonomy faster than they gain the operational judgment that human expertise once supplied. We argue that skills, defined as structured, retrievable, source-grounded units of operational knowledge, can serve as infrastructure for narrowing this gap. This paper introduces SkillCenter, a library of 216,938 such skills across 24 domain bundles, together with an automated framework for producing, validating, and distributing them at scale.

1.1 Vibe Coding and Vibe Research↩︎

In February 2025, Andrej Karpathy coined the term vibe coding [1] for a workflow in which a developer states intent in natural language, an LLM writes the code, and the developer accepts or rejects the output based on whether the program appears to work, without line-by-line review. Code-generation tools such as GitHub Copilot had existed for years; the term named a newer disposition, the willingness to stop reading the generated code. It gained currency because it described a practice that was already widespread.

The idea migrated quickly. OpenAI researchers Jakub Pachocki and Mark Chen applied the same logic to scientific inquiry under the label vibe research [2]: let AI agents handle literature review, data analysis, and even preliminary drafting while the human researcher steers. The researcher stops being the person who pipettes the reagent and becomes the person who decides which reagent to pipette.

These methodologies are also drawing scholarly attention; the VibeX 2026 workshop at EASE 2026 is one venue dedicated to studying them [3]. Industry is moving in parallel: a collaboration between OpenAI and Ginkgo Bioworks paired a GPT-5 model with an autonomous laboratory to design and run biological experiments at scale [4].

In effect, the human role is shifting from executing tasks to directing them.

1.2 The Autonomy Spectrum↩︎

The transition to agent-executed work has not happened in a single leap. We describe it as a four-stage autonomy spectrum:

1. Human-only. The practitioner writes all code, runs all experiments, and reviews all outputs. The machine is a passive execution environment.

2. LLM-assisted. Tools such as GitHub Copilot, ChatGPT, and similar systems suggest completions, answer questions, and draft short passages. The human retains full editorial control and reviews every suggestion before acceptance.

3. Agent-executed. Integrated development agents (Claude Code, Cursor, Windsurf, and their counterparts in scientific domains [5]) receive high-level tasks (“implement the authentication module,” “analyze the RNA-seq dataset”) and produce multi-file, multi-step outputs with minimal human intervention. The human reviews selectively.

4. Agentic autonomous. Multi-agent systems decompose complex goals into sub-tasks, delegate to specialized sub-agents, and orchestrate execution across tools, APIs, and environments [6]. The OpenClaw agent framework [7] (an open-source harness for building skill-composing assistants and automation agents) and OPAL [8] are early examples. In OpenClaw’s architecture, agents assemble task-specific behaviors from a registry of discrete skill primitives, making the availability and quality of those primitives a first-order concern. Human involvement at this stage is limited to goal-setting, periodic auditing, and exception handling.

At each stage, the agent’s independent decision-making increases while human oversight decreases. When a human writes code, decades of training and institutional knowledge implicitly constrain the solution space; when an agent writes code, those constraints must be made explicit. The autonomy spectrum is therefore also a risk spectrum: the less a human is in the loop, the more the system depends on the quality of the knowledge available to the agent.

1.3 Execution Versus Correctness↩︎

Modern LLMs are capable code generators. Given a well-formed prompt, an LLM can produce a Python module that parses a dataset, trains a model, and writes results to disk, and the module will often execute without errors on the first attempt. Successful execution, however, is a weak signal of quality: benchmarks of real-world issue resolution show that code which runs can still fail to fix the underlying problem [9]. The module may silently leak memory, use a deprecated API, ignore edge cases in the data, apply an inappropriate statistical test, or introduce a security vulnerability that passes all existing tests. In scientific contexts, a generated analysis may use a valid but suboptimal method or fail to correct for multiple comparisons. Execution success and substantive correctness are distinct properties.

Experience, mentorship, code review, and institutional standards traditionally bridged this gap. In an agent-executed paradigm, these mechanisms are either absent or operate on a different timescale: a code review that takes a senior engineer thirty minutes is at odds with an agent that generates a feature in seconds. The autonomy thus creates a tension. The more autonomous the agent, the more it needs grounded knowledge to constrain its behavior. Yet the very autonomy that makes agents useful removes the human from the position where such knowledge was traditionally applied.

Current mitigation strategies fall into two categories. Human-in-the-loop review is effective but unscalable: the review bottleneck grows proportionally with agent output. Retrieval-augmented generation (RAG) improves factual grounding but operates on raw document chunks that may be noisy, contradictory, or tangential. The agent must still decide what to do with the retrieved passages, a decision that requires the operational judgment it lacks; neither approach scales on its own.

1.4 Why Skills Are Needed↩︎

We define a skill as a structured, retrievable, source-grounded unit of operational knowledge. Each skill encodes a specific piece of actionable guidance (a best practice, a common pitfall, a validated technique, a configuration recommendation) together with metadata including its domain, evidence provenance, quality score, and applicability conditions. Skills differ from RAG document chunks in several important respects:

• Structure. A skill has a defined schema (title, description, applicability, evidence, score), whereas a RAG chunk is an arbitrary substring of a source document.

• Quality gating. Each skill passes through an LLM-based quality gate that scores clarity, accuracy, and actionability (an internal QA signal, not external validation); RAG chunks inherit the quality of their source without independent assessment.

• Actionability. A skill is written to be directly applied by an agent during task execution; a RAG chunk provides context that the agent must interpret and operationalize on its own.

• Scoring. Skills carry numerical quality scores that allow agents to prioritize high-confidence guidance; RAG systems typically rank by relevance rather than quality.

Reusable skill collections already exist in robotics, game AI, LLM agent frameworks, and community marketplaces such as ClawHub [10], which we survey in §5. Existing libraries share three limitations:

1. Manual authorship. Skills are written by hand, making creation slow and expensive. A domain expert may spend hours distilling a single skill from the literature.

2. Limited scale. The largest publicly available collections contain hundreds to low thousands of skills, far too few to cover the breadth of knowledge that a general-purpose agent requires.

3. Narrow coverage. Most collections focus on a single domain (e.g., software engineering, robotic manipulation) and do not transfer across the diverse tasks that modern agents are expected to handle.

These libraries are not keeping pace with demand. As agents are deployed in more domains and given more autonomy, the number of situations in which grounded operational knowledge would prevent errors grows combinatorially, and manual curation does not scale to meet it. This motivates an approach that is automated, source-grounded, multi-domain, and able to scale to hundreds of thousands of skills, which is the goal of this work.

1.5 Our Contributions↩︎

This paper makes three primary contributions:

1. The SkillCenter library. We release 216,938 skills across 24 domain bundles, of which 114,565 are produced by the SkillGate pipeline and 102,373 are integrated from public GitHub repositories and the ClawHub marketplace, exceeding prior open skill collections by more than an order of magnitude in size. Section 2.1 gives the full breakdown by source and domain.

2. An end-to-end automated framework. We present a complete, continuously running pipeline for skill production, covering multi-source acquisition, an LLM-based quality gate (SkillGate), template-driven generation, iterative source-grounding, and quality-controlled publishing with full audit trails, that ingests new sources and produces new skills without manual intervention.

3. An offline-searchable distribution system. We package the corpus as domain-split SQLite FTS5 bundles [11] that support offline keyword search over skill titles without network access. An automatic project-type detection mechanism identifies the relevant domains for a given project, and a bundle-install --auto command integrates the appropriate skill bundles into agent workflows. Pre-built bundles are available on Hugging Face¹ [12], and the full framework is open-source on GitHub.²

2 The SkillCenter Corpus↩︎

This section analyzes the corpus: its scale and domain composition (§2.1), academic (§2.2) and technical (§2.3) sources, the integrated community bundles (§2.4), deduplication and redundancy (§2.5), quality scores (§2.6), and the search and agent integration layer (§2.7).

2.1 Corpus Overview↩︎

The SkillCenter library contains 216,938 published skills organized into 24 domain bundles, drawn from three broad categories: Research (90,084 skills, 41.5%), Technical (24,481 skills, 11.3%), and Community (102,373 skills, 47.2%). The Research and Technical bundles (114,565 skills) are produced by the SkillGate pipeline (§3) from 55,199 distinct source documents; the Community category integrates two large externally harvested collections: GitHub SkillMD (90,984 SKILL.md files mined from public repositories via code search) and the ClawHub community marketplace (11,389 skills). Figure 1 visualizes the relative scale of these categories, and Table ¿tbl:tab:corpus-summary? provides the complete per-domain breakdown. All skills are in English. Pipeline-produced skills carry a quality score on a scale from 1 to 5 assigned by GPT-5.2 during the publish gate; their average is 3.91 (the two integrated collections use separate scoring scales and are excluded from this average).

2.1.0.1 Terminology.

A few terms recur throughout this report:

• Source: a raw input document (web page, README, paper, forum post, repository). There are 55,199 sources for the pipeline subset and 94,722 distinct across the full library.

• Generated skill: a skill produced by the LLM pipeline before quality filtering. Published skill: one that passes the publish gate and ships in a released bundle.

• Skill kind: the facet a skill captures (e.g.paper.experiment, paper.method, or the default technical template); one source can yield several kinds.

• Domain configuration (13): a framework input spec defining source routing, host lists, and search parameters for one topic domain.

• Domain bundle (24): a published SQLite database grouping skills; 21 are produced by the domain configurations and 3 are integrated community bundles.

The phrase “over 24,000 technical sources” refers to the distinct GitHub, web, and forum source documents that produced the technical skills.

2.1.0.2 Bundle Taxonomy and Assignment.

The 24 bundles follow two organizing principles. Technical, web, and forum skills are grouped by topic domain: the pipeline defines 13 domain configurations (e.g., cloud, linux, web; the full list and schema are in Appendix 12), each delimiting a domain through host allowlists, GitHub search constraints, and forum tags (§3.2). Research skills are instead grouped by publication venue, namely the Public Library of Science (PLOS), eLife, and the Nature-family journals, which form a natural and citable partition. Each skill inherits the bundle of the configuration that acquired its source, so it belongs to exactly one bundle; topics that do not map unambiguously to a single domain are routed to the most appropriate configuration by an LLM classifier (§3.2). That this partition is clean in practice is corroborated by the redundancy analysis: cross-bundle near-duplicates are rare (only about 3% of near-duplicate pairs at Jaccard \(\geq 0.8\) span two bundles; §2.5), so the bundles do not substantially overlap. The residual “other” categories collect sources that fall within the pipeline’s scope but match no specific domain configuration.

We split the corpus into research and technical deliberately. Academic papers provide depth: each paper yields multiple skill kinds covering experimental methodology, theoretical framing, and visualization. Technical sources provide breadth: GitHub repositories, web documentation, and forum discussions capture the operational knowledge agents need for writing, deploying, and maintaining software. A computational biology agent, for instance, needs both the methodological rigor of journal-derived skills and the systems-level guidance of technical skills. Ordering the 24 bundles by their concept profiles recovers this research/technical/community structure (Figure 2).

2.2 Academic Paper Sources↩︎

Academic papers make up 41.5% of the library (90,084 skills), drawn from more than ten peer-reviewed journals and the ArXiv preprint server. Peer-reviewed literature has the highest density of structured, citable knowledge per document, so we prioritized it. Each paper is decomposed into multiple skill kinds covering intellectual framing, experimental design, methodological details, and visual communication. The corpus records what a paper found together with how it framed its question, tested its hypothesis, and presented its results.

The PLOS Journal Family↩︎

The PLOS journals collectively contribute 61,968 skills (28.6% of the library), making them the single largest journal source category. We selected PLOS journals for three reasons: they are fully open-access under Creative Commons licenses, they span a wide range of biological and medical disciplines, and their XML-based publication format enables reliable automated parsing. Seven PLOS journals are represented: PLOS ONE, PLOS Computational Biology, PLOS Biology, PLOS Genetics, PLOS Medicine, PLOS Pathogens, and PLOS Neglected Tropical Diseases (NTD).

For each PLOS paper, the framework extracts four skill kinds that together provide a multi-dimensional decomposition of the paper’s content:

• paper.idea_intro captures the paper’s intellectual contribution: the research question, the gap it addresses, and the framing of its hypothesis within the broader literature.

• paper.experiment encodes the experimental design, including protocols, controls, sample sizes, and the logic connecting experimental choices to the research question.

• paper.method distills the computational or analytical methodology, including algorithms, statistical tests, software tools, and parameter choices.

• paper.picture analyzes the paper’s figures and visual communication strategy, extracting guidance on how to effectively present scientific data.

Table ¿tbl:tab:plos-breakdown? presents a detailed breakdown of each PLOS journal, including skill counts, average quality scores, and the distribution of skill kinds; Figure 3 visualizes the skill-kind composition across the seven journals.

PLOS ONE is the largest single journal bundle (13,887 skills, avg 4.01) and the only multidisciplinary PLOS journal, spanning biology, medicine, engineering, and social sciences. Its skill kind distribution is nearly uniform (30/28/21/21%), consistent with its broad disciplinary scope. PLOS Biology (10,042 skills, avg 3.96) is similar (32/25/23/20%), a selective journal that publishes conceptual and experimental work in roughly equal measure.

The other five journals are more specialized, and the skill kind distributions show it. PLOS Computational Biology (10,843 skills, avg 3.85) tilts toward methods (28%) and away from figures (14%), consistent with its computational and mathematical emphasis. PLOS Genetics (4,241 skills, avg 3.77) follows a similar pattern: method-heavy (26%) with low picture share (13%), consistent with a computational and statistical emphasis. PLOS Medicine (9,219 skills, avg 3.94) goes the opposite direction: 24% picture, the highest in the family. Clinical papers rely heavily on Kaplan-Meier curves and forest plots. PLOS Pathogens (9,160 skills, avg 3.86) leads on idea_intro (33%). Papers in this journal spend considerable space framing novel hypotheses about host-pathogen interactions. PLOS NTD (4,576 skills, avg 3.87), the smallest bundle, resembles PLOS Medicine in its high picture share (24%): epidemiological maps and geographic visualizations are central to the field.

Nature Family and Other Journals↩︎

The Nature family of journals contributes 22,617 skills (10.4% of the library), making it the second largest journal source category after PLOS. We decomposed the formerly monolithic “Other Journals” bundle into its constituent sub-journals using DOI-based classification against the source URLs. The result reveals over 30 distinct Nature-branded journals, with the top eleven each contributing over 900 skills: Nat.Neuroscience (1,303), Nat.Cell Biology (1,163), Nat.Methods (1,160), Nat.Immunology (1,084), Nat.Microbiology (1,073), Nature flagship (1,048), Scientific Reports (1,030), Nat.Medicine (998), Nat.Human Behaviour (997), Nat.Chemistry (952), and Nat.Metabolism (943). The remaining 30+ journals collectively contribute 10,866 skills, including titles such as Nat.Structural & Molecular Biology, Nat.Plants, and Nat.Ecology & Evolution.

Quality scores run high across the Nature family. The Nature flagship journal achieves the highest average among all research sources (4.12), reflecting the depth and precision of its papers. Nat.Methods (4.05) ranks second, consistent with its focus on detailed methodological descriptions that map naturally to actionable skills. The family-wide average of 3.83 is competitive with PLOS despite the higher selectivity of Nature journals producing fewer but more focused skills.

The idea_intro share across Nature journals (36.1%) is the highest of any source family, consistent with these journals’ emphasis on conceptually novel work.

eLife (941 skills, avg 3.91) is selective and prizes conceptual novelty. idea_intro accounts for 34.9% of its skills, while picture is only 10.3%. A residual category of 1,075 skills (0.5%) includes PLOS cover image descriptions and a small number of items that did not match any journal family pattern.

ArXiv Preprints↩︎

ArXiv contributes 3,483 skills (1.6%, avg 3.73, the lowest among research sources, as expected for non-peer-reviewed preprints). Despite the lower scores, ArXiv fills an important niche by providing access to recent methods before journal publication. The skill kind taxonomy for ArXiv differs from the journal taxonomy; Table ¿tbl:tab:kind-comparison? compares the two systems.

The two taxonomies reflect different use cases. Journal skill kinds center on understanding a published paper: paper.idea_intro captures the research question, paper.method distills the methodology. ArXiv skill kinds are oriented toward writing and reproducing research: paper_writing captures how to frame a contribution, paper_writeup distills methods into reproducible recipes, and experiment_design focuses on experimental setup. The small share of results_analysis (2.4%) reflects the predominantly methodological nature of preprints.

2.3 Technical Sources↩︎

Technical sources account for 11.3% of the library (24,481 skills), drawn from GitHub repositories, web pages, Stack Overflow forums, and ArXiv papers in technical domains. Unlike academic sources with consistent structure, technical sources vary widely in format, depth, and quality, presenting both opportunities for capturing hands-on operational knowledge and challenges from variable signal-to-noise ratios.

GitHub Repositories↩︎

GitHub repositories constitute the largest technical source, contributing 20,064 skills (9.2% of the library).³ The collection pipeline uses domain-configured search queries with minimum star count and pushed_after date thresholds to identify actively maintained, community-validated repositories. For each qualifying repository, the framework extracts the README file and key code files, then generates skills that capture the repository’s core functionality, setup procedures, and usage patterns.

Table ¿tbl:tab:github-domains? presents the distribution of GitHub-derived skills across technical domains.

DevTools has the highest average score (4.23) despite modest volume. Microsoft, JetBrains, and Docker write thorough READMEs, which in turn yield good skills. Linux is the largest domain (7,262 skills) but scores lower (3.90): individual maintainers vary widely in how much they document. Programming (avg 4.15) benefits from language ecosystem repositories (rust-lang, golang, python) with unusually complete documentation.

Community-driven and enterprise-driven domains differ, but not cleanly by ownership. Enterprise repositories cluster at the high end (DevTools 4.23, Observability 4.09, Cloud 4.03), probably because corporate documentation teams write more structured READMEs; but the community-driven programming ecosystem is comparably high (4.15), so this is a tendency, not a rule.

Web Pages↩︎

Web pages contribute 3,130 skills (1.4% of the library), with approximately 95% concentrated in the web development domain. Table ¿tbl:tab:web-sources? lists the top 10 source domains by skill count.

The distribution has a long tail. The 3,130 web page skills come from 1,326 unique source domains; the top 10 account for 721 skills, while the remaining 2,409 originate from 1,316 domains at an average of 1.8 skills each, and 976 domains contribute a single skill. Of the 3,130 skills, 2,980 (95.2%) fall in the web-development domain, with the remainder scattered across the Linux, DevTools, and other technical domains.

The overall web page average is 3.76, lower than GitHub’s 4.01. For non-web domains, web page skills concentrate on official documentation sites, and the average score for cloud-domain web pages drops to 2.25 (across only eight skills), consistent with diminishing returns from web scraping in domains with sparse tutorial coverage.

Stack Overflow Forums↩︎

Stack Overflow contributes 1,162 skills (0.5% of the library), all sourced from stackoverflow.com. Stack Overflow content is published under CC-BY-SA licenses (versions 3.0 and 4.0, depending on the post date), which require attribution and share-alike compliance for redistribution; the published bundle retains the source URL and attribution metadata needed to support these obligations. Table ¿tbl:tab:forum-domains? shows the domain breakdown.

The web domain dominates Stack Overflow-derived skills at 81%, reflecting the platform’s historically strong coverage of frontend and web development topics. The Q&A format maps naturally to the skill structure: a question provides the background and problem context, the accepted answer supplies the solution steps, and comments add verification criteria or edge-case warnings.

However, the moderate average scores (3.12 to 3.83) reveal a limitation of forum-derived skills. Stack Overflow answers are often terse, version-specific, or narrowly scoped to the original question’s context, limiting their generalizability. The “other” domain scores lowest (3.12), as miscellaneous topics tend to produce answers too niche for effective skill extraction. Despite these limitations, Stack Overflow’s CC-BY-SA licensing (with attribution and share-alike obligations) and problem-and-solution structure make it a valuable complement to GitHub and web page sources.

ArXiv Preprints in Technical Domains↩︎

ArXiv preprints in technical domains contribute 125 skills, split between the Linux domain (64 skills, avg 2.80) and the ML domain (61 skills, avg 3.43). These two domains behave very differently: academic papers about operating system concepts and kernel design do not readily convert to actionable, step-by-step skills, while ML methodology papers describing model architectures and training procedures are inherently procedural and convert naturally. The linux-domain ArXiv average of 2.80 is among the lowest source-level averages in the corpus, ahead of only cloud-domain web pages (2.25).

2.4 Community and Repository Bundles↩︎

Beyond the SkillGate pipeline, the released library integrates two large, pre-existing skill collections that are harvested rather than generated. Together they contribute 102,373 skills (47.2% of the library) and are reported as the Community category in Table ¿tbl:tab:corpus-summary?.

GitHub SkillMD (90,984 skills, source type repo) is a bulk harvest of SKILL.md files already authored and committed to public GitHub repositories, located via code search rather than produced by our generation templates. Because these skills are human-authored artifacts that ship inside agent projects, they are admitted directly; they carry a uniform placeholder quality marker rather than a GPT-assigned score on the 1-to-5 scale, and are therefore excluded from the score analyses in §2.6 and Table ¿tbl:tab:score-distribution?. This bundle is the single largest in the library and substantially broadens coverage of real-world, repository-embedded agent skills.

ClawHub community (11,389 skills, source type claw-*) mirrors the ClawHub marketplace [10] of community-contributed skills. ClawHub items are scored on a separate marketplace scale (not the 1-to-5 publish-gate rubric) and are likewise excluded from the pipeline score statistics. Integrating the marketplace makes the library a superset of the community ecosystem while keeping provenance explicit per bundle.

Both integrated collections bypass SkillGate, generation, and the publish gate; the framework described in §3 applies only to the 114,565 pipeline-produced Research and Technical skills. We keep the two populations clearly separated throughout so that downstream users can opt into the source-grounded pipeline subset, the community subset, or the full library.

2.5 Deduplication and Redundancy↩︎

A library of this size invites an obvious question: are the 216,938 skills genuinely distinct, or does the headline count conceal duplicates? We measure redundancy at three levels (Table ¿tbl:tab:dedup?), recomputed directly from the released SQLite bundles. First, identity: skill_id is a global primary key, all 216,938 published skills carry distinct IDs, and the 24 bundles are pairwise disjoint, so no skill is counted twice and none appears in two bundles. Second, verbatim content: 9,831 skills (4.5%) share byte-identical normalized text with at least one other skill, that is, distinct IDs that nonetheless render to the same body, such as shared templates or repeated boilerplate. Third, near-duplication: we compute a 128-permutation MinHash over word 5-shingles of each skill body and retrieve near-duplicate pairs with banded locality-sensitive hashing (LSH), then cluster skills whose estimated Jaccard similarity exceeds a threshold. At Jaccard \(\geq 0.8\), 24,988 skills (11.5%) lie in a near-duplicate cluster.

Redundancy is highly uneven across the library and is confined almost entirely to the externally harvested community bundles (Table ¿tbl:tab:dedup-by-domain?). The SkillGate pipeline subset is essentially duplicate-free: every one of its 21 domains sits at or below 0.01%, reflecting per-source generation and source-grounding. The GitHub SkillMD bundle, by contrast, is about 27% near-duplicate (and its small curated-lite subset reaches 65%), as expected for SKILL.md files mined from public repositories, which include forks, templates, and copied boilerplate; the ClawHub marketplace sits at about 5%. Near-duplicate pairs are overwhelmingly within a single bundle: only about 3% of near-duplicate pairs at Jaccard \(\geq 0.8\) span two different bundles, confirming that the 24 bundles do not overlap one another and that the corpus total is not inflated by cross-bundle repetition. Table ¿tbl:tab:dedup-examples? gives representative duplicate groups, spanning verbatim copies and small-edit near-duplicates; Appendix 10 lists every domain that contains duplicates, with counts and a concrete example from each.

Two caveats apply. First, MinHash with Jaccard similarity captures lexical near-duplication; meaning-preserving paraphrases are not detected, so the figures above are a lower bound on true redundancy.

Second, we also tested embedding-based semantic deduplication [13] to catch paraphrases that MinHash misses, but found it unreliable on this corpus: across seven off-the-shelf sentence encoders [14] spanning 22M to 8B parameters (from the MiniLM, BGE, GTE, E5, and Qwen3-Embedding families), the share of skills flagged as near-duplicate at a fixed cosine-0.9 threshold ranged all the way from 49% to 93%, reflecting each encoder’s embedding geometry rather than any property of the data; manual inspection confirmed that the high-similarity pairs are topically related but genuinely distinct skills, not paraphrases. We therefore report the lexical MinHash figures of Table ¿tbl:tab:dedup? as our defensible redundancy measure and leave a calibrated semantic estimate to future work. The residual redundancy concentrates in the harvested community bundle, and users who require a deduplicated view can restrict to the pipeline subset or apply standard near-duplicate filtering.

2.6 Quality Score Analysis↩︎

Each skill in the pipeline subset receives an integer quality score from 1 to 5, assigned by GPT-5.2 during the publish gate; the integrated community collections use separate scales and are excluded here. The rubric evaluates clarity, accuracy, actionability, and evidence grounding. The average over these 114,565 scored skills is 3.91, but the distribution is heavily skewed: approximately 82.1% of them receive a score of exactly 4. Score 3 and score 5 together account for most of the remainder. The model rarely commits to an extreme rating. This score inflation is consistent with documented biases in LLM-as-judge evaluation, where models exhibit self-enhancement and verbosity effects that compress scores toward the high end [15], [16].

Domain-level averages occupy a narrow band: most technical domains fall within roughly 4.0 to 4.2 (e.g., DevTools 4.21, Programming 4.15, LLM 4.03), a spread small enough that, given the single-LLM scorer and the heavy score-4 collapse, we do not read the ordering among them as meaningful. The only clearly separated case is the residual “other” domain (3.39), a catch-all for miscellaneous content.

Source-type differences are likewise subtle. The high-quality source types cluster closely (GitHub 4.01, journals 3.90, ArXiv 3.71), too near to rank reliably. The full per-source, per-score breakdown is deferred to Table ¿tbl:tab:score-distribution? in §3.5; we report these averages for completeness rather than as evidence of relative quality, and whether the finer differences hold under human evaluation is an open question (§6.2).

The publish gate is configured to exclude skills scoring below 3.0, removing approximately 3% of generated skills; a small number of early-run skills predate full enforcement of this threshold (see §3.5). The threshold is conservative: it filters the clearly defective tail while retaining the broad score-4 middle that represents skills of adequate quality. Section 6 discusses calibration strategies including human annotation campaigns and multi-model consensus scoring.

2.7 Search System and Agent Integration↩︎

The distribution system obeys three constraints. First, it uses no embedding models, no vector databases, and no network access at query time, so it has zero external dependencies. Second, agents install only the domains they need, which keeps the system modular at the domain level. Third, skill retrieval requires no explicit user action, so the integration is invisible to the user.

Architecture↩︎

The search system is built on SQLite FTS5 [11], a full-text search extension that ships with SQLite and requires no external dependencies. Each domain bundle is a self-contained SQLite database file, with technical domain bundles averaging approximately 120 MB and research domain bundles averaging approximately 1 GB. In the current release the FTS5 index covers each skill’s title and domain rather than its full body; queries therefore match against the skill’s declared topic, and matching against full skill content is a planned extension (§6.5).

Each bundle uses a four-table schema (detailed in Appendix 11) that separates metadata from content, enabling lazy loading: the search engine scans lightweight index entries and fetches full skill markdown only for selected results.

We chose FTS5 over vector search for four reasons. First, FTS5 is fully offline: it requires no embedding model download, no GPU, and no network access, making it suitable for air-gapped environments. Second, agent queries tend to be short keyword phrases (“configure nginx reverse proxy,” “pandas groupby aggregation”) that BM25, the standard bag-of-words ranking function used in full-text search, matches against each skill’s title and domain. Third, FTS5 ranking is deterministic and auditable, a key property for debugging agent behavior. Fourth, storage overhead is minimal compared to dense vector indexes. The main cost of this design is retrieval recall: because only the title and domain are indexed, a query whose terms appear in a skill’s body but not its title will miss it, which our downstream study (§4) identifies as the binding constraint in practice.

Query Pipeline↩︎

A skill-search command accepts a natural language query string and runs it through four stages:

1. The FTS5 engine returns candidate skills ranked by BM25 score.

2. Optional filters narrow results by domain, skill kind, or minimum quality score.

3. When multiple bundles are installed, the pipeline searches all of them in parallel, merge-sorts by BM25, and deduplicates.

4. Content loads on demand: the initial query returns only metadata from skills_index, and full skill markdown is fetched from skills_content only when the agent picks a specific skill.

A typical search scans thousands of index entries but loads only two or three full documents.

Agent Integration Design↩︎

The agent integration layer automates three steps: project type detection (by inspecting configuration files such as package.json or pyproject.toml), bundle installation from Hugging Face [12], and skill injection into the LLM context.

During task execution, the agent follows a retrieve-then-act pattern: it issues a skill search based on the task description, selects the highest-scoring relevant skills, and injects their content into the LLM context. Source URLs are stripped from the injected prompt to prevent agents from generating stale or hallucinated links; the published bundle nonetheless retains each skill’s source URL and attribution metadata, so license obligations such as CC-BY-SA attribution can still be satisfied. The entire integration is invisible to the end user: the agent retrieves and applies skills without manual configuration. Because retrieval is a local SQLite FTS5 query over lightweight index entries, it adds negligible latency to the agent loop; a systematic benchmark across bundle sizes and multi-bundle configurations is planned (§6.5).

3 The SkillCenter Collection Framework↩︎

The framework converts raw source material into searchable, quality-checked skills through five stages.

3.1 Framework Overview↩︎

The framework is organized as a five-stage pipeline (Figure 4).

The five stages are:

1. Source Acquisition (§3.2): Multi-source fetching with domain-aware routing. The framework retrieves content from web pages, GitHub repositories, Stack Overflow forums, ArXiv preprints, and journal APIs, applying per-source rate limiting and text extraction to produce uniform capture artifacts.

2. Quality Gate (§3.3): An LLM-based pre-filter called SkillGate evaluates whether each source document is suitable for skill extraction before any generation tokens are spent. Sources are classified as pass, maybe, or fail based on actionability, reproducibility, and content density.

3. Skill Generation (§3.3): Template-driven LLM generation produces structured skill documents using kind-specific prompts. Four template types tailor the generation to the source material’s nature (Table ¿tbl:tab:source-routing?).

4. Iterative Improvement (§3.4): Each generated skill undergoes up to three refinement passes (configurable). Each pass lints the skill for structural issues, identifies unaddressed improvement suggestions, and rewrites the skill with deterministic source-grounding checks to confirm that claims trace back to the original source.

5. Publishing (§3.5): A four-criterion publish gate filters on quality score, license compatibility, plagiarism ratio, and placeholder density. Skills that pass are packaged into SQLite FTS5 bundles and distributed via Hugging Face.

Appendix 14 traces a single skill (a GitHub README on automated security review) through all five stages, from raw source to published bundle entry.

3.2 Source Acquisition↩︎

The first stage retrieves raw content from five primary source types. All sources undergo common post-processing: text extraction, truncation to 12,000 characters, URL canonicalization (removing tracking parameters), and persistence as capture artifacts.

Input Sources and Fetching↩︎

Table ¿tbl:tab:source-methods? summarizes the five primary source types and their acquisition methods.

Each source type follows its own acquisition path. Web pages: HTTP GET with readability extraction and per-host delays. GitHub: domain-configured search queries with minimum star count and pushed_after filters, extracting README and key code files. Stack Overflow: the Stack Exchange API v2.3, concatenating question, accepted answer, and top comments. ArXiv: the ArXiv API with PDF-to-text conversion. Journals (PLOS, eLife): XML APIs that enable precise section-level extraction.

Domain-Aware Configuration↩︎

The framework supports 13 configured domains, each specifying host allowlists, seed URLs, GitHub search constraints, and forum tags (full configuration schema in Appendix 12). When a topic does not map unambiguously to a single domain, an LLM-driven classifier routes it to the most appropriate configuration.

3.2.0.1 Case Study: “kubernetes networking” acquisition path.

The topic “kubernetes networking” could belong to the cloud, linux, or web domains. The LLM classifier assigns it to cloud, which triggers three parallel fetches using the cloud domain configuration: web pages from kubernetes.io, GitHub repositories matching “kubernetes networking” with min_stars=100 (e.g., cilium, flannel), and Stack Overflow questions tagged kubernetes+networking. All source documents are truncated to 12,000 characters and saved as capture artifacts.

3.3 Quality Gate and Skill Generation↩︎

This subsection describes the two-phase process: a pre-generation quality gate that filters unsuitable sources, and template-driven generation of structured skill documents.

SkillGate: Pre-Generation Filter↩︎

SkillGate is an LLM-based pre-filter that evaluates source suitability before spending generation tokens. The gate receives a source excerpt (truncated to 4,000 characters) and produces a three-class verdict: pass, maybe (configurable, default: pass), or fail. Table ¿tbl:tab:skillgate-criteria? summarizes the criteria, and Appendix 13 reproduces the gate prompt together with the 1-to-5 quality-score rubric.

Sources below 200 characters receive an automatic fail. Above this threshold, the LLM returns a structured output: verdict, a SkillGate suitability score (0 to 10, not the 1-to-5 quality score used at the publish gate), and lists of supporting and opposing signals.

Two contrasting cases show what the gate does in practice.

3.3.0.1 Case Study A (pass \(\to\) score = 5 skill).

The GitHub repository ca-risken/security-review (MIT), containing a complete README with GitHub Actions configuration and input/output descriptions, received a SkillGate verdict of pass (score=8) and produced a score-5 skill titled “Add RISKEN Security Code Review to GitHub Pull Requests.” The resulting skill featured a clear Background, four concrete Use Cases, eight numbered Steps with YAML code blocks, and an explicit Verification section.

3.3.0.2 Case Study B (would-fail \(\to\) score = 2 skill).

By contrast, a bare code repository containing only a Mellor-Crummey-Scott (MCS) lock implementation (no README, no context, no usage instructions) would have received a fail verdict had the gate been enabled. The resulting score-2 skill suffered from vague Background text, “not provided” placeholders in Inputs, and Steps that merely restated code lines without operational guidance.

Structured source documentation maps directly to skill components. Bare code, without a README or usage instructions, does not.

Skill Generation Templates↩︎

Four template types tailor the generation to different source materials (Table ¿tbl:tab:gen-templates?).

All templates share common LLM parameters (listed in Appendix 12). Each generated skill includes a title, full skill markdown, and a self-review with an overall score and improvement suggestions for the iterative improvement stage.

Note that experiment_design serves as both a generation template and a skill kind label. Journal papers also produce four additional skill kinds (paper.idea_intro, paper.experiment, paper.method, paper.picture) via the default template adapted for academic content.

Table ¿tbl:tab:source-routing? summarizes the end-to-end mapping from source type through domain configuration and generation to published bundle.

3.3.0.3 Case Study C (journal \(\to\) paper.experiment skill).

A PLOS Biology paper on amplitude modulation in neural circuits, processed by the experiment_design template, yielded a skill containing an explicit Claim, a replication-ready experimental design (electrode configurations, stimulus parameters, analysis pipelines), and a task breakdown into independently executable steps.

3.4 Iterative Improvement and Source-Grounding Check↩︎

Each generated skill undergoes up to 3 improvement passes (configurable, range 1 to 5), a form of iterative self-refinement with model-generated feedback [17]. The improvement loop is driven by a composite scoring function: \[\text{score} = \text{lint\_count} \times 100 + \text{missing\_count}\] where lint_count is the number of structural issues (missing required sections, malformed code blocks, formatting errors) and missing_count is the number of improvement suggestions from the original generation review that have not yet been addressed. The \(100\times\) weight on lint errors reflects their higher severity: a skill with a missing Verification section is fundamentally incomplete, whereas an unaddressed stylistic suggestion is a missed optimization.

Each pass has five steps:

1. Lint the current markdown for structural issues.

2. Extract unaddressed improvement suggestions.

3. LLM rewrite with explicit required_suggestions and lint_issues.

4. Source-grounding check: each claimed improvement must map to an exact quote (\(\leq\)​20 words) found via deterministic substring matching against the original source, not LLM-based verification. This confirms that the skill’s claims trace back to the source document, a safeguard against the ungrounded or hallucinated content that open-ended generation is prone to [18]; it does not independently verify factual correctness.

5. Score comparison: keep the better version.

The loop stops when the score hits 0 or the maximum passes are exhausted.

In our experience, most skills reach score 0 within 2 passes. For example, a skill starting at score 305 (lint_count=3, missing_count=5) typically reaches 0 in two rounds. We have not yet collected pass-count histograms across the full corpus; a systematic breakdown is planned for a future release.

3.5 Publishing and Quality Control↩︎

Skills must pass a final quality gate before inclusion in published bundles.

Publish Gate↩︎

The publish gate applies four independent criteria, all of which must be satisfied for a skill to be included in the final bundles:

• Overall score \(\geq\) 3.0. This threshold excludes clearly defective skills (scores 1 or 2) while retaining the broad score-4 majority that, despite LLM score inflation, represents skills of adequate quality.

• License whitelist/blacklist. GitHub and repository sources permit MIT, Apache-2.0, BSD-*, ISC, MPL-2.0, and Unlicense. GPL-3.0, AGPL-3.0, and LGPL-* are denied as strong or network copyleft, whereas MPL-2.0, a weaker file-level copyleft, is permitted. Forum sources accept CC-BY-SA-4.0 and CC-BY-SA-3.0. Web sources have no license whitelist in the current configuration. Important caveat: this is a technical default, not a legal determination. Plagiarism ratio enforcement reduces verbatim copying but does not resolve copyright or terms-of-service obligations. Operators should conduct their own compliance review for web-derived skills. The framework records source URL and attribution metadata for every skill, and the publish gate can be configured with stricter per-source policies.

• Plagiarism ratio \(<\) 0.35. The plagiarism ratio measures how much of the generated skill text is a verbatim copy of the source. Below 0.35 means the generation process adds real value: the skill must synthesize and restructure the source, not just reproduce it.

• “Not provided” count \(<\) 15. Skills with excessive placeholder text (e.g., “not provided” in the Inputs or Verification sections) indicate that the source material was insufficient for complete skill generation. A threshold of 15 occurrences filters the most egregious cases while tolerating occasional placeholders in optional fields.

In the current public release, the majority of skills derive from sources with explicit open licenses (MIT, Apache-2.0, BSD-* for repositories; CC-BY-SA for forums; Creative Commons for journals). Web-derived skills are included based on the plagiarism ratio threshold, but operators should treat this as a quality filter rather than a licensing clearance. The framework’s per-skill provenance records (source URL, license identifier, attribution) enable downstream consumers to apply their own compliance criteria or exclude specific source domains entirely.

3.5.0.1 Pipeline Accounting.

Table ¿tbl:tab:pipeline-funnel? traces the pipeline from source documents to published skills for the SkillGate-produced subset (114,565 skills), aggregated from the released SQLite bundles; the two integrated community collections (GitHub SkillMD and ClawHub, 102,373 skills) bypass this pipeline and are excluded here. Journal papers produce an average of 3.0 skills each, drawn from up to four skill kinds (idea_intro, experiment, method, picture); not every paper yields all four. GitHub, web, and forum sources each produce one skill per source. ArXiv preprints produce 2.1 skills per source. Of 114,565 pipeline-published skills, 302 (0.26%) have scores below the nominal 3.0 publish-gate threshold; these entered the corpus during early pipeline runs before the gate was fully enforced and will be removed in the next release.

SkillGate pre-filters sources before generation, but we do not yet track aggregate pass/fail counts across the full corpus. The SkillGate rejection rate varies by source quality: in observed batches, well-documented GitHub repositories pass at near 100%, while low-quality web pages and social media posts are rejected at higher rates. A systematic funnel breakdown (sources fetched \(\to\) SkillGate pass/fail \(\to\) generated \(\to\) publish-gate rejects) is planned for the next release.

Score Distribution Analysis↩︎

Table ¿tbl:tab:score-distribution? presents the quality score distribution broken down by source type, revealing both the systematic inflation pattern and the genuine cross-source variation discussed in §2.6. Figure 5 plots the same per-source distribution alongside the mean score for each source type.

The score-4 concentration is consistent across all high-quality sources (journal 85.7%, webpage 76.6%, arxiv 70.6%, github 69.5%, forum 69.4%), suggesting that the inflation is a property of the LLM scoring mechanism rather than a source-specific artifact. However, the concentration varies meaningfully: journals cluster most tightly at score 4 (85.7%) with few score-5 (1.8%), while GitHub is more dispersed with 16.1% at score 5, the highest of any source type. This is consistent with the scoring function favoring the direct, usage-oriented style of GitHub READMEs.

4 Downstream Evaluation: When Do Skills Help?↩︎

Our motivating claim is that skills improve the correctness of agent outputs, not merely whether they execute. We now report a controlled evaluation of that claim. Rather than asking only whether skills help, we design the study to isolate when they help, separating the value of a skill’s content from the confound of merely adding context, and the value of the retrieval mechanism from the question of whether the library actually covers a task’s knowledge needs.

4.1 Protocol↩︎

We evaluate on offline, objectively graded tasks: each task ships a prompt (task.md), a workspace, and a hidden reference checked by a verify script that returns an exact pass/fail. The pool spans 51 algorithmic and data-processing domains (SQL, parsing, encoding, graphs, data structures, file transforms, and others), roughly 2,000 tasks. A solver attempts each task with and without injected skills; reference and grader-internal files are withheld from the solver during solving and restored only for grading, so the agent cannot copy the answer.

To probe solver-independence we use four LLM solvers spanning weak to frontier across three providers: gemini-3.5-flash (Google), claude-haiku-4.5 and claude-sonnet-4.6 (Anthropic), and gpt-5-mini (OpenAI). For each task we compare paired arms on the same task instance:

• Baseline: no skills.

• +Keyword: the top-\(k\) skills retrieved from SkillCenter by FTS5 keyword relevance over skill titles (\(k{=}3\)); this is the realistic deployment path.

• +Placebo: three fixed, length-matched but deliberately irrelevant skills, to separate the effect of adding context tokens from the effect of skill content.

• +Oracle: on a separate probe (§4.3), the single genuinely needed skill.

Significance uses the exact paired McNemar test on discordant outcomes; \(\Delta\) denotes net discordant tasks (arm wins minus baseline wins). The general-task analysis is restricted to domains the solver can attempt (nonzero baseline pass rate), so the comparison has headroom. Per-solver task counts differ by design: gemini-3.5-flash, gpt-5-mini, and claude-sonnet-4.6 were each run on a shared 503-task subsample of the general pool, while claude-haiku-4.5 was run on the full 2,028-task pool; each \(n\) in Table ¿tbl:tab:downstream? is that solver’s count after the solvable-domain restriction. All tests are paired within a solver, so the differing \(n\) affect power but not the within-solver contrasts, and we do not compare pass rates across solvers.

4.2 Tasks Within the Solver’s Competence↩︎

Table ¿tbl:tab:downstream? (columns 2 to 5) reports paired pass rates on the general pool. Across all four solvers, keyword-retrieved injection is statistically indistinguishable from the placebo and never produces a real gain over baseline: it is flat for the weakest solver (already near ceiling on its solvable domains), mildly net-negative for the strong solver, and net-negative for both mid-tier models—significantly so for claude-haiku-4.5 (\(83\%\) vs.\(87\%\) baseline, \(-77\) net discordant tasks over \(n{=}1{,}979\), \(p<0.001\)) and directionally, though not significantly, for gpt-5-mini (\(-9\), \(p{=}.08\)). Because the keyword and placebo arms move together, the small effect is attributable to the extra context tokens, not to skill content: these algorithmic tasks lie within the models’ pretrained competence, so retrieved skills are redundant at best and distracting at worst.

4.3 Tasks That Exceed the Solver’s Knowledge↩︎

To create a genuine knowledge gap we built an agent-gap probe: 260 small, deterministic tasks each governed by an arbitrary, non-guessable convention (custom checksums, base encodings, formatting and reduction rules) whose specification lives only in an accompanying skill. By construction the answer cannot be inferred from the task statement alone. Table ¿tbl:tab:downstream? (columns 6 to 8) is unambiguous: the baseline, placebo, and keyword arms all solve \(0\%\), while injecting the relevant convention (oracle) solves \(72\) to \(100\%\) across solvers (\(p\) from \(10^{-13}\) to \(10^{-63}\)). Two observations follow. First, the injection mechanism works: when a skill carries information the solver lacks, the agent reads and applies it. Second, most solvers execute the supplied rule almost perfectly (gpt-5-mini \(100\%\), claude-sonnet-4.6 \(99\%\), gemini-3.5-flash \(98\%\)), with claude-haiku-4.5 the lone exception at \(72\%\); the fidelity gap tracks the individual model rather than solver strength. The keyword arm scores \(0\%\) here precisely because these synthetic conventions are not in SkillCenter, which isolates retrieval coverage, not the injection mechanism, as the binding constraint in practice.

4.4 Real Corpus Skills Close Real Knowledge Gaps↩︎

The agent-gap probe of §4.3 proves the injection mechanism but uses synthetic conventions that are deliberately not in SkillCenter. To test whether real corpus content carries knowledge that solvers lack, we built a second probe grounded entirely in the released library. We selected 18 source-grounded research skills whose bodies document specific, study-particular parameters (exact reagent doses and durations, cohort and screen sizes, instrument models, quality thresholds) that a base model cannot infer from general knowledge. Each task asks the solver to return the value the skill documents for a handful of named parameter keys, and grading is exact value recall with numeric formatting normalized. The four arms match §4.1; the oracle arm injects the single real skill that documents the parameters, verbatim as it ships in the bundle, while the keyword arm performs the ordinary FTS retrieval over all installed bundles.

Table ¿tbl:tab:realskill? reports the outcome across the same four solvers, and the pattern is identical for every one of them. The baseline, placebo, and keyword arms each solve \(0\%\) of the 18 tasks, while injecting the relevant real skill (oracle) solves \(61\) to \(78\%\) (pooled \(69\%\); net \(+50\) discordant tasks over \(n{=}72\), exact McNemar \(p\approx2\times10^{-15}\)). Three conclusions follow. First, the corpus genuinely carries operational knowledge the models lack: a real SkillCenter skill, injected verbatim, lifts pass rates from zero to roughly two-thirds. Second, the effect is skill content, not added context: the length-matched placebo, which holds token count constant, contributes nothing. Third, and most telling, the keyword arm also scores \(0\%\) even though the needed skill is present in the searched bundles; title-only FTS retrieval returns generic, off-topic skills (an OpenTelemetry instrumentation skill, an MCP-builder guide, a TensorFlow recipe) rather than the matching research protocol. Retrieval, not coverage or the injection mechanism, is therefore the binding constraint even when the corpus does contain the answer, corroborating with real content the conclusion §4.3 drew from synthetic conventions. These are deliberately narrow fact-recall tasks and a lower bound on skill utility; such cleanly offline-verifiable gaps concentrate in the source-grounded research subset, since much of the corpus is higher-level operational guidance whose value is harder to grade automatically. The probe generator and the exact-McNemar analysis are released with the framework (make_realskill_envs.py, mcnemar_arms.py).

4.5 Implications and Limitations↩︎

Together these experiments bracket the conditions for skill value: in our probes a skill helps an agent only when three conditions hold together: (i) the task requires knowledge the solver lacks, (ii) that knowledge exists in the library, and (iii) retrieval surfaces it. Indiscriminate keyword injection over tasks the model already handles is not beneficial, and is mildly harmful for mid-tier models, whereas a precisely targeted skill is decisive. This argues that downstream impact will come from gap-aware injection (inject only when a knowledge deficit is detected), higher-precision retrieval (semantic rather than purely lexical matching), and corpus coverage of model blind spots, rather than from corpus size alone.

Several caveats bound these claims. The solvers are single-shot, prompt-conditioned LLMs rather than full tool-using agentic harnesses, so the study measures one-shot skill conditioning, not multi-turn skill use. The agent-gap conventions of §4.3 are synthetic; the real-corpus probe of §4.4 complements them by injecting knowledge drawn verbatim from the library, but its tasks are deliberately narrow parameter-recall items rather than open-ended skill use, and clean offline-verifiable gaps concentrate in the source-grounded research subset. The general task pool skews toward algorithmic and data-processing problems, where strong models are near ceiling; broad coverage of the operational domains where the corpus should help most (niche tooling, evolving APIs) in a realistic multi-turn setting is not yet measured. We present this as an internal study that establishes the conditions for skill value, and extend it to a broad, human-validated, multi-turn agentic benchmark in future work (§6.5).

5 Related Work↩︎

SkillCenter draws on several lines of research: skill and memory libraries for agents, tool use and retrieval augmentation, large-scale corpus construction and deduplication, and community skill ecosystems. Table ¿tbl:tab:positioning? positions SkillCenter against a representative system from each line along the dimensions that matter for a retrievable skill library: scale, how the unit is produced, whether provenance and licensing are tracked, and whether redundancy is measured.

Skill and memory libraries for agents. Several systems equip agents with reusable skills or memory. Voyager [19] incrementally builds a library of executable programs while exploring an open-ended environment; Generative Agents [22] maintain a memory stream that is retrieved and reflected upon; Reflexion [23] stores verbal self-feedback to improve across trials; and ReAct [24], building on chain-of-thought prompting [25], interleaves reasoning traces with actions. These methods construct skills or memories online, specific to one agent, task, or environment. SkillCenter is complementary: a large, static, cross-domain library built offline from external evidence sources, designed to be retrieved by many agents rather than grown by one.

Tool use and retrieval augmentation. A parallel line equips models with external capabilities. Toolformer [26] and Gorilla [27] teach models to invoke APIs, while retrieval-augmented generation [21] and Self-RAG [28] condition generation on retrieved documents. Skills differ from both: tool use targets executable API calls and RAG retrieves raw document chunks, whereas a skill is a curated, quality-scored, source-grounded unit of operational guidance (§2.1). SkillCenter can be viewed as supplying a retrieval corpus for an agent’s operational knowledge, distinct from the factual corpora typical of RAG.

Corpus construction and deduplication. SkillCenter is also a data-curation effort. Self-Instruct [20] synthesizes instruction data from a language model, while large pretraining corpora such as The Pile [29] and heavily filtered web collections such as RefinedWeb [30] emphasize diverse, documented, and quality-filtered sources. A recurring lesson is that deduplication improves downstream model quality [31]; our redundancy analysis (§2.5) follows this practice, using MinHash with locality-sensitive hashing [32] to quantify near-duplication. Unlike purely synthetic instruction sets, every SkillCenter skill carries an explicit source URL and passes a source-grounding check.

Skill ecosystems and agent safety. Community skill marketplaces such as ClawHub [7], [10] distribute manually contributed skills; SkillCenter instead automates extraction at scale while keeping provenance explicit, and integrates such a marketplace as one bundle. Finally, because agents execute retrieved content, safety is central: a growing body of work benchmarks prompt-injection and tool-use risks [33]–[37]. We treat skill-level safety screening as future work (§6.3).

6 Future Work and Vision↩︎

SkillCenter is a starting point. Below we outline planned extensions and the broader trajectory we see for skill-based agent infrastructure.

6.1 Expanding the Corpus↩︎

On the academic side, we plan to integrate journals with complementary disciplinary coverage: Cell and other life-sciences families not yet covered; IEEE and ACM proceedings for systems, networking, and hardware; and PubMed Central’s open-access archive for clinical protocols. On the technical side, GitLab repositories, Reddit programming communities (r/programming, r/machinelearning, r/devops), and curated Hacker News threads offer practitioner knowledge that is less polished than GitHub documentation but often more candid about failure modes and workarounds.

Beyond English, we plan multi-language expansion targeting Chinese (CSDN, Zhihu) and Japanese (Qiita, Zenn) developer-community platforms. Informal social-media prose will likely require language-specific quality gates with stricter thresholds and culturally adapted rubrics. Multi-modal extraction from YouTube tutorials and Jupyter notebooks is also planned.

6.2 Quality Enhancement↩︎

The score-4 inflation (82.1% of scored skills) is the most pressing quality limitation. A score that assigns the same value to over 80% of items carries little discriminative information. We plan two complementary remedies: (1) human rating calibration, in which domain experts annotate a stratified set of 2,000 skills to provide ground truth for retraining the scoring rubric; and (2) multi-LLM cross-scoring, in which GPT-5.2, Claude, and open-source models independently rate skills, with systematic disagreement flagging candidates for manual review.

Two additional enhancements target corpus-level quality: semantic deduplication via vector-space clustering to detect near-duplicates, and skill versioning to auto-flag stale skills for re-extraction when source content is updated.

6.3 Safety, Security, and Guardrails↩︎

The current pipeline includes quality-oriented safeguards but not security-specific ones. SkillGate (§3.3) rejects spam, non-actionable, and excessively short sources; the publish gate (§3.5) enforces license whitelists, plagiarism thresholds, and placeholder limits. These mechanisms filter low-quality content but do not screen for adversarial instructions, credential exposure, or operations that could cause harm when an agent executes a retrieved skill unsupervised. As agent autonomy increases, this gap becomes a first-order concern: a skill that scores 5 on clarity and actionability but instructs the agent to exfiltrate environment variables is worse than no skill at all.

We plan to close this gap along three axes. First, source-level safety screening will add prompt-injection detection informed by recent threat taxonomies and benchmarks [33], [34], along with malicious instruction filtering and credential-exposure checks before skill generation. Indirect prompt injection, where adversarial payloads are embedded in content that an LLM later retrieves and follows, is a documented threat to tool-integrated agents [35]; the same attack vector applies to skill corpora built from open web sources. Second, skill-level risk annotations will tag published skills with properties such as privileged shell access, network access, external code execution, secret handling, destructive file operations, and domain-specific sensitivity (e.g., cybersecurity, biosecurity). These annotations will enable policy-aware retrieval: an agent operating in a sandboxed environment can restrict itself to low-risk skills, while a human-supervised agent can accept higher-risk skills with explicit approval. Third, execution-time guardrails in the agent integration layer will allow high-risk skills to be blocked, sandboxed, or routed through human approval before entering the active context window, following the principle that risk identification should be separated from risk mitigation [36].

On the evaluation side, we plan dedicated safety benchmarks drawing on agent-safety frameworks such as R-Judge [37] and AgentDojo [35] for prompt-injection robustness and risk awareness, supplemented by task-specific metrics for insecure code generation and unsafe command execution. We also plan red-team studies in which malicious or policy-violating sources are injected into the corpus-building pipeline to test whether SkillGate and the publish gate reject them reliably. Skills that are later found to be unsafe, stale, or policy-violating will be subject to a quarantine-and-revocation mechanism: flagged skills are excluded from future bundle releases, and a signed denylist can be distributed so that agents with managed deployments can filter them from already-downloaded bundles.

The goal is to make skills more useful and also safer to retrieve and safer to execute.

6.4 Sustainability and Continuous Growth↩︎

SkillCenter is designed for sustained growth, not one-time release. The underlying demand does not depend on any single paradigm label: as long as agents gain autonomy faster than they gain the operational judgment that human expertise once provided, structured knowledge must fill the gap. Three structural properties of the framework support this.

First, the pipeline runs continuously. Adding a new domain within the five supported source types requires only a domain configuration file (§3.2); no code changes are needed, and the five-stage architecture lets each stage be upgraded independently: a better LLM scorer, a new source API, or a stricter publish-gate threshold can be deployed without disrupting other stages.

Second, growth follows two complementary tracks. The automated track extracts skills from continuously published academic papers and technical sources, scaling with the literature rather than with manual effort. The planned community contribution channel (§6.5, item 7) will add a second track: externally submitted skills that pass adapted publish-gate checks (quality score, license compatibility, plagiarism ratio, and provenance verification) before inclusion. Open-source availability on GitHub and pre-built bundles on Hugging Face lower the barrier to both adoption and contribution.

Third, the corpus grows additively. Domain-split SQLite bundles mean that adding a new domain does not invalidate or require reprocessing of existing bundles. An agent that today uses only the Linux and Security bundles can later add Cloud or ML without re-downloading or re-indexing its existing skill set. This additive property is a practical prerequisite for a library that aims to keep pace with the expanding scope of agent-executed work.

6.5 Ecosystem Vision and Near-Term Roadmap↩︎

SkillCenter is complementary to manually curated marketplaces such as ClawHub [7], [10] (§5): community-authored skills capture practitioner intuition and edge cases, while automated extraction provides broad cross-domain coverage. SkillCenter currently distributes standalone SQLite bundles with its own search and integration layer (§2.7); format-level compatibility with OpenClaw’s skill specification is a planned engineering goal. The following concrete engineering steps are planned for the next release cycle:

1. Full-content retrieval. Extend the FTS5 index from title and domain to the full skill body (and add optional semantic retrieval), directly targeting the recall bottleneck identified in §4.

2. Latency benchmarks. Systematic measurement of search latency across small, medium, and large bundles, and multi-bundle configurations.

3. Improvement-pass histogram. Corpus-wide statistics on how many passes skills require to converge, replacing the current anecdotal observation.

4. Safety and guardrail evaluation. Dedicated benchmarks for source-level prompt-injection screening, skill-level risk annotation accuracy, and end-to-end red-team testing of whether the pipeline reliably rejects adversarial or policy-violating sources [33], [35].

5. Human calibration study. 2,000-skill stratified annotation by domain experts to provide ground truth for rescoring.

6. Multi-LLM cross-scoring. Independent rating by GPT-5.2, Claude, and open-source models, with disagreement-based flagging.

7. Community contribution channel. Accepting externally submitted skills with adapted publish-gate checks covering quality, licensing, plagiarism, and provenance.

8. Downstream evaluation. A controlled study measuring whether skill-augmented agents produce higher-quality outputs than unaugmented baselines on a representative task set.

Whether skills improve agent outcomes in practice is an empirical question that this roadmap is designed to answer.

7 Limitations↩︎

We state the main limitations of this work explicitly so that the released artifacts are not over-interpreted.

Scope of the downstream evaluation. The controlled A/B (§4) establishes when skills help: a precisely targeted skill is decisive on tasks whose knowledge the solver lacks, while keyword-retrieved injection over already-solvable tasks is statistically indistinguishable from injecting irrelevant text. The evaluation uses single-shot LLM solvers on a pool that skews toward algorithmic problems where strong models are near ceiling; extending it to a broad, human-validated, multi-turn agentic benchmark on domains with scarce operational knowledge is a natural next step (§6.5).

Quality rests on an internal signal. Every quality figure in this paper derives from a single-LLM scorer, and roughly 82% of scored skills receive the same score of 4 (§2.6). We therefore treat the 3.91 average as an internal QA signal, not external validation, and report no human evaluation, no inter-annotator agreement, and no comparison against baseline collections; the per-domain and per-source averages should be read with the same caution. Human calibration and multi-model cross-scoring are planned (§6.2).

Source grounding is traceability, not verification. The source-grounding check (§3.4) confirms that each retained claim maps to an exact quotation in its source through deterministic substring matching. It does not verify that the source is factually correct, current, or authoritative, nor that the skill’s actionable guidance (as opposed to an isolated quoted phrase) is fully supported. A skill grounded in an outdated or incorrect source can still pass.

Deduplication is lexical, and the headline count is heterogeneous. Our redundancy analysis (§2.5) uses MinHash over word shingles and therefore captures only lexical near-duplication; semantically equivalent paraphrases go undetected, so the reported redundancy is a lower bound. The full 216,938-skill count also aggregates two externally harvested community collections (102,373 skills) that bypass the pipeline’s quality gate and source-grounding; the pipeline-produced, quality-controlled subset is 114,565 skills, and readers requiring a uniformly processed corpus should use that subset.

Reproducibility depends on a proprietary scorer. Acquisition, SkillGate filtering, generation, and scoring all depend on a proprietary LLM. Re-running the pipeline with a different model would yield different skills and scores, and the 1-to-5 scores are not directly portable across scorers. We release prompts, configurations, and the resulting bundles, but exact reproduction of the scores requires the same model version.

Licensing is filtered, not cleared. The publish gate enforces a license whitelist for repository and forum sources and a plagiarism-ratio threshold, but web sources currently have no license whitelist (§3.5). The released bundles redistribute web-derived skills on the basis of this quality filter, which is a technical default rather than a legal clearance; downstream users who redistribute should perform their own compliance review. Every skill carries source-URL and attribution metadata to support this.

Residual legacy skills. A small number of skills (302, or 0.26% of the pipeline subset) carry scores below the nominal 3.0 publish threshold because they entered the corpus during early runs before the gate was fully enforced (§3.5); they are scheduled for removal in the next release.

8 Ethical Considerations and Responsible Release↩︎

SkillCenter is released as a research artifact, and several considerations shaped how we release it.

Safety screening is not yet in place. The current pipeline filters for quality, not safety: it does not screen retrieved content for adversarial instructions, indirect prompt injection, credential exposure, or operations that could cause harm when executed by an unsupervised agent (§6.3). Because agents execute retrieved skills, the corpus should not be deployed in autonomous, unsandboxed settings without the source-level screening, skill-level risk annotations, and execution-time guardrails outlined in §6.3. The quality-controlled pipeline subset (114,565 skills) and the unscreened community bundles are kept separate so that operators can opt into the more constrained subset.

Provenance and attribution. Every skill retains its source URL, license identifier, and attribution metadata, so that license obligations (for example, CC-BY-SA share-alike for forum content and Creative Commons attribution for journal content) can be honored by downstream redistributors. The publish gate enforces a license whitelist for repository and forum sources, but web-derived skills are admitted on a plagiarism-ratio basis only and are not legally cleared (§3.5); redistributors should perform their own compliance review.

Revocation. Skills later found to be unsafe, stale, or in violation of a source’s terms can be excluded from future bundle releases, and we plan a signed denylist (§6.3) so that managed deployments can filter already-downloaded bundles.

Intended use. The artifact is intended to supply operational guidance to agents under human oversight, not to replace human judgment in high-stakes domains. Our evaluation (§4) shows that skill injection helps only under specific conditions; we make no broader claim that skill augmentation improves agent outcomes in realistic deployments, which a larger multi-turn study is needed to establish (§6.5).

9 Conclusion↩︎

We have presented SkillCenter, a library of over 216,000 skills across 24 domain bundles, together with the automated, continuously running pipeline that produces its source-grounded core and the offline SQLite FTS5 bundles that distribute it. Every skill carries an LLM-assigned quality score (an internal QA signal), a source URL, and a full audit trail.

As agent autonomy expands into domains where errors carry increasing cost, the safety of retrieved skills becomes as important as their quality. We have outlined planned extensions along three axes: source-level safety screening, skill-level risk annotations, and execution-time guardrails. The framework’s continuous pipeline, modular architecture, and open-source distribution model are designed for sustained growth: new domains can be added without disrupting existing bundles, and a planned community contribution channel will complement automated extraction. A controlled evaluation (§4) shows that skill augmentation helps precisely when a task exceeds the solver’s own knowledge and retrieval surfaces the right skill; establishing this at scale on multi-turn agentic benchmarks remains ongoing work. The corpus and framework are open-source on GitHub,⁴ with pre-built bundles available on Hugging Face.⁵

Acknowledgements↩︎

We thank the open-access publishers, open-source maintainers, and community contributors whose works form the substrate of this corpus. We also thank the maintainers of the open-source tools on which the pipeline and this report depend, including SQLite and its FTS5 extension, the Python scientific stack, and the biblatex/tabularray LaTeX packages.

10 Duplicate Skills: Real Examples↩︎

The per-domain audit of §2.5 (computed with the reproducible dedup_by_bundle.py script, stable BLAKE2b shingle hashing) finds that all 21 SkillGate pipeline domains are effectively duplicate-free: every research and technical domain has zero verbatim duplicates and zero within-domain near-duplicate pairs, with the single exception of three borderline near-duplicate pairs in PLOS ONE (two unrelated articles that share only an auto-generated figure-extractor scaffold—a template collision, not a true duplicate; see Table ¿tbl:tab:dup-plos?). We therefore do not enumerate the clean domains here; instead, Table ¿tbl:tab:redundancy-audit-examples? lists only the domains that do contain duplicates, giving for each its verbatim and near-duplicate counts together with one concrete example and the distinct sources that produced the matched skills.

The reason the redundancy is so sharply localized follows from how each population is produced. Pipeline skills are generated once per source document and then source-grounded, so two pipeline skills can collide only if two different source documents happen to yield near-identical bodies; in practice this never occurs within a research or technical domain. The community bundles, by contrast, are harvested as-is from public repositories and a marketplace, so they inherit whatever redundancy already exists in the wild: a popular SKILL.md copied into dozens of skill-collection repositories appears dozens of times, framework scaffolds emit identical placeholder stubs, and successive versions of the same skill differ only in a version string or a few appended lines. A consumer who wants a deduplicated corpus can therefore drop or filter the three community bundles and retain the entire pipeline subset untouched.

10.0.0.1 What a duplicate actually looks like.

To make Table ¿tbl:tab:redundancy-audit-examples? concrete rather than merely counted, we reproduce one community skill together with one of its near-duplicates. The Anthropic theme-factory skill is copied byte-for-byte—the identical content hash—into many harvested repositories (for example davila7/claude-code-templates, Scoheart/agentskills, and garri333/Skills); its opening is:

A second harvested copy, in gabrielmoreira/agent-skills-mirror, is the same file as the Anthropic original with exactly one line inserted at the top of the frontmatter—a fresh re-indexing UUID. Table ¿tbl:tab:dup-sidebyside? places the two side by side: only the green line differs, and every other line is byte-for-byte identical.

That one cosmetic line changes the file’s content hash, so an exact-hash filter would file the two copies as unrelated; yet it leaves nearly every shingle shared, so MinHash still flags it at Jaccard \(\approx 0.98\). Hashing alone would therefore miss this copy—which is why we deduplicate with MinHash rather than hashing. MinHash is in turn only a lower bound: a third harvested copy, in Nucleon2/EcoSim-GenAI-hackathon, is the same skill rewritten: it preserves the ten theme names verbatim but paraphrases every surrounding sentence, so its MinHash Jaccard against the original falls below the \(0.8\) threshold and it is not counted as a near-duplicate—the exact blind spot behind the paraphrase caveat in §2.5:

The three boxes show both how the corpus is deduplicated and why the reported rate is a lower bound. Deduplication is applied at the bundle level (§2.5) because the community populations recycle a small set of popular skills verbatim or with mechanical edits—version strings, re-indexing identifiers, an appended stub—while genuine paraphrases such as the third box slip past lexical MinHash entirely. The 21 SkillGate pipeline domains contain none of these because each skill is generated once from a distinct source document.

10.1 One concrete duplicate per domain↩︎

Table ¿tbl:tab:redundancy-audit-examples? names one example per duplicate-bearing domain; here we make each one concrete with a side-by-side view, in the same format as the theme-factory pair (Table ¿tbl:tab:dup-sidebyside?), which is itself the curated-lite example. The three remaining domains each follow one of two patterns. In the two harvested community domains a popular skill is recycled with only cosmetic edits, so its body is byte-for-byte identical and MinHash Jaccard \(=1.0\): the code-search domain copies the Anthropic pptx skill (Table ¿tbl:tab:dup-pptx?) and the marketplace republishes one skill under two slugs (Table ¿tbl:tab:dup-clawhub?). In the pipeline, by contrast, the only “duplicate” is an auto-generated scaffold shared by two unrelated sources — a borderline template collision at Jaccard \(\approx 0.85\) (Table ¿tbl:tab:dup-plos?), not a recycled skill.

The two community domains above recycle a popular skill verbatim, but the 21 SkillGate pipeline domains contain no verbatim duplicates at all; their only flagged pairs are the three borderline near-duplicates in PLOS ONE. These are not recycled skills but scaffold collisions. The pipeline emits a small family of fixed-format helper skills for every paper—for instance, one that extracts a paper’s figures and open-data links—so two papers on entirely unrelated topics can receive structurally identical skills whose only differences are the title, DOI, publication date, and capture hash. Table ¿tbl:tab:dup-plos? shows the strongest such pair: a type-2-diabetes medication-adherence study (pone.0342056) and a marine-turtle nesting survey (pone.0338445) collide at MinHash Jaccard \(0.85\)—just over the \(0.8\) threshold—despite sharing no actual content, which is why the audit counts the pair as borderline rather than a true duplicate.

11 Reproducibility: Schema and Build Commands↩︎

Source code, configuration files, and prompt templates are available in the SkillCenter repository [38]. Corpus statistics correspond to release tag v0.1.0-report on GitHub and snapshot v0.1.0 on Hugging Face. Because acquisition depends on live APIs whose content changes over time, exact reproduction of the reported pipeline corpus from scratch is not guaranteed. To address this, the release archives the following frozen artifacts: per-bundle source manifests (listing every source URL and SHA-256 hash), the complete captures/ directory with raw extracted text, SkillGate decisions, and generated skill files, per-bundle statistics (skill counts, score distributions, kind breakdowns), and the ClawSkills.json configuration used for the reported build. These artifacts are included in the Hugging Face snapshot.

11.0.0.1 SQLite Bundle Schema.

Each domain bundle uses the following schema:

11.0.0.2 Bundle Build and Install.

To rebuild bundles from generated skills:

11.0.0.3 Skill Markdown Structure.

A typical technical skill follows this structure:

11.0.0.4 Reproducibility Checklist.

1. Prerequisites: Python 3.10+, pip install SkillCenter (installs all dependencies including openai, sqlite3, requests).

2. Configuration: Set OPENAI_API_KEY environment variable. Domain configurations are in config/ClawSkills.json.

3. Generate skills: Run SkillCenter generate with --domain and --topic flags. Output goes to skills/by-skill/<domain>/<method>/.

4. Build bundle: SkillCenter build-bundle --type lite --split-by-domain.

5. Install pre-built: SkillCenter bundle-install --auto downloads matching bundles to ~/.SkillCenter/.

6. Search: SkillCenter skill-search "query" --top 3 returns ranked results with title, domain, score, and kind.

12 Pipeline Implementation Parameters↩︎

Table [tab:pipeline-params] lists the exact implementation parameters used to produce the reported corpus. All parameters are configurable via ClawSkills.json or command-line arguments.

The parameters fall into five stages that mirror the pipeline of §3. The SkillGate stage fixes the pre-generation filter’s excerpt budget (4,000 characters), its minimum source length (200 characters, below which a source is failed without an LLM call), and the policy for borderline “maybe” verdicts (treated as pass, the permissive default). The Generation stage pins the LLM model, a low decoding temperature (0.2, dropped to 0.0 on retry for determinism), the JSON output mode, and the 12,000-character source truncation applied before prompting. The Improvement stage caps the refinement loop at three passes and records the composite score formula and the deterministic substring-match window used for source grounding. The Publish gate stage enumerates the four admission thresholds (minimum quality score, maximum plagiarism ratio, maximum placeholder count, and the license whitelist/denylist), and the Acquisition stage records the corpus build window, the number of domain configurations, and the per-source rate-limit settings. Reproducing the reported bundles requires the same model versions, since the LLM scorer and generator are proprietary and not pinned by these parameters alone (§7).

These parameters also separate corpus construction from query-time use. Acquisition, generation, refinement, and publishing are the only stages that require network APIs or LLM calls; after a bundle is released, installation and retrieval use local SQLite files. This distinction matters for reproducibility: changing the thresholds below changes the published artifact, whereas changing a user’s search query changes only how an installed artifact is retrieved.

13 Prompts and Scoring Rubric↩︎

For completeness we reproduce the operative content of the two LLM judgments that govern the pipeline: the SkillGate pre-generation filter (§3.3) and the 1-to-5 quality score (§2.6) assigned during generation self-review and enforced at the publish gate (§3.5). The boxes below are representative of the rubric content rather than byte-for-byte transcripts; the exact wording is version-controlled with the released configuration [38], and the associated parameters (model, truncation lengths, thresholds) are listed in Appendix 12.

13.0.0.1 SkillGate prompt.

The gate receives a source excerpt truncated to 4,000 characters and returns a structured JSON verdict; sources shorter than 200 characters are failed without an LLM call (§3.3).

13.0.0.2 Quality-score rubric.

After generation and iterative improvement (§3.4), each skill receives an integer score on a 1-to-5 scale; the publish gate (§3.5) admits skills scoring 3 or higher.

The improvement_suggestions returned here drive the iterative improvement loop (§3.4): its missing_count term counts the suggestions not yet addressed in the current draft, and the loop terminates when the composite score reaches 0 or the maximum number of passes is exhausted.

14 Worked Example: Source to Published Skill↩︎

The following traces one skill from raw source to published bundle entry, illustrating the pipeline end-to-end.

14.0.0.1 Source (excerpt).

The GitHub repository ca-risken/security-review (MIT license, 45 stars) contains a README describing a GitHub Action for automated security code review. The acquisition stage fetches the README (2,847 characters). Below is a representative excerpt from the source:

14.0.0.2 SkillGate.

The gate receives the 2,847-character excerpt and returns: verdict = pass, score = 8/10, good_signals = [“contains YAML code blocks”, “step-by-step setup instructions”, “clear input/output specification”], bad_signals = [].

14.0.0.3 Generation (excerpt).

The default (tech) template produces a skill titled “Add RISKEN Security Code Review to GitHub Pull Requests.” Below is a condensed excerpt of the generated skill:

Self-review: overall_score = 4, issues = 1, improvement_suggestions = 12.

14.0.0.4 Improvement.

Pass 1: lint_count = 0, missing_count = 8 \(\to\) score = 8. LLM rewrite addresses 8 suggestions. Evidence verification confirms 7/8 via deterministic substring match (e.g., the quote “Automatically review code in pull requests for security vulnerabilities” is found at character offset 48 in the source). Pass 2: lint_count = 0, missing_count = 1 \(\to\) score = 1. Final rewrite resolves remaining suggestion. Score = 0, loop terminates.

14.0.0.5 Publish gate.

Quality score = 5 (\(\geq\) 3.0, pass). License = MIT (whitelisted, pass). Plagiarism ratio = 0.18 (\(<\) 0.35, pass). “Not provided” count = 0 (\(<\) 15, pass). Skill is published.

14.0.0.6 Bundle entry.

The skill is stored in the security domain bundle:

15 Corpus Audits: Licensing and Safety↩︎

This appendix reports two artifact-level audits computed directly from the released bundles: the distribution of source licenses and a baseline scan for unsafe content. Both reinforce the pipeline-versus-community split seen in the redundancy analysis (§2.5): the quality-gated pipeline subset carries explicit open licenses and very little unsafe content, while the externally harvested community bundles do neither and should be treated with more caution.

15.0.0.1 License audit.

Every pipeline skill records an SPDX license identifier and a coarse risk class in its metadata. Table ¿tbl:tab:license-audit? summarizes the pipeline subset. Journal-derived skills are almost all Creative Commons (CC-BY-4.0), and repository-derived skills carry permissive software licenses (MIT, Apache-2.0, BSD, MPL-2.0); together, skills under an explicit open license account for the large majority of the pipeline subset. The residual with no SPDX tag is dominated by web-page sources, for which the publish gate applies a plagiarism-ratio threshold rather than a license whitelist (§3.5); these should be treated as filtered but not legally cleared. The two community collections are excluded from the whitelist entirely: the GitHub SkillMD bundle carries no per-skill SPDX field, and ClawHub items use a marketplace-specific scale that the audit maps to needs_review.

15.0.0.2 Safety scan.

Because agents execute retrieved skills, we ran a baseline scan of all 216,938 skill bodies for three risk classes using high-precision regular expressions: hardcoded secrets (cloud and API keys, private-key blocks), prompt-injection-style phrases (for example “ignore previous instructions” or requests to exfiltrate environment variables), and destructive shell patterns (for example rm -rf / or curl | sh). Table ¿tbl:tab:safety-audit? reports the counts, split by population. This is a pattern scan, not a semantic safety judgment, so the counts are an upper bound on genuinely harmful content (many injection-phrase and destructive-pattern hits are quoted defensively in security or DevOps skills). Two findings stand out: the absolute rates are low (well under 3% of skills in any class), and the risk is concentrated in the community bundles, which contribute the large majority of every category despite being a minority of the corpus. This localizes where the source-level safety screening of §6.3 is most needed and, in the interim, gives operators a concrete reason to prefer the pipeline subset for unsupervised deployment.

We treat these scans as a starting point, not a safety guarantee: they run after generation rather than as a gate, and pattern matching cannot catch obfuscated or semantically unsafe instructions. Integrating secret redaction, prompt-injection detection, and destructive-command flagging into the publish gate, together with per-skill risk tags, is the source-level screening prioritized in §6.3.

16 Full Skill Examples↩︎

The worked example in Appendix 14 traces one skill through the pipeline in condensed form. For completeness, we reproduce three complete published skills, lightly abridged only where marked, spanning the quality range: a strong technical skill, a strong paper-derived skill, and a borderline low-scoring skill.

16.0.0.1 Strong technical skill (GitHub, score 5).

Title: “Verify Dart Generated Code Is Up-to-Date with build_verify”; source: github.com/kevmoo/build_verify (MIT).

16.0.0.2 Strong paper-derived skill (PLOS Biology, paper.experiment, score 4).

Title: “Assess mitonuclear genotype-by-diet and parental diet effects on Drosophila fitness”; source: doi.org/10.1371/journal.pbio.3002218 (CC-BY-4.0).

16.0.0.3 Borderline skill (ArXiv, experiment_design, score 3).

Title: “Reproducible Experiment Plan: Diffusion-based Document Layout Generation (arXiv:2303.10787v1).” This skill scores 3, the lower edge of the publish gate: it is well-structured (audience, claims-and-metrics table, task breakdown) but long and preprint-derived, so its guidance is less immediately actionable than the two above, illustrating the kind of skill the 3.0 threshold retains but that human calibration (§6.2) may re-rank.

17 Datasheet↩︎

Following Datasheets for Datasets [39], we summarize the corpus’s motivation, composition, collection, preprocessing, uses, distribution, and maintenance.

17.0.0.1 Motivation.

The corpus was created to give autonomous agents a large, retrievable, source-grounded body of operational knowledge, and to study how such a library is best built and evaluated (§2.1). It was assembled by the authors as a research artifact.

17.0.0.2 Composition.

Each instance is a skill: a structured Markdown document with metadata (domain, source URL, SPDX license, quality score, skill kind, evidence quotes). The library contains 216,938 skills in 24 domain bundles, of which 114,565 are produced by the SkillGate pipeline and 102,373 are integrated from public GitHub SKILL.md files and the ClawHub marketplace. All skills are in English. Redundancy is quantified in §2.5 and Appendix 10; licensing and a baseline safety scan are in Appendix 15. The corpus is self-contained and references public sources rather than embedding personal data; it is not a sample of a larger set beyond the source populations described in §2.2 and §2.3.

17.0.0.3 Collection process.

Pipeline skills were acquired from journal APIs (PLOS, eLife), ArXiv, the GitHub REST API, curated web pages, and Stack Overflow, then filtered by SkillGate, generated with template prompts, source-grounded, and admitted by the publish gate (§3). The community bundles were harvested as-is via code search and a marketplace mirror and bypass the pipeline. The build window was January to March 2026 (Appendix 12).

17.0.0.4 Preprocessing and labeling.

Sources are truncated to 12,000 characters, canonicalized, and (for the pipeline) decomposed into skill kinds. Quality scores are assigned by a single LLM and are an internal signal, not human labels; roughly 82% of scored skills receive a 4 (§2.6). No human annotation, inter-annotator agreement, or external validation is included in this release.

17.0.0.5 Uses.

The intended use is retrieval-time operational guidance for agents under human oversight. It is not validated for autonomous, unsandboxed deployment, safety-critical use, or as ground truth for factual claims (source grounding is quote traceability, not verification; §3.4). The community bundles in particular are unscreened (Appendix 15).

17.0.0.6 Distribution.

The corpus ships as domain-split SQLite FTS5 bundles on Hugging Face and the framework is open-source on GitHub (§2.7), under the licenses recorded per skill. Redistributors of web-derived or community skills should perform their own license and safety review (§3.5, §8).

17.0.0.7 Maintenance.

The pipeline runs continuously and the corpus grows additively (§6). Skills later found unsafe, stale, or non-compliant can be excluded from future releases, with a planned signed denylist for already-downloaded bundles (§6.3). Corpus statistics correspond to release tag v0.1.0-report (Appendix 11).

References↩︎

---

1. https://huggingface.co/datasets/Tommysha/skillcenter-bundles↩︎

2. https://github.com/LabRAI/SkillCenter↩︎

3. Seven further GitHub-sourced skills fall in research bundles; the by-source-type totals in Table ¿tbl:tab:pipeline-funnel? therefore list 20,071 GitHub skills across the full pipeline subset.↩︎

4. https://github.com/LabRAI/SkillCenter↩︎

5. https://huggingface.co/datasets/Tommysha/skillcenter-bundles↩︎