1 Introduction↩︎

Large language model agents [1] are increasingly expected to do more than answer questions: they must operate software, call tools, inspect intermediate results, and produce high-quality artifacts such as slide decks, spreadsheets, web pages, 3D scenes, CAD designs, and audio projects. In these settings, success often depends less on isolated factual knowledge than on reusable procedural know-how: how to decompose a goal, which tool or API pattern to use, what intermediate state to inspect, and how to recover when an operation fails. We refer to such reusable procedural knowledge as skills. In the agent era, skills provide a natural abstraction from experience to reusable expertise: they convert observations of how tasks are solved into compact instructions, code fragments, visual references, and execution recipes that can be repeatedly invoked by future agents.

Recent skill-based agent systems [2] have already shown that such abstractions can be highly valuable. Code agents and software assistants benefit from reusable tool-use routines, while manually authored skill hubs have become a practical way to encode expert conventions for document editing, programming, data analysis, and other text-heavy workflows. However, existing skill libraries are still largely limited by how they are created: they are either hand-written by experts, accumulated from an agent’s own interaction traces, or mined from text/code resources. This leaves a major source of human expertise underused. For many commercial and creative software tasks, the most natural way humans learn is not by reading static documentation, but by watching tutorials, demonstrations, and screen-recorded workflows. A video tutorial can reveal the temporal order of operations, the visual effect of each editing step, and tacit design choices that are difficult to express in text alone.

This observation motivates a broader question: Can we automatically distill skills from multimodal human-created resources, especially tutorial videos, and use them to build a scalable skill library for software agents? The answer is not straightforward. Although frontier models have seen massive amounts of text during pretraining, and text resources are routinely exploited through retrieval and search, high-dimensional multimodal resources remain much harder to use effectively at inference time. Directly placing raw videos into an agent’s memory is expensive, redundant, and often impractical. A single tutorial may contain minutes of irrelevant setup, repeated narration, and visual details that are important only at a few key moments. At the same time, compressing video into a plain text summary discards precisely the information that makes video useful: dynamic operations, before-after visual changes, animation quality, spatial layout, timing, and tool interaction order. A practical system must therefore extract the procedural signal from videos and other resources, normalize it into a reusable representation, and organize the resulting knowledge so that agents can efficiently retrieve and execute the right skill for a new user request.

We introduce Resource2Skill, a framework for distilling executable skills from human-created resources and organizing them into a maintainable multimodal skill library for software agents. Given multimodal resources—including tutorial videos, source repositories, articles, documentation, and reference artifacts— Resource2Skill extracts domain-specific skills and stores them in a hierarchical Skill Wiki. Each skill is represented as a multimodal entry that may contain structured text, executable or adaptable code, visual examples, metadata, and provenance. This design makes the skill library more than a flat collection of retrieved passages: text explains applicability and mechanism, code provides tool-grounded execution patterns, and visual examples preserve layout, style, motion, and other perceptual information that text alone under-specifies.

A central design choice of Resource2Skill is to treat skill construction and skill use as a unified pipeline. Offline, we distill large-scale resources into a domain wiki for important commercial software scenarios. At inference time, given a user requirement, the agent first navigates the hierarchical index to form a candidate skill pool, then reads the relevant multimodal entries and composes them during execution. This hierarchical organization improves over flat retrieval because it encodes domain structure, narrows the search space, and exposes skill candidates at the appropriate level of abstraction. Moreover, when the offline library does not cover a requested capability, the same resource-to-skill operator can be invoked online to search for new resources, extract additional skills, and incrementally extend the library. The resulting system is therefore not a fixed prompt collection, but a growing and maintainable procedural memory.

We study Resource2Skill across seven practical software-authoring domains, including slide design, web page generation, spreadsheet authoring, Blender scene creation, CAD design, UE5 scene construction, and music production. These domains are chosen because they require different forms of procedural knowledge: some depend heavily on code and API conventions, some on visual design and layout, and others on temporal operations that are naturally conveyed by video. Our experiments show that skill access consistently improves agent performance across model backends and domains. Across our seven authoring benchmark suites (Web, Excel, Reaper, PPT, Blender, CAD, UE5), Resource2Skill improves the average overall score by \(+11.9\) percentage points over the same agents without skills, and outperforms strong agentic-harness baselines in \(26\) of \(28\) main-aggregate cells. Ablations further show that the hierarchical wiki interface, source diversity, multimodal skill format, library scale, online skill acquisition, and hierarchy-then-LM selection strategy each contribute to the final performance.

Our contributions are summarized as follows:

• Resource-to-skill learning for software agents. We formulate the problem of distilling reusable executable skills from multimodal human-created resources, with tutorial videos as a key underused source of procedural and perceptual knowledge.

• A hierarchical multimodal skill library. We propose a Wiki-based organization in which each skill combines structured text, executable or adaptable code, visual examples, metadata, and provenance, enabling agents to retrieve, inspect, and compose skills across diverse software domains.

• A unified offline-online construction pipeline. The same resource-to-skill operator is used both to build large offline skill libraries and to acquire new skills online when user requirements expose capability gaps, making the library maintainable and incrementally extensible.

• A broad empirical study across commercial authoring tasks. We evaluate Resource2Skill on seven authoring benchmark suites. Skill access yields consistent gains over no-skill agents and strong harness baselines, while controlled ablations isolate the value of source mix, multimodal format, wiki organization, selection strategy, and online acquisition.

2 Related Work↩︎

LM agents and reusable memory. Recent agents combine reasoning with tool invocation, executable actions, and execution feedback [3]–[13], and are now evaluated on realistic web and software-engineering tasks [14]–[19]. Procedural knowledge in these systems is largely implicit in weights, prompts, or interaction history; retrieval and memory work [20]–[26] and skill-library agents [9], [10], [27] make it explicit, but typically rely on self-generated traces rather than external human references.

Procedural knowledge from human-created resources. Instructional videos [28]–[32], web pages [33], and public code with documentation [34], [35] carry rich procedural supervision, but their raw form—long videos, descriptive articles, scaffolding-heavy repositories, outcome-only artifacts—is poorly matched to agent execution and is usually consumed as pretraining or retrieval context. Resource2Skill instead distills them into a validated multimodal wiki, turning source type, modality, library scale, and selection strategy into controlled design variables.

