Source-linked AI summary
Group of Skills: Group-Structured Skill Retrieval for Agent Skill Libraries
Kun Zeng, Yu Huo, Siyu Zhang, Zi Ye, Yuecheng Zhuo, Haoyue Liu, Yuquan Lu, Junhao Wen, Xiaoying Tang
TL;DR
Skill libraries make retrieval necessary, but flat skills or bundles can leave execution roles and visible requirements implicit. GoSkills retrieves anchor-centered groups, expands support groups, bottlenecks payloads, and renders a fixed execution contract without changing the downstream agent or environment. Across SkillsBench and ALFWorld, it preserves visible-requirement coverage, improves over flat access, and often improves reward and agent-only runtime relative to structural references.
Problem
Large skill libraries make retrieval necessary, yet existing atomic-skill and bundle interfaces can leave execution roles, visible requirements, and failure-avoidance guidance implicit.
Source: §1 · p. 2Method
Results
Across SkillsBench and ALFWorld, GoSkills preserves visible-requirement coverage, improves over flat skill-access baselines, and often improves reward and agent-only runtime relative to structural retrieval references.
Source: §1 · p. 2, §4.2 · p. 6, §7 · p. 9Takeaways & Limitations
Role-aware group organization provides a compact, directly usable retrieval context under a small presented-skill budget.
Source: §1 · p. 2, §7 · p. 9GoSkills depends on deterministic schema extraction, skill metadata, and visible pre-execution requirements, and may be less effective with sparse metadata, ambiguous requirements, long setup chains, or hidden constraints.
Source: §6 · p. 9
Abstract
from arXiv · showhide
Skill-augmented agents increasingly rely on large reusable skill libraries, but retrieving relevant skills is not the same as presenting usable context. Existing methods typically return atomic skills or dependency-aware bundles whose internal roles remain implicit, leaving the agent to infer the execution entry point, support skills, visible requirements, and failure-avoidance guidance. We introduce Group of Skills (GoSkills), an inference-time group-structured retrieval method that changes the agent-facing retrieval object from a flat skill list to a compact, role-labeled execution context. GoSkills builds anchor-centered skill groups from a typed skill graph, expands support groups through a group graph, bottlenecks the selected group plan into a bounded set of atomic skill payloads, and renders a fixed execution contract with Start, Support, Check, and Avoid fields, without changing the downstream agent, skill payloads, or execution environment. Experiments on SkillsBench and ALFWorld show that GoSkills preserves visible-requirement coverage under a small skill budget, improves over flat skill-access baselines, and often improves reward and agent-only runtime relative to structural retrieval references.
1 Introduction
GOSKILLS reframes skill retrieval as organizing a compact, role-labeled execution context rather than returning a flat skill list. Across SkillsBench and ALFWorld, it preserves visible-requirement coverage and improves over flat access while often improving reward and runtime.
Motivation and contribution
- GOSKILLS changes the retrieval object from atomic skills or bundles to anchor-centered, role-labeled execution contexts.Groups expose anchor, support, requirement, and failure-avoidance roles while leaving the downstream agent, payloads, and environment unchanged.Source: §1 · p. 2
Method contribution
- It organizes retrieval into anchor selection, support expansion, and bounded payload exposure, then renders an execution contract with coverage debt over visible requirements.This decomposition makes retrieved skills directly usable under a context budget.Source: §1 · p. 2
Evaluation
- Across SkillsBench and ALFWorld, GOSKILLS preserves visible-requirement coverage and improves over flat skill-access baselines while often improving reward and agent-only runtime.The evaluation covers technical selection and visible-requirement coverage alongside interactive decision-making.Source: §1 · p. 2
2 Related Work
Prior work makes external tools and skills retrievable through repositories, semantic matching, and graph structure, but retrieval remains distinct from presenting usable execution context. GOSKILLS targets this interface layer by organizing already-retrieved skills into role-aware groups before execution.
Tool and skill retrieval
- Tool and skill repositories make external capabilities reusable, but growing collections create a need for retrieval across diverse agent tasks and library settings.Prior work emphasizes packaging, discovering, and evaluating reusable skills and tools.Source: §2 · pp. 2–3
Structured retrieval
- Graph-structured retrieval recovers relations such as prerequisites, setup utilities, preprocessors, and formatters that independent nearest-neighbor matching may miss.GOSKILLS extends this structural view by shifting the decision unit from individual skills to small role-aware groups.Source: §2 · p. 3
Concurrent work
- Concurrent methods use structure for dependency-aware bundles or execution-time repair, whereas GOSKILLS performs group retrieval and expansion before execution and leaves the downstream loop unchanged.The distinction is where structure enters the skill-use pipeline.Source: §2 · p. 3
3 Methodology
GOSKILLS constructs reusable anchor-centered groups offline and deterministically retrieves, expands, bottlenecks, and renders them online. Its fixed contract exposes role-labeled skills and visible requirements while respecting a bounded context budget.
3 Methodology
- GOSKILLS is an inference-time group-level retrieval method that changes the agent-facing object from atomic skills to a compact role-labeled execution context.The downstream agent, skill implementations, and environment remain unchanged.Source: §3 · p. 3
3.1 Offline: Skill Groups and Group Graph
- Offline, it builds a typed skill graph, extracts bounded anchor-centered groups with support members and role, artifact, and visible-requirement metadata, and links groups through typed edges.Groups are reusable role templates rather than executable hidden programs; group edges encode support, artifact, visible-check, fallback, or incompatibility evidence.Source: §3.1 · p. 3
3.2 Online: Group Retrieval and Contextualized Exposure
- At inference time, GOSKILLS maps the query to a schema covering goals, anchors, operations, artifacts, constraints, failure cues, and visible requirements, using only pre-execution information.The schema excludes hidden tests, evaluator internals, and previous failure traces.Source: §3.2 · pp. 4–5
- Atomic retrieval results activate candidate groups, but the final retrieval decision ranks groups, selects an anchor, and greedily expands positive non-incompatible support groups under capped budgets.The selected group plan is capped at three groups and stops when marginal gain, group budget, or context guard is exhausted.Source: §3.2 · p. 5
- The selected plan is bottlenecked into presented atomic payloads by inserting lead skills first and selecting remaining skills under cost(B) ≤τ.Group structure guides planning without exposing every group member, while the online neighborhood and payload budgets are capped.Source: §3.2 · pp. 4–6
- Coverage-safe backfill preserves exact high-confidence facets such as frameworks, file extensions, APIs, formats, and explicit constraints, reporting remaining debt when it cannot fit.Backfill requires debt coverage, negative-applicability checks, and remaining budget.Source: §3.2 · p. 5
- The deterministic contract names the anchor, labels support skills, lists visible requirements, states negative guidance, and includes hydrated payloads for presented skills.It does not bind arguments, check preconditions, execute skills, or perform runtime graph repair.Source: §3.2 · p. 6
4 Experiments
Experiments compare GOSKILLS with no-skill, full-library, flat semantic, and dependency-aware retrieval settings across SkillsBench and ALFWorld. GOSKILLS generally improves reward and runtime while preserving visible-requirement coverage under bounded skill access.
4.2 Main Results
- Across SkillsBench and ALFWorld, GOSKILLS improves over No Skills and offers a favorable reward–runtime tradeoff against Vanilla Skills, Vector Skills, and Graph of Skills.The fixed contract can add prompt overhead, so GOSKILLS is not always token-minimal.Source: §4.2 · p. 6, Table 1 · p. 7
- On SkillsBench, GOSKILLS achieves the highest completed-run average reward for every evaluated backbone.Against Graph of Skills, GPT-5.4 reward rises from 36.4 to 48.9 while runtime falls from 603.7s to 352.9s.Source: §4.2 · pp. 6–7, Table 1 · p. 7
- On ALFWorld, GOSKILLS also achieves the highest reward across evaluated backbones, although margins are smaller than on SkillsBench.The benchmark emphasizes general multi-turn planning more than technical skill matching.Source: §4.2 · p. 7
- GOSKILLS passes all 40 visible-requirement items under each retrieval mode, achieving a 1.00 must-hit rate with fewer than four presented skills on average.This indicates coverage is preserved under a strict skill bottleneck.Source: §4.2 · pp. 7–8, Table 2 · p. 8
- Figure 3 compares method-wise reward within fixed-model mini-panels, with SkillsBench on the top row, ALFWorld on the bottom row, GOSKILLS in blue, and Graph of Skills in orange.The visual is organized to compare retrieval settings under each agent backbone.Source: Figure 3 · p. 8
5 Ablation Study
The ablations test library-size sensitivity, contract-only formatting, and core retrieval components. Results indicate that bounded group activation remains robust as libraries grow, while both formatting and group-structured retrieval contribute to performance.
Sensitivity to library size
- As the SkillsBench library grows from 200 to 2,000 skills under GPT-5.4, GOSKILLS maintains the highest reward at moderate scale while runtime remains stable and lower than competing methods.Vanilla Skills becomes increasingly expensive, whereas Vector Skills is more affected by retrieval noise from distractors.Source: Figure 4 · p. 8, §5 · pp. 8–9
Component ablations
- Rendering fixed Graph of Skills payloads with the GOSKILLS contract raises reward from 36.4 to 41.2 and lowers runtime from 603.7s to 516.2s, but remains below full GOSKILLS.Prompt formatting helps, but does not explain the full gain.Source: §5 · p. 9, Table 3 · p. 9
- Removing anchor selection, group expansion, or the group graph causes the largest performance drops, while removing coverage backfill lowers must-hit from 1.00 to 0.73.Removing role labels or AVOID preserves must-hit but worsens reward and runtime; Retrieved Skills Only shows flat presentation is insufficient.Source: §5 · p. 9
6 Limitations
GOSKILLS is limited to inference-time retrieval and contextualization over a skill library.
6 Limitations
- GOSKILLS cannot train the downstream model, execute tools, bind arguments, or adapt after failures, and it depends on metadata and visible requirements available before execution.It may be less effective with absent or disconnected capabilities, long setup chains, sparse metadata, ambiguous requirements, or hidden constraints.Source: §6 · p. 9
7 Conclusion
GOSKILLS changes skill retrieval from atomic skills or bundles to role-aware groups and reports improved coverage, reward, and agent-only runtime under constrained contexts. The appendix roadmap identifies supporting material for method specification and reproducibility.
7 Conclusion
- GOSKILLS preserves visible-requirement coverage under a small presented-skill budget and often improves reward while reducing agent-only runtime relative to structural retrieval references.The reported efficiency reflects downstream usability of role-labeled context, not uniformly lower token cost.Source: §7 · p. 9
A Appendix Overview
- The appendix complements the main paper with method specification, implementation reproducibility, retrieval analysis, and trajectory-grounded qualitative analysis.Table 4 maps appendix sections to these supporting roles.Source: A Appendix Overview · p. 13, Table 4 · p. 13
B Additional Method Details
GOSKILLS constructs reusable role-annotated groups offline, selects and bottlenecks them online under a budget, and renders the result through a fixed execution contract. Coverage debt exposes uncovered visible requirements, while the interface remains deterministic and downstream components unchanged.
B.2 Offline Group Construction
- Offline construction enumerates bounded typed-neighborhood groups, assigns roles and evidence facets, removes incompatible or redundant candidates, and builds reusable indexes and a group graph.The resulting pool is reused across queries.Source: §B.2 · pp. 13–14
B.3 Online Contextualization Algorithm
- Online contextualization selects an anchor group, adds support groups by marginal utility, bottlenecks selected members into bounded atomic payloads, and formats the execution contract.The procedure controls agent-visible context without changing the base retriever, environment, or execution loop.Source: §B.3 · p. 14, §B.5 · p. 15
B.4 Coverage-Debt Accounting
- Coverage debt records high-confidence visible requirements not covered by rendered payloads and may trigger budget-limited backfill; unresolved debt remains explicitly reported.Debt can persist when no eligible skill exists, the budget is exhausted, or the backfill cap is reached.Source: §B.4 · p. 14
B.5 Execution Contract Template
- The fixed contract exposes START, SUPPORT, CHECK, AVOID, SKILLS, and DEBT fields, with task-specific content deterministically filled from selected groups, payloads, query schema, and debt.Only bottlenecked or backfilled skills are exposed, and AVOID guidance is advisory rather than a runtime blocker.Source: §B.5 · p. 14, C Prompt and Interface Examples · p. 16
B.6 Complexity Details
- Online overhead is bounded by capped candidate, group, payload, and presented-skill sizes, so it is dominated by the activated group neighborhood rather than the full skill library.The reported terms include O(M¯ι), O(|Gq| log |Gq|), O(Pmax(L + ¯dH)Kmax), and O(bPmaxKmax).Source: §B.6 · p. 16
C Prompt and Interface Examples
- The interface uses a fixed downstream skeleton rather than task-specific prompt templates, with support roles and visible checks rendered from retrieval decisions.The prompt is the rendering surface for group-level retrieval, not the method itself.Source: C Prompt and Interface Examples · p. 17, SUPPORT · pp. 17–18
B.1 Comparison of Retrieval Units
- GOSKILLS differs from post-hoc bundle annotation by using role-aware groups before expansion, bottlenecking, and contract rendering.The same final payload budget supports comparison with Vector Skills and Graph of Skills.Source: Table 5 · p. 13, SUPPORT · p. 18
D Implementation and Hyperparameters
This appendix specifies deterministic implementation, evaluation, and accounting procedures, and presents matched SkillsBench evidence on role-aware group rendering, bounded graph-hydrated contexts, and retrieval-gate, reward, and runtime comparisons.
D Implementation and Hyperparameters
- The fixed implementation uses lexical seed retrieval, anchor-centered groups, group-graph expansion, a four-skill payload budget, three-skill groups, three selected groups, and a 9,000-character rendered-context cap.Scores are deterministic weighted sums over clipped normalized features, with fixed coefficients and penalties for redundancy, negative applicability, and payload cost.Source: §D.1 · pp. 18–19
E.1 Benchmark and Evaluation Protocol
- Evaluation keeps the downstream agent, execution loop, environment, prompts, and skill payloads fixed while changing only retrieved skill context; reward is primary, with tokens and agent-only runtime as efficiency metrics.Infrastructure failures are excluded from aggregate metrics, whereas evaluator-produced timeout outcomes remain valid task failures and contribute to reward, token, and runtime accounting.Source: §E.1 · pp. 19–20
- Group construction enumerates singleton, pair, and non-conflicting triple groups, assigns typed roles, rejects incompatible or redundant groups, and builds a weighted group graph.Online selection applies anchor correction, support marginal utility, coverage-debt backfill, bottlenecking, and Start/Support/Check/Avoid contract rendering.Source: §E.1 · p. 21
E.3 Retrieval-gate annotation protocol
- The retrieval gate uses 40 pre-annotated visible-requirement items per mode across 10 SkillsBench tasks, with labels based only on public task materials and shared across methods and ablations.Labels exclude hidden tests, evaluator internals, private oracle information, failure traces, and execution-time artifacts, preventing derivation from GoSkills outputs.Source: §E.1 · p. 20, §E.3 · p. 22
E.4 Retrieval Gate Details
- The final retrieval gate raises average must-hit rate from 0.73 to 1.00 in both evaluated modes.The same visible-requirement annotations are used to assess each method’s final presented context before execution.Source: §E.4 · p. 22, Table 17 · p. 23
E.5 Task-Level Retrieval Examples
- Representative traces show GoSkills pairing primary skills with support skills for artifacts, workflow dependencies, and visible checks, including fuzzy-match with pdf-reading and xlsx.Other examples include conditioning with matched-filtering and silence-detector, threejs with obj-exporter, and Lean theorem proving with lean4-memories.Source: §E.5 · p. 23, Table 18 · p. 23
E.6 Task-level paired bootstrap confidence intervals
- +12.5 percentage points reward and -250.8 seconds runtime versus Graph of Skills, with 95% confidence intervals excluding zero for both deltas.Task-level paired bootstrap resampling used 10,000 samples and supported the stability of GoSkills’ improvements over the strongest structural-retrieval baseline.Source: Table 19 · p. 24
E.7 Baseline specification and accounting
- GoSkills and Graph of Skills share the same four-payload and 9,000-character budgets, but GoSkills adds anchor/support planning, coverage-safe backfill, and role-labeled contract rendering.This comparison isolates context organization rather than changes to the downstream model, execution environment, or skill implementations.Source: §E.7 · p. 24, Table 20 · p. 25
E.8 Matched Paired Results
- Matched evaluation exposes at most 4 graph-hydrated payloads under the same truncation guard and a 9,000-character rendered skill-context limit.The graph-hydrated block retains dependency structure but does not render an explicit role-labeled execution contract.Source: §E.8 · p. 25
- 0.539 to 0.683 average reward favors GOSKILLS over Graph of Skills in the completed matched subset, with 10 wins, 3 losses, and 41 ties.The fixed paired slice similarly rises from 0.614 to 0.827, while the per-task snapshot subset shows 0.860 versus 0.620; error counts are mixed.Source: Table 21 · p. 25, §E.8 · p. 25
E.9 Token and Runtime Analysis
GOSKILLS adds modest structured-context token overhead but consistently reduces agent-only runtime across matched trajectory slices. Task-level efficiency is mixed, supporting a tradeoff in which explicit role and check structure can shorten downstream execution despite extra context.
E.9 Token and Runtime Analysis
- Agent-only runtime decreases in every paired slice despite modestly higher input and total tokens; the completed matched subset falls from 235.7s to 202.3s.The fixed, GPT-5.4, and fast-agent slices likewise decrease from 178.3s to 167.9s, 204.7s to 193.1s, and 156.6s to 137.2s.Source: §E.9 · p. 26, Table 22 · p. 26
- Task-level efficiency is mixed: invoice-fraud-detection reduces input tokens by 31.7%, while setup-fuzzing-py increases them by 24.2%.Other reported reductions include 18.7% input and 8.6% wall time for threejs-structure-parser, and 18.3% wall time for data-to-d3.Source: §E.9 · p. 26
E.10 Implementation Settings
- Unless otherwise stated, GOSKILLS uses four seed skills, at most three groups, at most four presented atomic skills, 1,800-character payload caps, and a 9,000-character rendered-context cap.Scoring weights and the downstream agent loop, environment, and payloads remain fixed across methods.Source: §E.10 · p. 26
F Failure and Error Analysis
The analysis separates retrieval-interface failures from downstream execution and infrastructure failures, then identifies coverage, execution, and efficiency boundaries for GOSKILLS.
Execution failures
- Downstream execution can fail after valid retrieval because GOSKILLS cannot execute skills, bind arguments, repair code, inspect hidden state, or force correct multi-step behavior.Completed reward-0 outcomes are retained as substantive execution failures rather than infrastructure noise.Source: F Failure and Error Analysis · pp. 26–27
Retrieval-side failures
- GOSKILLS retrieval failures occur either when seed evidence fails to activate a relevant group or when bottlenecking drops required support skills.Coverage debt checks whether high-confidence visible requirements remain covered, but does not establish successful execution.Source: F Failure and Error Analysis · p. 26
Context overhead
- GOSKILLS can add context overhead without improving trajectories, especially when the agent over-builds, ignores the contract, or fails the task check.These cases are classified as context-overhead or downstream execution failures rather than retrieval misses.Source: F Failure and Error Analysis · p. 27
Efficiency failures
- Efficiency is mixed: GOSKILLS shows gains on invoice-fraud-detection, threejs-structure-parser, and data-to-d3, but increases input tokens on setup-fuzzing-py; compact anchor/support/check tasks benefit most.Source: F Failure and Error Analysis · p. 27
G Qualitative Analysis
The qualitative analysis shows that role-labeled retrieval is most useful when tasks have compact anchor/support/check decompositions, while existing dependency-aware retrieval can suffice and long-horizon or setup-heavy tasks remain bounded by execution and context demands.
G Qualitative Analysis
- GOSKILLS turns retrieved skills into an explicit START, SUPPORT, CHECK, AVOID, and debt contract, unlike Graph of Skills’ dependency-aware bundle.The case studies assess entry points, supporting artifacts, checks, and whether failures arise from retrieval, execution, or infrastructure.Source: G Qualitative Analysis · pp. 27–28
- GOSKILLS changes Azure BGP route-leak diagnosis from Graph of Skills reward 0.0 to reward 1.0, with 62.8s agent time versus 120.2s and 98,764 versus 112,467 input tokens.The case supports a mechanism-level interpretation: the contract clarifies starting points, support context, checks, and avoid cues.Source: G Qualitative Analysis · p. 28
- GOSKILLS reduces invoice-fraud-detection input tokens by 31.7% by exposing fuzzy-match as primary with pdf-reading and xlsx as support.The compact artifact chain illustrates reduced search burden without claiming Graph of Skills cannot solve the task.Source: G Qualitative Analysis · pp. 28–29
- On threejs-structure-parser, GOSKILLS presents threejs with obj-exporter and discover-important-function support, reducing input tokens by 18.7% and wall time by 8.6%.The example is treated as a qualitative mechanism case rather than standalone evidence of a reward gap.Source: G Qualitative Analysis · pp. 28–29
- Graph of Skills can already suffice on compact tasks such as 3d-scan-calc, where it completes with reward 1.0 in 96.399s and 33,853 tokens.When dependency-aware retrieval exposes the executable decomposition, GOSKILLS is expected mainly to preserve coverage or modestly affect efficiency.Source: G Qualitative Analysis · pp. 28–29
- Long-horizon completed failures and setup-heavy failures remain boundaries: adaptive-cruise-control and earthquake-phase-association are reward-0 completed outcomes, while setup-fuzzing-py increases input tokens by 24.2%.Setup-heavy failures are tracked separately from clean method-quality comparisons when reward artifacts are unavailable.Source: G Qualitative Analysis · pp. 28–29
H Additional Weaknesses
- GOSKILLS relies on deterministic schema extraction, typed metadata, visible requirement cues, and fixed handcrafted scoring weights, limiting robustness across ambiguous prompts, sparse metadata, implicit requirements, and other domains.The coefficients may fit the development distribution and may not be optimal for other libraries or task domains.Source: H Additional Weaknesses · p. 30
I Broader impacts
- The method does not filter unsafe skills, verify semantic correctness, or prevent misuse, so deployment requires library curation, policy checks, and task-level monitoring.These are identified as potential negative impacts of applying retrieval to automated coding agents.Source: I Broader impacts · p. 30
J Compute resources and API usage
The experiments use API-based agent evaluations on CPU cloud workers without model training or fine-tuning, with repeated runs and separate accounting for runtime and infrastructure outcomes.
J Compute resources and API usage
- All experiments are API-based evaluations that run retrieval, downstream agent loops, logging, and task evaluators on CPU machines without training, fine-tuning, or GPUs.Each worker uses 8 vCPUs and 32GB RAM in Ubuntu 22.04 cloud VMs with matched software environments and benchmark versions.Source: J Compute resources and API usage · p. 30
- Each model–method–benchmark combination is run three times, reporting mean input tokens and mean agent-only task-processing runtime while excluding environment setup.Infrastructure failures, timeouts, and valid outcomes are tracked separately, and inference uses provider endpoints with reported model snapshots and access dates.Source: J Compute resources and API usage · p. 30