Comparison with skill-library frameworks. Voyager [27], AWM [36], ASI [37], and SkillFlow [38] grow text- or code-only libraries online from a single domain’s agent traces or failures and retrieve by dense similarity or repair rules; Anthropic Agent Skills [39] ships hand-authored text/code/asset bundles without automatic acquisition; SkillFoundry [40], closest in spirit, mines text/code skills offline into a top-down knowledge tree for scientific computing. Our work differs by combining offline-mined multimodal skills (videos, repositories, articles, reference artifacts), a hierarchical wiki interface with hierarchy-then-LM selection, artifact-level evaluation by vision and audio judges, and controlled online gap-filling, across seven authoring domains.

3 Method↩︎

We instantiate Resource2Skill as four stages (Figure 2): construction, wiki organization, selection, and execution. The same construction operator is reused online when the offline pool is insufficient, so online acquisition adds no separate pipeline, and all four stages share a single MCP-mediated browse-select-execute interface over domain-specific backends.

3.1 Hierarchical Multimodal Skill Wiki↩︎

A skill is a tuple \[s \;=\; \bigl(p,\; x_{\text{text}},\; x_{\text{visual}},\; x_{\text{code}},\; m\bigr),\] where \(p\) is the path of \(s\) in a domain-specific taxonomy \(\mathcal{T}_{\mathcal{D}}\) and \(m\) is metadata used for filtering, auditing, and provenance. The three content views are complementary: \(x_{\text{text}}\) states name, mechanism, applicability, inputs, and expected effects; \(x_{\text{visual}}\) provides thumbnails, screenshots, rendered previews, or diagrams; \(x_{\text{code}}\) contains executable or adaptable procedure fragments (visual and code fields may be empty for reference-only entries).

The taxonomy is domain-specific (e.g., PPT organizes by layout, typography, and motion; Blender by geometry, material, lighting, and composition) but the browse-and-read interface is shared. The full library for domain \(\mathcal{D}\) is \[\Sigma_{\mathcal{D}}\;=\; \bigl\{\, s : s \text{ accepted by the construction operator}\,\bigr\},\] and we treat its size as an experimental variable. The on-disk realization is given in Appendix 17.

3.2 Resource-to-Skill Construction↩︎

A construction operator distills multimodal resources into wiki entries. The resource pool \(\mathcal{R}_{\mathcal{D}}\) for domain \(\mathcal{D}\) is drawn from four families: tutorial videos, source repositories, articles, and reference artifacts.

A multimodal distiller maps each resource \(r \in \mathcal{R}_{\mathcal{D}}\) to candidate skills, \[\tilde{s}_{1:k} \;=\; f_{\theta}(r,\, \mathcal{D}),\] each expressed in the wiki schema above. Concretely, \(f_\theta\) retrieves resources against domain-specific queries, extracts modality-specific evidence (key frames, code regions and parameter signatures, prose passages, rendered exemplars), distills it into \((p, x_{\text{text}}, x_{\text{visual}}, x_{\text{code}}, m)\) via a vision-capable LM, and normalizes the result. A domain-specific predicate \(A_{\mathcal{D}}\) then enforces five checks—completeness, traceable provenance, deduplication, modality consistency, and structural executability of the code field when present: \[\Sigma_{\mathcal{D}}\;=\; \Bigl\{\, s = \mathrm{normalize}(\tilde{s}) \;:\; \tilde{s} = f_{\theta}(r, \mathcal{D}),\; r \in \mathcal{R}_{\mathcal{D}},\; A_{\mathcal{D}}(\tilde{s}) = 1 \,\Bigr\}.\] Per-domain library sizes and the executability protocol are summarized in Appendix 6. The same operator \((f_\theta, A_\mathcal{D})\) is reused at test time for online acquisition, so source mix becomes a controlled design variable rather than a hidden implementation detail.

3.3 Selecting and Composing Skills↩︎

Given a brief \(q\), the agent must choose a small subset of wiki entries to compose. MetaBrowse uses the wiki’s hierarchical organization in two stages: a lexical scorer narrows the candidate set to a topically relevant region of the taxonomy, then a language model selects a subset to compose. The first-stage score combines the entry’s name, tags, applicability text, and—critically—its taxonomy path \(p(s)\), \[\mathcal{C}_K(q) \;=\; \operatorname{TopK}_{s \in \Sigma_{\mathcal{D}}} \mathrm{BM25}\!\bigl(q,\; \mathrm{name}(s) \oplus \mathrm{tags}(s) \oplus \mathrm{applicability}(s) \oplus p(s)\bigr),\] so the wiki tree directly favours skills sitting in topically relevant subtrees rather than treating the library as a flat list. The language model then reads structured evidence for candidates in \(\mathcal{C}_K(q)\) and selects a subset to compose, \[\mathcal{S}(q) \;=\; \pi_{\phi}\!\bigl(q,\; \{\Phi(s) : s \in \mathcal{C}_K(q)\}\bigr),\] where \(\Phi(s)\) contains metadata and whichever text, visual, and code views are exposed by the current configuration. Selection is a subset rather than a ranking: the language model can pick zero skills if no candidate is a good fit.

3.4 Execution and Online Acquisition↩︎

The agent and domain adapter share one MCP tool surface. The wiki side exposes a small set of discovery actions (list categories, list skills with metadata cards, read per-modality content) together with a search action wrapping the BM25 shortlist; the domain side exposes a single apply action backed by a per-domain capabilities manifest, with structured not-applicable returns for missing capabilities. A run follows the same control loop in every domain (plan, MetaBrowse, apply, render), and selected skill code, when present, executes directly against the live MCP server with no language-model translation between selection and execution. Reference-only skills remain useful: the agent adapts their text and visual evidence to write its own code, and provenance is retained through the selected skill identifiers.

When \(\mathcal{C}_K(q)\) contains no adequate candidate, the same operator \((f_\theta, A_\mathcal{D})\) is invoked online: targeted queries are issued on the same resource families, returned resources are distilled into temporary candidates, validated by \(A_\mathcal{D}\), and exposed as a separate online pool for the current task or evaluation split. Offline and online pools are kept separate throughout the experiments, so online acquisition is a controlled gap-filler on capability regions known to be insufficient, rather than uncontrolled context expansion at test time.

4 Experiments↩︎

We evaluate Resource2Skill across seven authoring domains and four agent backends, comparing it against a no-skill ablation and two off-the-shelf agentic harnesses, and isolating the wiki interface, source mix, entry format, library scale, online acquisition, and selection strategy in controlled ablations.

4.1 Setup↩︎

4.1.0.1 Domains and briefs.

We evaluate on seven authoring domains: slide design (PPT), 2D drafting (CAD), web (HTML/CSS/JS), spreadsheet authoring (Excel), 3D scenes (Blender), real-time 3D (UE5), and audio production (Reaper). Per-domain backends and rendering paths are in Appendix 6. Each domain has a screened pool of \(80\) task briefs with no overlap with the resource corpora used to build the library; the brief author is blind to the wiki and the agent. The main comparison and the scaling and online/offline studies use a matched \(N{=}80\) subset per domain; ablations use matched \(N{=}40\) subsets. All conditions in a comparison share brief IDs, so within-table deltas are paired by construction.

4.1.0.2 Compared systems.

We sweep four agent backends—GPT-5.5, GPT-5.4, GPT-5.4 Mini, and GPT-5.4 Nano—against four systems. w Skills is the full Resource2Skill pipeline. w/o Skills is the same agent solving tasks through free-form code over the domain apply tool, with no skill library. ClaudeCode-H and Codex-H are the off-the-shelf Claude Code and Codex agentic harnesses (the -H suffix denotes harness, not human rater); CLI versions, invocation contract, and matched configuration are in Appendix 8. All agent and judge calls use temperature \(0\) and reasoning effort low. Studies and ablations use GPT-5.4 unless stated otherwise.

4.1.0.3 Judge and aggregation.

Non-audio artifacts are judged by a GPT-5.4 vision judge; Reaper is judged by an audio-capable GPT-4o-series judge. The judge is blinded to the system label and sees only the brief and the rendered artifact. Each domain has its own five-axis rubric (full protocol, weights, and human–judge agreement in Appendices [app:metrics] and 11); rubric scores in \(0\)–\(10\) are reported as percentages, and the overall score is the rubric-weighted mean. A run that fails to produce a scorable artifact—no artifact returned, or an artifact below a per-domain minimum-quality threshold—is treated as a failure and folds in at \(\text{overall}{=}0\).

4.2 Main Comparison: With-Skill vs Without-Skill↩︎

The first question is whether the skill library contributes measurable lift. We compare the four systems (w Skills, w/o Skills, ClaudeCode-H, Codex-H) on the matched-brief suite of \(N{=}80\) tasks per domain, repeated across the four agent backends. The judge, brief set, and decoding seed are held fixed within each model-domain cell, so score differences isolate the effect of the execution interface and skill access. Table 1 reports the overall score as a percentage.

4.2.0.1 Skills dominate across backends.

w Skills beats w/o Skills in all \(28\) main-aggregate model–domain cells, averaging \(56.8\%\) versus \(45.0\%\), a \(+11.9\)-point lift. Both off-the-shelf harnesses raise the no-skill agent on their own but remain consistently below w Skills: Codex-H reaches \(50.5\%\) and ClaudeCode-H \(50.4\%\) on the same matched briefs, and w Skills still beats the stronger of the two in \(26\) of \(28\) cells. The two exceptions (GPT-5.5 Web vs.ClaudeCode-H, GPT-5.4 Nano PPT vs.Codex-H) are within one point. The dominant lift therefore comes from the curated wiki, not from the execution harness alone. Per-cell deltas of w Skills over w/o Skills are statistically significant in every cell of the GPT-5.4 and GPT-5.5 backbones (paired Wilcoxon \(p < 10^{-3}\), with \(13\) of \(14\) cells at \(p < 10^{-8}\); full per-cell CIs in Appendix 12).

4.2.0.2 Lift concentrates where conventions matter.

Per-domain gains are largest where authoring conventions are dense and expensive to re-derive from a prompt—Excel, Blender, and Web at the larger backends—and largest of all on UE5 (\(+30\) to \(+40\) pp), where the free-form code agent rarely assembles a minimum-viable scene through the UE5 Python API and frequently returns artifacts below the per-domain minimum-quality threshold. Reaper sees the smallest gains, reflecting a relatively competent no-skill prior over the medium. A blinded human A/B study with five raters per pair on \(40\) matched pairs across all seven domains (\(200\) paired ratings, Appendix 16) corroborates the preference direction across all seven domains, with w Skills winning \(83.3\%\) of non-tied pairs against w/o Skills. Per-axis traces of the lift are in Table 7 (Appendix 13).

4.3 Studies↩︎

4.3.1 Skill-Library Scaling↩︎

This study asks how performance moves as we vary the size of the skill pool. Holding the agent, judge, brief set, and wiki interface fixed, we expose progressively larger category-balanced pools from \(0\) skills to the complete library and evaluate on the matched \(N{=}80\) brief suite in each domain. The \(0\)-skill condition is the same free-form baseline as the main comparison; the final tick in panel a denotes the full pool used by the main system.

4.3.1.1 Result.

Performance rises monotonically with library size in every domain and saturates near \(200\) skills. The first \(0\rightarrow 200\) slice carries the largest gains (between \(+3.1\) pp on Reaper and \(+14.2\) pp on Excel); the curve flattens after \(200\) and the \(400\rightarrow\)Full step adds at most \(+0.8\) pp per domain. Early entries cover common operations and recovery routines; later entries fill domain-specific gaps.

4.3.2 Offline and Online Acquisition↩︎

We compare Offline-only, which retrieves from a fixed pool of \(891\) distilled skills, against Offline+Online, which adds up to \(100\) skills distilled online when the offline pool is inadequate. We evaluate on two task sets: \(T_{\text{standard}}\) is the regular matched benchmark; \(T_{\text{novel}}\) is a stress-test suite targeting capabilities the offline pool failed to cover during preliminary screening. Online candidates are not folded back into the offline pool.

4.3.2.1 Result.

The two task sets reveal a sharp asymmetry. On \(T_{\text{standard}}\), online acquisition adds \(+0.7\) pp—essentially noise, since the offline pool already covers most common requests. On \(T_{\text{novel}}\), the same \(100\) online skills lift the mean score from \(41.2\%\) to \(62.8\%\) (\(+21.6\) pp). Online search is a gap-filler, not a booster; we therefore default to Offline-only for the standard benchmark.

4.4 Ablations↩︎

4.4.1 Skill + Wiki vs Skill Only↩︎

4.4.1.1 Setup.

We compare three GPT-5.4 conditions on the matched \(N{=}40\) subset per domain. w/o Skills disables the library; Flat exposes pure text skill descriptions as an unstructured list, removing category browsing, metadata, visual previews, and executable code; Our Wiki is the full skill-enabled wiki interface used by Resource2Skill. Panel b reports the three arms.

4.4.1.2 Result.

The flat text library already lifts every domain over disabling skills, confirming that reusable skill descriptions help on their own. Our Wiki is best in every domain and beats Flat by \(2.5\) to \(8.2\) pp, with the largest gains where category structure and code grounding matter most (Excel, Web, Blender). Hierarchical browsing narrows the search space; code and visual fields supply execution grounding that pure text under-specifies.

4.4.2 Wiki Construction↩︎

4.4.2.1 Source ablation.

The top row of Table 3 holds Video out (Code+Article+Artifact only) to test whether the other source families can recover video’s contribution; the next four rows seed with video and add zero or one supplemental source family; the bottom row combines all four. This design measures both video’s irreplaceability and the marginal utility of each supplemental source.

4.4.2.2 Source result.

Video is the non-substitutable source. Holding it out drops the average from \(68.9\%\) to \(59.4\%\), and the video-only library still outscores the three-source no-video library by \(7.4\) points. The video-removal drop concentrates where temporal operations and visual sequencing carry signal that text under-specifies (Excel \(-12.1\) pp, Web \(-9.8\)). Beyond video, no supplemental family dominates, but the all-source pool stays \(0.3\) to \(0.9\) pp ahead of the strongest two-source variant in every domain; diversity adds coverage insurance on top of video.

4.4.2.3 Matched-budget representation ablation.

This ablation isolates multimodal skill content from curated text memory. All conditions share the resource pool, accepted skill IDs, wiki frontmatter/metadata, BM25-then-LM budget, GPT-5.4 agent, and judge; only the post-retrieval content (text, visual thumbnail, executable code) changes. Thus Text is a strong curated text-memory baseline with matched metadata and retrieval.

4.4.2.4 Result.

Text reaches \(65.0\%\) because it already inherits applicability and routing cues. Visuals add \(+1.9\) pp, code adds \(+2.0\) pp, and Full ranks first in every domain at \(68.9\%\), attributing the remaining gain to multimodal skill content rather than curated memory alone.

4.4.3 Selection Strategy↩︎

4.4.3.1 Setup.

On the same matched \(N{=}40\) subset we compare six selection strategies under a fixed library, agent, judge, and candidate budget. Ours is the hierarchy-then-LM MetaBrowse selector. BM25 and Embed are retrieval-only baselines (lexical and dense, the latter a standard dense-retrieval RAG over the skill library); BM25+Embed combines them via dense reranking on a lexical shortlist. Random-FullPool samples uniformly from the skill pool; No-Skill disables skills as a floor reference.

4.4.3.2 Result.

The hierarchy-then-LM MetaBrowse policy wins in every domain, averaging \(68.9\%\) against \(66.0\%\) for BM25, \(64.2\%\) for BM25+Embed, \(60.0\%\) for Embed, \(58.0\%\) for Random-FullPool, and \(57.3\%\) for No-Skill. Its largest margins over the strongest retrieval-only baseline are on Excel (\(+5.0\) pp), PPT (\(+3.8\)), and Blender (\(+2.3\)), where task fit and complementarity are not captured by lexical or vector similarity alone.

5 Conclusion↩︎

Resource2Skill distills multimodal human references into a structured, executable Skill Wiki shared by offline construction and controlled online gap filling. Across seven authoring domains and four backends, skill access improves artifact quality by \(+11.9\) points over no-skill agents and beats two agentic-harness baselines in \(26\) of \(28\) main-aggregate cells. Our results show that distilling skills from human-created resources gives software agents reusable procedural knowledge that improves over both no-skill agents and strong agentic harnesses across diverse authoring domains.

6 Per-Domain Details↩︎

We summarize the implemented domain backends. Main results in Section 4 cover Web, Excel, PPT, Blender, Reaper, CAD, and UE5; ablations report the five-domain core (Web, Excel, Reaper, PPT, Blender), with CAD and UE5 included in the main comparison and held out from per-condition ablations to keep the within-table compute budget bounded.

6.0.0.1 Slide design (PPT).

Slides are generated as SVG and then rendered to native PowerPoint (.pptx) shapes, on a fixed 16:9 canvas. Categories: layout, typography, palette, chart, icon, photo, shell, and motion. Active wiki size at evaluation start: 996. Render path: deck playback is rendered to video/frame artifacts for scoring; static-only runs use the same rendered slide frames as a contact sheet.

6.0.0.2 Spreadsheet authoring (Excel).

openpyxl with optional xlsxwriter for formatting. Categories: data ingest, formula pattern, conditional format, chart, dashboard layout, named range. Active wiki size: 632. Render path: LibreOffice export to per-sheet pages, composited into a worksheet contact sheet.

6.0.0.3 Web (HTML/CSS/JS).

Vanilla HTML5 + CSS3 + ES2020. Categories: layout, animation, typography, interaction, component, theme. Active wiki size: 941. Render path: Playwright full-page screenshot at a 1280-pixel viewport.

6.0.0.4 3D scenes (Blender).

bpy (Blender 4.1) headless. Categories: geometry, material, lighting, camera, animation, environment. Active wiki size: 661. Render path: the saved scene or final PNG is rendered to a single hero-shot frame.

6.0.0.5 Audio production (Reaper).

REAPER ReaScript over MCP. Categories: instrument, effect chain, automation, mix, arrangement. Active wiki size: 934. Render path: WAV bounce, transcoded to a bounded MP3 preview for the audio judge; spectrograms are retained only as diagnostics.

6.0.0.6 2D drafting (CAD).

ezdxf with FreeCAD as a fallback renderer. Categories: primitive, constraint, dimensioning, hatching, layer, layout. Library size: 312. Render path: FreeCAD viewport screenshot from two orthographic angles, composited.

6.0.0.7 Real-time 3D (UE5).

Unreal Engine 5 driven through a UE5-MCP bridge that exposes editor-side Python actions (actor spawn, transform, material assignment, level lighting, sequencer keyframe, asset import) as MCP tool calls. Categories: actor placement, lighting, materials and PBR, level blueprint, sequencer/cinematic, environment, post-process. Library size: \(417\). Render path: editor viewport HighResShot of the saved level from a fixed camera, composited with a Lit-mode pass for scoring.

6.0.0.8 Skill-entry size and inference-time context budget.

Each skill entry on disk bundles agent-facing frontmatter (skill_name, category_path, applicability, tags, modalities_present), a structured prose body (text/overview.md: mechanism, use conditions, inputs, expected effects), and the executable code body (code/skill.py or domain-equivalent). Visual thumbnails are referenced by path and resolved to images only when the agent explicitly requests the visual modality, so they do not enter the text-token budget. Token estimates use a conservative four-characters-per-token rule on the concatenation of frontmatter, prose, and code, computed across every entry in the offline wiki snapshot used for the main comparison. Per-domain mean / median tokens per entry are PPT \(3{,}934\) / \(4{,}108\), Excel \(3{,}207\) / \(2{,}612\), Web \(5{,}726\) / \(5{,}479\), Blender \(4{,}248\) / \(3{,}937\), and Reaper \(4{,}170\) / \(3{,}925\); aggregated across these domains the mean is \(4{,}332\) tokens (median \(4{,}133\), \(25\)th percentile \(3{,}367\), \(75\)th percentile \(5{,}049\)). At inference time MetaBrowse forms a BM25 shortlist of \(K{=}20\) candidates over the wiki taxonomy and exposes their compact frontmatter (typically \(200\)–\(500\) tokens each) to the language-model selector, which picks \(n{=}5\) entries to expose to the agent in full. The skill-related context per task is therefore \(\sim 4\)–\(10\)k tokens for the selection step and \(\sim 22\)k tokens for the five fully expanded entries; total \(\sim 26\)–\(32\)k tokens, well within the working window of every agent backend used in the main comparison and independent of the total library size since both \(K\) and \(n\) are fixed before the run.

7 Benchmark Construction and Evaluation Protocol↩︎

7.0.0.1 Benchmark construction.

Each benchmark item is a task brief, not a demonstration. A brief specifies the domain, a stable brief_id, a slug, the natural-language request, and the required output path and artifact type. It does not name skills, source URLs, or solution steps. We generate candidate briefs from domain-specific prompt templates with fixed seeds, then screen them manually for clarity, feasibility under the domain backend, and absence of overlap with the resource corpora used to build the skill wiki. For each domain, we retain a pool of \(80\) screened briefs. The main comparison, scaling study, and online/offline study use a fixed matched \(N{=}80\) subset. Ablations use separate fixed \(N{=}40\) subsets sampled from the same \(80\)-brief pool because evaluating every ablation on all \(80\) tasks would exceed the available run budget; all conditions within a given ablation share the same sampled brief IDs. The online/offline study additionally constructs \(T_{\text{novel}}\) from capability regions that the offline pool fails to cover during preliminary screening, so it is a stress test for gap filling rather than a standard-distribution benchmark.

7.0.0.2 Run orchestration.

A run is one cell in the Cartesian product of domain, brief, and condition. All cells use the same agent loop and the same domain MCP server; conditions change only the skill access policy, wiki root, pool whitelist, source set, entry format, or harness baseline specified by the experiment. Unless a model ablation explicitly changes the backend, the agent uses GPT-5.4 with reasoning effort low. Each run follows the same four-stage loop: plan the task, browse or retrieve candidate skills when the condition permits it, execute through the domain apply tools, and verify by rendering the artifact. The experiment directories are self-contained: experiments/<name>/briefs.json stores briefs, runs/<domain>/<slug>_<condition>/ stores artifacts, logs/ stores the agent trace, and scores/ stores the judge JSON. Scaling pools and offline/online splits are fixed before launch and written to disk, so reruns reuse the same skill IDs rather than resampling the library.

7.0.0.3 Rendering.

Scoring always observes rendered artifacts rather than source files. Web outputs are rendered with Playwright full-page screenshots. Excel workbooks are exported through LibreOffice to per-sheet pages and stitched into a contact sheet. Blender outputs are scored from the final rendered PNG or a headless hero-shot render of the saved scene. PPT decks are rendered as presentation playback artifacts: when motion or transitions are part of the brief, we record video/frame evidence from the rendered slideshow; for static-only cells, the same pipeline reduces to rendered slide frames arranged as a contact sheet. Reaper projects are bounced to WAV, transcoded to a bounded mono MP3 preview, and sent as audio to the judge. CAD and UE5 follow the same artifact-first rule.

7.0.0.4 Scoring.

Non-audio artifacts are judged by GPT-5.4 with reasoning effort low. Reaper is judged by an audio-capable GPT-4o-series model on the bounced audio. Judges are blinded to the condition label and receive only the task brief, the rendered artifact, and the domain rubric. Each domain has five paper-facing axes: PPT uses layout quality, content density, theme coherence, typography hierarchy, and overall polish; Excel uses structure clarity, data density, chart quality, theme consistency, and overall polish; Web uses visual design, hierarchy clarity, section richness, modernness, and overall polish; Blender uses lighting, composition, materials realism, scene complexity, and overall aesthetic; Reaper uses low-end balance, transient clarity, spectrum balance, arrangement dynamics, and overall mix. The score file records an integer \(0\)–\(10\) raw score and a one-sentence justification for each axis; all paper tables and figures report these scores after multiplying by \(10\). The overall metric is the configured weighted mean of the five axes. Missing, unopenable, too-small, or silent artifacts receive \(\text{overall}{=}0\) and are counted as failures; failures are kept in the denominator when computing condition means.

7.0.0.5 Aggregation and reproducibility.

For matched comparisons, we aggregate over the same brief IDs within each domain and condition. Reported deltas are therefore paired by construction. Every score JSON stores the artifact path, render path, rubric breakdown, overall score, and judge metadata, which allows later re-aggregation without re-running the agent.

7.0.0.6 Brief generation is wiki-blind.

Benchmark briefs are generated by a separate language-model call whose prompt receives only (i) the domain name, (ii) a hand-curated per-domain guidance string that enumerates types of artifacts in the wild, and (iii) a fixed structural template that specifies output format and the required output path. The brief generator does not receive any skill identifier, wiki listing, library size, taxonomy tree, per-skill metadata, or aggregated benchmark statistic from prior runs. The per-domain guidance strings were authored once before the main benchmark and were not updated in response to subsequent benchmark scores.

7.0.0.7 Resource collection queries are taxonomy-driven, not brief-driven.

The construction operator’s resource queries are derived from per-domain category lists in the taxonomy that was hand-designed before benchmark briefs were generated. The query templates do not consume benchmark brief text, brief slugs, or any benchmark-side identifier; resource ingestion is a function of the taxonomy alone.

7.0.0.8 Acceptance thresholds are frozen before benchmark scoring.

The acceptance predicate \(A_{\mathcal{D}}\)’s thresholds (minimum schema fields, deduplication hash policy, executability gate, per-domain minimum-size constants) were tuned on a small dev-side resource sample drawn before main-benchmark briefs were generated and were frozen before the main comparison. Thresholds are not re-tuned in response to benchmark failure rates or per-cell scores.

7.0.0.9 No feedback loop from benchmark to library.

Per-cell failure rates, judge scores, and qualitative error analyses computed from benchmark runs are stored in scores/ alongside the run artifacts; they are not piped back into the brief generator, the resource collector, the taxonomy, or the acceptance predicate. The library snapshot used for the main comparison is the same snapshot used for the scaling and online/offline studies, and was frozen before any benchmark cell was scored.

8 Harness Baseline Configurations↩︎

This appendix documents the CLI versions and invocation contract under which ClaudeCode-H and Codex-H were run. Both harnesses are off-the-shelf agentic CLIs; we treat them as baselines rather than as custom-built systems, and intentionally retain their default planning and tool-use loops so that the comparison reflects the product a practitioner would actually deploy rather than a stripped variant.

8.0.0.1 Common protocol.

Both harnesses see the same brief, the same per-domain backend (SVG-rendered .pptx, openpyxl, Playwright, bpy/Blender, REAPER ReaScript, ezdxf/FreeCAD, UE5 Python), and the same output-path contract as w Skills and w/o Skills. Neither has access to the Skill Wiki or to any Resource2Skill-specific prompt. Within each model–domain cell of Table 1, brief IDs (\(N{=}80\) matched per domain), agent backend, judge model and decoding settings (temperature \(0\), judge reasoning effort low), output-path contract, and the per-domain failure-handling rule (overall\({=}0\) on missing or unscorable artifact) are held fixed across all four systems, so within-cell deltas isolate the execution interface. Both harnesses run inside a per-brief working directory and produce artifacts there; live web browsing is not used as a path to ground-truth answers in either harness.

8.0.0.2 ClaudeCode-H.

Anthropic Claude Code CLI, version 2.1.x. The CLI is invoked in non-interactive print mode with the brief on standard input and the per-brief working directory added to the tool-access scope. The underlying agent backend (GPT-5.5 / GPT-5.4 / GPT-5.4 Mini / GPT-5.4 Nano) is selected per row of the main comparison via the CLI’s model-selection flag and routed through the same model deployments used for w Skills and w/o Skills. We use the harness-default tool surface (file read/write/edit, shell, grep/glob, web fetch) and explicitly do not load a project-level instructions file or any skill files, so the agent has no Resource2Skill-specific priors. Permission prompts are bypassed so that runs are hands-off; reasoning effort is set to low, matching w Skills and w/o Skills.

8.0.0.3 Codex-H.

OpenAI Codex CLI, version 0.129.x. The CLI is invoked in non-interactive exec mode under a per-backend profile that pins the underlying model. Across all profiles we set the approval policy to never (no human-in-the-loop), the sandbox to workspace-write (the agent may write within the per-brief workspace), reasoning effort to low (matching w Skills and w/o Skills), and web search to cached (browsing is restricted to the cached snapshot rather than live retrieval). The model providers point at the same model deployments used for w Skills and w/o Skills, so judges, decoding seeds, and model identifiers are matched. As with ClaudeCode-H, no skill library is mounted and no Resource2Skill-specific prompt is injected.

8.0.0.4 Reproducibility.

The supplementary material includes the per-brief invocation contract for each harness, the per-condition run directories with raw stdout/stderr, agent traces, and produced artifacts, and the per-condition score JSONs that allow regeneration of every cell of Table 1 without re-invoking the agent or the judge.

9 Construction Operator and Acceptance Predicate↩︎

This section disaggregates the construction operator \(f_\theta\) into its prompt-based and deterministic components, and lists what the acceptance predicate \(A_\mathcal{D}\) actually checks.

9.0.0.1 \(f_\theta\): prompt-based distillation with deterministic post-processing.

The construction operator is implemented as a vision-capable language-model call, not as a fine-tuned model, with no learned parameters specific to Resource2Skill. Per resource \(r\), the operator (i) issues a per-domain query template against the resource connector to retrieve the resource bytes (video frames, repository tree, article text, or reference artifact), (ii) extracts modality-specific evidence using deterministic preprocessors (key-frame sampling for video, AST-aware code region extraction for repositories, paragraph segmentation for articles, image preprocessing for artifacts), and (iii) calls the language model with a per-domain prompt template that elicits a structured JSON skill payload (skill_name, category_path, applicability, tags, text_body, code_body, visual_caption, provenance). A deterministic post-processor normalizes whitespace, validates JSON shape, computes a stable skill identifier from a SHA1 hash of (domain, source_path), and writes the entry to disk. The language-model role is therefore prompt-engineering plus structured output, not learned scoring.

9.0.0.2 \(A_\mathcal{D}\): five deterministic gates.

The acceptance predicate is composed of five deterministic checks, each of which can independently reject a candidate skill. None is implemented as an LM-as-judge call.

• Completeness. A schema validator requires (a) all required frontmatter fields populated, (b) a non-empty text_body of at least a minimum prose length, and (c) at least one populated content modality. Rejected candidates have null or shorter-than-threshold fields.

• Provenance. A file-system check requires the resolved source_path (or video_url) to point to a retrievable resource recorded in the connector’s manifest. Rejected candidates either omit provenance or point to a resource that is not in the manifest snapshot.

• Deduplication. A SHA1 hash on (domain, source_path) yields a stable skill identifier; a candidate sharing an identifier with an existing accepted skill is collapsed into the existing entry rather than added separately. Near-duplicate detection is implemented as exact identifier match plus a normalized-name string-equality check on the same source.

• Modality consistency. A file-system check verifies that every modality declared in modalities_present resolves to a non-empty file at the expected sub-path. Rejected candidates declare a modality that is not on disk.

• Structural executability. For domains with executable skill bodies, a sandboxed test harness imports and runs the code_body against minimal sample inputs (and, where applicable, runs render and overlap gates on the produced artifact). The gate sets a Boolean exec_ok flag in the entry’s metadata; entries with exec_ok=False are retained in the wiki as reference-only and are filtered out by the agent’s default verified-only mode. The executability check therefore validates that the code is structurally runnable and produces a non-trivial artifact, not that it solves any particular benchmark task.

The split is therefore prompt-based distillation (one LM call per resource) plus deterministic post-processing and gating (five rule-based checks). The library is not curated by an LM-as-judge loop, and the gates do not consult the benchmark.

10 Retrieval and Composition Quality↩︎

The main paper reports end-to-end overall scores rather than disaggregated retrieval metrics. This section describes what the run logs contain so that retrieval-quality analyses can be reproduced from the released artifacts, and explains why the end-to-end comparison already constrains retrieval and composition quality.

10.0.0.1 What is logged per run.

For every (brief_id, condition) pair, the released run directory contains: (i) the BM25 shortlist of the top-\(K{=}20\) candidates with their lexical scores; (ii) the language-model selector’s transcript including the \(n{=}5\) chosen skill identifiers and a brief justification per pick; (iii) the agent’s execution trace recording which selected skills were actually invoked, in what order, and with what arguments; (iv) per-call tool invocation success and any apply-tool error returns; and (v) the final scored artifact and judge JSON. These logs permit downstream computation of precision-at-\(K\) against any reference relevance label, of selection-call success rates, and of per-skill invocation success rates without re-running the agent.

10.0.0.2 Why end-to-end already constrains retrieval quality.

The matched-budget design of the selection-strategy ablation (Table 5) holds the library, agent, judge, decoding seed, and candidate budget fixed across selection strategies; the only varying factor is how candidate skills are ranked and presented. Under that design, a strategy that retrieves irrelevant skills can fail in two observable ways: the language-model selector can refuse to compose with them (it is permitted to pick zero skills), in which case the agent falls back to free-form code and the score regresses toward the no-skill baseline; or the agent can attempt to compose with them and produce an artifact that the rubric scores poorly. Both failure modes show up as a lower overall score in the corresponding row, which is what we observe for the retrieval-only baselines (Embed \(60.0\%\), BM25+Embed \(64.2\%\), Random-FullPool \(58.0\%\)) relative to Ours (\(68.9\%\)).

10.0.0.3 Composition behaviour.

A run is a single ordered application of \(n{=}5\) selected skills (or fewer, if the language-model selector picked fewer); we do not perform multi-pass replanning or arbitration between conflicting skills, so the composition step is deterministic given the selected set. Composition conflicts therefore manifest as failures in the apply tool’s structured not-applicable returns or as artifact-level scoring drops; both are recorded in the run directory and contribute to the per-cell overall score.

11 Judge Reliability↩︎

We sampled 17 task–artifact pairs uniformly across domains and obtained five-axis scores from three human raters and from the corresponding automatic judge (GPT-5.4 for non-audio artifacts, audio-capable GPT-4o-series judging for Reaper). We report Spearman \(\rho\) between the judge and the rater median, and the intraclass correlation coefficient ICC(2,1) treating raters and judge as exchangeable. On the overall axis, \(\rho = 0.71\) and ICC \(= 0.66\); design and detail axes track human medians most closely, while utility shows the highest disagreement (judge tends to reward apparent functionality even when interactivity is absent). Per-axis numbers are tabulated in the supplementary material. We re-ran the judge on the same 17 pairs and obtained \(\rho = 0.83\) between runs, confirming that judge variance is substantially below judge–human variance.

12 Per-Cell Bootstrap CIs and Wilcoxon Tests↩︎

For every backend–domain cell of the main comparison (Table 1), Table 6 reports the per-brief win count of w Skills over w/o Skills on the matched \(N{=}80\) briefs, the cell mean for each system, the matched delta, the bootstrap \(95\%\) confidence interval for the delta computed with \(10{,}000\) resamples, and the paired Wilcoxon signed-rank \(p\)-value. We report the GPT-5.4 and GPT-5.5 backbones; analogous tables for GPT-5.4 Mini and GPT-5.4 Nano are produced by the same script from the released score JSONs.

The w Skills delta over w/o Skills is significant in every reported cell at \(p < 10^{-3}\), with \(13\) of \(14\) cells at \(p < 10^{-8}\). w Skills wins on every one of the \(80\) matched briefs in every reported cell.

13 Per-Axis Main-Comparison Details↩︎

Table 7 reports the per-axis breakdown of the GPT-5.4 main-comparison cell. Each domain is scored on its own five-axis rubric (full protocol in Appendix [app:metrics]); raw axis means are multiplied by \(10\) and reported as percentages. The w Skills column shows the mean and, in parentheses, the matched percentage-point difference \(\Delta\) relative to w/o Skills (green for positive).

14 Online Acquisition Details↩︎

14.0.0.1 Trigger and budget.

Online acquisition is activated only when the offline wiki fails to return an adequate candidate set for the requested capability. In the offline/online study, the offline pool is fixed at launch and the online arm is allowed to add at most \(100\) newly searched and distilled skills. This budget is held fixed across task sets so that the comparison measures coverage gain rather than unbounded resource access.

14.0.0.2 Validation.

Online candidates use the same construction predicate as offline candidates: the entry must have sufficient text evidence, traceable provenance, non-duplicate metadata, and a valid modality bundle. If executable code is present, it must pass the domain’s smoke check or be marked as reference-only. Rejected candidates are not exposed to the agent.

14.0.0.3 Pool separation.

Online entries are stored in a separate pool for the duration of the evaluation split and are not folded back into the offline wiki used by the main comparison or ablations. This prevents online search from silently changing the default skill library.

15 Case Studies↩︎

We pair one success and one failure case for each of five representative domains (Web, PPT, Excel, Blender, Reaper) on the GPT-5.4 backbone. Success cases are examples where the skill arm clearly improves on the no-skill arm; failure cases are manually authored diagnostic boundary probes where skill use exposes a visible limitation, such as partial grounding, unresolved parameter binding, or overly literal composition. We do not show pure missing-output failures. Each figure shows the two arms side by side.

These qualitative examples are manually authored boundary probes and are not included in the matched benchmark aggregates. They should therefore not be interpreted as counterexamples to the paired benchmark results. Instead, they are used to make the method’s limitations concrete: distilled skills improve average artifact quality, but they can still fail when a retrieved skill is only partially grounded, when symbolic bindings do not resolve, or when the agent composes a skill too literally.

15.0.0.1 Web success: cottagecore restaurant landing page.

Brief: build a farm-to-table restaurant page (cream, mossy green, floral motifs, rounded serifs; cottagecore digital) with a creative testimonials section. The skill arm produces a complete, content-rich long-scroll page with consistent typography and a styled testimonials block; the no-skill arm produces a thin scaffold-like page that reads as an unfinished template.

15.0.0.2 Web failure: retro-futurist tabletop game page.

Brief: build a one-page site for a retro-futurist tabletop game. Both arms report success: true and TASK_COMPLETE, so this is a quality failure rather than an execution failure: the skill arm is sparser and less finished, while the no-skill arm has fuller section coverage and stronger polish.

15.0.0.3 PPT success: corporate all-hands keynote.

Brief: build a \(10\)-slide internal all-hands deck for a customer-success team (sober and corporate, blue/gray restrained) with cover, agenda, dividers, content slides, and closing. The skill arm produces a deck with shell variety, dense per-slide content, and consistent theming; the no-skill arm produces a thinner deck with several placeholder-feeling slides.

15.0.0.4 PPT failure: product strategy quarterly review.

Brief: build a \(10\)-slide quarterly review deck for potential acquirers (sober and corporate, blue/gray restrained). The skill arm introduces unprocessed placeholder text and JSON-like fragments on the agenda slide and does not visibly inherit the chosen visual motifs; the no-skill arm is plainer but consistently styled.

15.0.0.5 Excel success: SaaS dashboard.

Brief: build a multi-sheet workbook with a summary dashboard, KPI blocks, and supporting detail sheets. The skill arm produces a summary-first workbook with KPI cards, dense data tables across sheets, and a coherent chart system; the no-skill arm produces a much sparser workbook with smaller, less polished tables and limited cross-sheet structure.

15.0.0.6 Excel failure: dashboard with broken formulas.

Brief: build an Excel workbook with dashboard and supporting detail sheets. The skill arm reuses dashboard components from the wiki but leaves visible #NAME? formula errors on several cells; the no-skill arm avoids reusable components entirely and produces a cleaner, error-free aggregated dashboard. This case illustrates that a partially-grounded skill, with a referenced formula whose bindings did not resolve, can be worse than a simple bespoke layout.

15.0.0.7 Blender success: emerald jewelry hero shot.

Brief: render a single hero-shot 3D scene of an emerald ring with staged lighting and styled materials. The skill arm produces an identifiable hero subject with rim and key lighting (blue/amber treatment) and PBR materials; the no-skill arm produces a flatly lit primitive blockout that does not read as a jewelry render.

15.0.0.8 Blender failure: perfume bottle macro.

Brief: render a luxury macro of a glass perfume bottle. The skill arm inspects multiple glass and lighting skills but produces a washed-out final render that fails to show the bottle and its materials; the no-skill arm produces a simpler scene that at least reads as a recognizable bottle. This case illustrates that complex skill compositions can fail to ground when key parameters (background, exposure, camera) are not visibly inherited.

15.0.0.9 Reaper success: deep house track.

Brief: produce a \(30\)–\(60\) s deep house track with sidechained bass, harmonic layering, and arrangement dynamics. The skill arm adds audibly grounded sidechain pumping, a distinct bassline, harmonic layering, and clearer intro/main/outro variation; the no-skill arm is competent but flatter in arrangement dynamics.

15.0.0.10 Reaper failure: less-dynamic arrangement.

Brief: produce a short genre track with intro/main/outro variation. The skill arm is competent but stays in one section throughout; the no-skill arm produces stronger intro/main/outro variation and overall mix polish. Reaper has the smallest no-skill-to-skill margin in the main aggregate; this case is consistent with that pattern.

15.0.0.11 What the failures reveal.

Across the five failure cases, two recurring patterns emerge: (i) partial grounding, where a skill is selected and its surface pattern is borrowed but key bindings or parameters do not resolve in the final artifact (Web tabletop, Excel #NAME?, Blender perfume); and (ii) conservative composition, where the skill arm sticks closer to a single pattern and loses the variation a less-anchored agent would have introduced (PPT placeholder, Reaper less-dynamic). These patterns are consistent with the Random-FullPool and Embed retrieval baselines underperforming Ours in the selection ablation: a skill is only as useful as the agent’s ability to bind its parameters, and stronger selection narrows this binding cost.

16 User Study↩︎

We validate the main comparison with a blinded human A/B study. Artifact pairs are sampled from Section [sec:exp-main] balanced across the seven domains, and five human raters per pair view anonymized renderings side by side and choose the better artifact or declare a tie. We use this human study as an external validation of the automatic judge’s preference direction, not as a training or selection signal.

Inter-rater agreement is Krippendorff’s \(\alpha = 0.58\). Table 8 reports the per-domain breakdown. w Skills wins \(64.2\%\) of pairs and w/o Skills wins \(12.9\%\) (\(22.9\%\) ties); excluding ties, w Skills’s win rate is \(83.3\%\). The smallest margin is on Reaper (\(74.7\%\) excl.ties), consistent with its stronger no-skill prior over the medium in the automatic-judge results; the largest is on UE5 (\(91.8\%\)). The ordering of per-domain win rates tracks the ordering of judge overall-score deltas, supporting the use of the automatic judge as the primary signal in the main paper.

17 Skill Library Schema and Storage↩︎

Each skill is materialized as a modality bundle:

skills_wiki/<domain>/<skill_id>/
  source/        # provenance and resource references
  text/          # overview, mechanism, applicability, inputs
  visual/        # thumbnail, screenshot, render, or diagram
  code/          # executable or adaptable procedure, if available
  meta.json      # category path, tags, source type, validation status

The metadata includes skill_id, skill_name, domain, category_path, tags, applicability, source.type, provenance fields, and validation status. The prose body follows the same semantic sections used in the main text: mechanism, use conditions, inputs, and expected effects. This storage format is an implementation of the abstract tuple \(s = (p, x_{\text{text}}, x_{\text{visual}}, x_{\text{code}}, m)\) from Section 3.1.

18 Limitations↩︎

Most scores route through GPT-5.4 vision on rendered artifacts (Reaper through an audio-capable GPT-4o-series judge); judge–human agreement on the 17-task subsample (Appendix 11) is acceptable, and a blinded human A/B study with five raters per pair across all seven domains (Appendix 16) independently corroborates the preference direction reported in the main comparison. We do not claim generalization to domains lacking either a programmatic tool interface or a public stream of procedural content.

Online acquisition adds search, distillation, and validation latency on top of the normal benchmark pass. We deliberately keep it outside the main comparison and evaluate it only on a fixed online pool against \(T_{\text{novel}}\), where gap-filling is the question being asked; folding online search into the default pipeline would conflate library-scaling effects with uncontrolled context expansion at test time. The online/offline study therefore measures coverage gain on capability regions known to be insufficient, not unbounded test-time recall.

Our retrieval-style baselines (Embed, BM25+Embed) operate over the distilled skill library, not over the raw resource corpus (transcripts, repository chunks, articles) under a matched token budget. We leave a same-budget raw-resource retrieval comparison to future work.

References↩︎