Agent Skills from "Installable" to "Governable": Utility, Conflicts, Supply-Chain Security, and Skill Evolution (Deep Dive)

1. Background: What a Skill Is, and Why It Now Needs Governance

According to Anthropic's October 2025 engineering blog and the open specification that followed [1][2], a skill is a folder containing a SKILL.md. The metadata at the top of SKILL.md has only two required fields: name and description. At startup, the agent loads only the names and descriptions of all skills; when a task matches a skill, it reads the full SKILL.md; when it needs finer detail, it reads additional files in the folder or runs scripts. This design is called progressive disclosure, and it lets an agent "carry" many skills without filling its context.

The division of labor between skills and MCP (Model Context Protocol) is also clear: MCP "connects the tools," skills "teach the procedure." An expense-review skill might contain the review steps, common exceptions, and a script that validates invoice formats.

This "employee handbook" style of design, however, brings four previously overlooked problems:

1. Utility: Do skills actually help? Whom do they help?
2. Conflicts: When several skills are installed at once, which one does the agent follow?
3. Security: The text and scripts in a skill run with the current session's permissions, so a third-party skill hands "command authority" to a stranger.
4. Evolution: How can skills get better with use instead of messier?

Anthropic's original blog already warned to "install skills only from trusted sources" [1]. October's research shows, for the first time with large-scale data, that this warning alone is far from enough.

Technical lineage: from "experience reuse" to "a skill supply chain"

Skills did not appear out of nowhere. Placed in the lineage of agent research, they have gone through roughly three stages.

Prehistory: letting agents reuse "procedural knowledge." Before the SKILL.md format existed, researchers were already exploring how agents could accumulate and reuse experience. According to the related-work survey in the downstream-utility study, some work distilled experience into natural-language insights (e.g., ExpeL), some into executable programs (e.g., Voyager and ASI), and some into task workflows (e.g., Agent Workflow Memory) [3]. The common problem was that formats varied and were hard to carry across products.

Standardization: one folder, one SKILL.md. On October 16, 2025, Anthropic introduced Agent Skills on its engineering blog; on December 18 of the same year, it published them as an open standard for cross-platform portability [1]. Under the specification, agents load skills in three stages (discovery, activation, execution): at startup they read only names and descriptions, when a task matches they read the full instructions, and during execution they run scripts or read bundled files as needed. The standard is open to community contributions and has been adopted by a growing number of agent products [2]. A unified format gave rise to public skill marketplaces where developers publish, distribute, and reuse skills [3].

Scale: growth outpacing governance. The attack-surface study compiles earlier public figures: a December 2025 crawl of one marketplace found 15,082 skills, and a crawl of the same marketplace one month later found 73,193; by March 2026, a study spanning three distribution platforms and GitHub counted 238,180 unique skills [8]. The same paper notes that installing a skill asks the user to approve nothing beyond the copy itself, and what arrives is trusted by default. Earlier studies had already reported that a static analysis of 31,132 skills found roughly one in four carrying a vulnerability pattern and one in twenty showing likely malicious intent, and that a detonation study confirmed 157 malicious skills in the wild [8].

October 2026: from "is it malicious?" to "what happens once it is installed?" Research in this cycle broadens the question from malware detection alone to four dimensions: whether skills actually help [3][4], whether multiple skills interfere with one another [5][6][7], how much authority installing a skill actually grants [8][9][10][11], and how skills can be improved safely through use [12][13][14]. Skills are turning from "prompt attachments" into software assets that need version control, admission review, and continuous evaluation. That is the organizing logic of the four sections below.

2. Utility: More Skills Are Not Always Better

An empirical study of downstream utility (2026-10-06) [3]. The researchers built 87 tasks and a corpus of 37,596 skills to measure how skills perform in real use. Per the paper:

• On 36.78% of tasks, the same set of skills helps some "model + configuration" combinations and hurts others — trajectories show that procedures recommended by skills sometimes become an execution burden.
• Skills picked by "relevance" ranking are often not the most useful; re-ranking by "whether it supports the operations the task needs" raises top-1 pass rate by 4.35–5.80 percentage points.
• When a task is equipped with 5–6 skills at once, organizing them with a "stage plan" or a dependency graph (DAG) beats merely specifying an order. The authors distill 17 authoring practices from this.

The effect of skill revisions (2026-10-04) [4]. Another study tracks how revisions to skill text affect coding agents. Per the paper, after revision, agents' compliance with new rules rises by 0.41 on average, the share of required actions executed by 0.23, and blind-graded final correctness by 0.10; gains come mainly from rules that "name commands or paths the old version did not mention." But in real tools, skill bodies are loaded only when the agent decides they are needed, and in that setting the four agents retain on average only about half (51%) of the action gains — about 38% for the three open models; loading skill bodies increases token consumption per task by 50% on average.

Summary: A skill's value depends heavily on the combination of model, harness, and task — and "written in" does not mean "will be read."

Together, these two studies reveal a built-in tension in progressive disclosure: to save context, skill bodies are loaded only when "the agent thinks they are needed," yet the agent decides that based solely on the two lines of name and description. If the description is vague, the skill is never loaded; if it is too broad, the skill gets loaded on unrelated tasks and becomes an "execution burden." The description field therefore effectively serves as a routing rule and deserves to be written and tested as carefully as interface documentation. In practice, each skill can come with a small set of "should trigger" and "should not trigger" test tasks to check that loading behaves as expected.

3. Conflicts: What Happens When Two Skills Are Present

3.1 The Phenomenon: One Skill "Takes Over" Another

One Skill Too Many (2026-10-08) [5] starts from 20,947 GitHub repositories, filters 822,109 candidate skill pairs, and confirms 312 conflicting pairs that do "the same job." Per the paper:

• Nearly a quarter of installed skills are co-installed with another skill doing the same job; 37% of the judged skills sit in copied skill collections.
• Without reducing task completion, a similar skill "steals" execution from the intended skill in one-fifth of runs; runs that open the similar skill first lose more than a third of the core functionality "only the original skill provides."
• Which skill gets executed is decided by install location, not list order; in runs where the skill was replaced, only 0.9% of final replies stated which skill was actually used.
• The conflict is decided at the first skill read, almost always before any file is modified.

SkillClash (2026-10-18) [6] builds 16 pairs of same-job skills, with every rule checked automatically by code. Per the paper, across 7 models from 5 families (from 4B open models to Qwen3-235B and GPT-4.1), rule compliance is 93%–99% when a skill is loaded alone and drops to 61%–62% when loaded together with its counterpart. Most outputs show "takeover": all rules unique to one skill are followed, and all rules unique to the other are dropped. What drives the takeover is the examples in the skill files.

3.2 Algorithm ①: The "One Joint Example" Fix and the "First Read" Hook

One-line intuition: Models imitate examples more than they obey rules. If two conflicting skills each give an example that satisfies only themselves, the model copies one wholesale; give it an example that "satisfies both skills," and takeover drops sharply [6]. And since the conflict is decided at the first read, add a check at that moment [5].

Analogy: A new employee holds two operations manuals, each with a "model answer." They will most likely pick one and copy it. Give them a model answer that "complies with both manuals," and they know both sets of requirements must be met; remind them, as they open the first manual, that "this job is assigned to the other manual," and they will not take the wrong path.

Step by step:

1. Detect same-job skills: at install or load time, find pairs of skills that "do the same thing" by description and functional similarity.
2. Joint example: append to the end of each conflicting skill file one complete example that follows both skills (generated by a strong model in the paper, and it must be correct).
3. First-read hook: before the tool call in which the agent first reads a skill file, insert a check; if the file being read is not the skill assigned to the task, add a hint or redirect.
4. Make execution visible: state in the final reply which skill was actually used, for auditing.

Pseudocode:

on_tool_call(read_file, path):
if is_skill(path) and first_skill_read(session):
intended = resolve_skill(task, installed_skills)
if path != intended.path:
inject_note("This task should use skill: " + intended.name)
proceed()
log_final_reply(skill_used = session.first_skill_read_path)

• is_skill(path): whether the file being read is some skill's SKILL.md.
• first_skill_read: whether this is the session's first skill read.
• resolve_skill: decides "which skill should be used" from install configuration and task assignment.
• inject_note: appends a hint to the context rather than refusing the read outright.

Worked example (illustrative): Skill A requires "commit messages in English with a type prefix"; skill B requires "commit messages of at most 50 characters citing the ticket number." When each carries an example satisfying only itself, the model usually copies one side and drops all the other side's rules. Append one joint example — "feat: add retry to payment client (TICKET-123)" — which satisfies prefix, English, length, and ticket number at once, and the model follows both.

Results (per the papers): After ending each skill file with one example that follows both skills, the takeover rate drops to 1%–15% across 6 tested models; telling the model "which skill takes priority" does not recover the dropped skill; a single merged skill file written by Claude Opus 5.5 lets 7 models follow 96%–99% of reachable rules, with most of the gain coming from its one example — and the example must be correct to help [6]. In [5], adding a pre-tool hook at the first read restores the fidelity of "core functionality unique to the original skill" to the level of "opening the original skill first."

Why it works, and when it fails: It exploits the models' "examples first" behavior to correct conduct with a tiny change. Limitations: when the two skills' rules genuinely contradict (rather than merely differ), no example can satisfy both, and a human must decide; the first-read hook requires a harness that supports intercepting tool calls.

3.3 Composition as Attack: CoSA

Conflicts do not only degrade quality; they can be exploited. CoSA (2026-10-26) [7] finds that reviewing each skill individually cannot rule out policy violations after they are combined: artifacts or evaluation signals produced for one purpose may be reused by downstream skills, losing their original restrictions or authorizations. An attacker need only "supplement" an existing skill pool with a few skills that each look compliant to fill in missing business operations, or to reshape artifact exchange, decision reuse, and goal binding between skills — without altering any existing skill or runtime permission.

Per the paper, across 288 tasks covering recruiting, finance, IT, and business, 5 models, and 3 agent harnesses, adding no more than 5% to the original skill pool raises the policy-violation rate from 35.02% to 58.45%. The authors' lightweight defense is to check information flow and authorization before executing consequential actions; on OpenClaw recruiting tasks, this lowers the violation rate from 65.28% to 6.67%, while completion of compliant benign tasks changes only from 66.67% to 65.00%.

4. Security: Skills Are a New Supply Chain

4.1 How Large Is the Attack Surface?

Attack-surface profiling (2026-10-13) [8] runs static analysis, dependency-provenance checks, and sandboxed execution on 6,309 entries from two skill marketplaces. Per the paper: half of the entries can execute shell commands; 35% read the file system, 31% each write the file system and make outbound network connections, and 13% access credentials; seven in ten have at least one high-privilege capability. "Permission declarations" are largely a formality: of 6,061 entries whose front-matter could be parsed, only 770 declared anything, and 59% of those declaring under-reported their actual capabilities.

PyCache Trap (2026-10-07) [9] reveals a subtler gap: scanners inspect documentation and visible source code, but Python may execute bundled bytecode caches whose behavior can differ from the source. Per the paper, across 100 skills and 7 scanners, this "benign source, malicious cache" attack succeeds 94%–100% of the time, and the scanners show no semantic recognition of the cached behavior. The authors' Execution-Aware Verification (EAV) links instructions, scripts, import relations, and runtime artifacts into a typed execution graph and reproduces compiled artifacts in a trusted way, reaching 92.8% recall at a 10% false-positive rate across 5 attack classes and 200 benign skills.

4.2 Algorithm ②: SCS — "Compile" Natural-Language Instructions into Programs, Then Run Taint Analysis

One-line intuition: A skill's risk often spans two worlds — the text instructions and the code. The text tells the agent to read a file; the code sends it out. SCS compiles the text into a program representation as well, links the two dependency graphs, and propagates three labels along the graph: trust, sensitivity, and capability [10].

Analogy: When customs inspects a shipment, checking only the packing list (the text) or only opening the boxes (the code) is not enough; "who sent it, what is inside, and where it is going" must be strung into one complete chain.

Step by step (2026-10-24):

1. Instruction compilation: compile the natural-language steps in SKILL.md into a restricted, Python-style intermediate representation that may only use a set of security-oriented APIs (e.g., read file, send request, run command).
2. Dual-domain dependency graphs: build program dependency graphs for the instructions and for the bundled code (Text-PDG, Code-PDG), then connect them into a cross-domain graph, xPDG.
3. TSC labels: tag each variable with trust T (4 levels: trusted, locally provided, derived, untrusted), sensitivity S (5 levels: public, internal, system, confidential, top secret), and capability C (read, write, execute, network, persistence, environment variables, install, privilege escalation, obfuscation, etc.).
4. Propagation and rules: propagate labels along the xPDG and use deterministic rules to flag dangerous chains, e.g., "confidential data flows to a network capability."

Key formulas (illustrative):

T(v) = max{ T(u) : u → v }          (downstream takes the worst trust level)
S(v) = max{ S(u) : u → v }          (sensitivity takes the highest level)
Alert: a path x ⇝ y exists with S(x) ≥ confidential and C(y) ∋ network
Alert: a path x ⇝ y exists with T(x) = untrusted and C(y) ∋ execute

• u → v: the value of u flows to v in the dependency graph; x ⇝ y: a path exists from x to y.
• T / S / C: trust, sensitivity, and capability labels; larger values mean less trusted and more sensitive.
• The propagation and rules above are an illustrative rendering of the paper's TSC model; see the original for the exact rule set.

Worked example (illustrative): SKILL.md says "read ~/.aws/credentials to confirm the region configuration," and the bundled script sync.py POSTs a "configuration summary" to an external address. Read alone, the text is a reasonable configuration check; read alone, the code is an ordinary sync upload. Linking the two in the xPDG reveals: credentials file (S = top secret) → summary variable → network request (C = network), triggering an exfiltration alert.

Results (per the paper): On 117 malicious and 117 benign manually verified skills, SCS averages, across 5 LLMs, 85.6% accuracy, 95.2% recall, 86.9% F1, and 80.2% precision, consuming 13.7 million tokens on average; compiling natural language into the intermediate representation reaches 92.5%–94.5% step-level correctness on 400 manually annotated steps; scanning 66,157 real ClawHub skills yields 2,473 candidates, of which 627 are confirmed malicious after dynamic verification and manual review [10].

Why it works, and when it fails: It turns "reading text to judge intent" into traceable program analysis whose conclusions can be explained and re-checked. Limitations: the compilation step still relies on an LLM, and about 6% of steps may be compiled incorrectly; for execution paths "outside the visible source," such as PyCache, it must be paired with execution-aware verification [9].

4.3 High-Recall Pre-Screening: SkillScreen

SkillScreen (2026-10-13) [11] trains a compact decision model that outputs a maliciousness score directly from SKILL.md in a single forward pass. Per the paper, at 99% recall on unseen attack families it flags only 20%–25% of benign skills — fewer than word-level classifiers and prompted LLM judges — but false positives rise significantly on unfamiliar benign sources. It serves as the "mouth of the funnel": a cheap model filters out most benign skills first, and suspicious ones go on to deep analysis such as SCS and EAV.

5. Evolution: Making Skills Better with Use

5.1 Algorithm ③: SkillNEO — Skill Evolution That Allows "Temporarily Worse"

One-line intuition: Fixing a skill often takes several interdependent edits, and the score may drop halfway through. SkillNEO does not require every step to raise the score immediately; it selects "the version to use" and "the version to keep improving" separately [12].

Analogy: When renovating a house, between tearing down the old wall and finishing the new one, the house is messier than before. If the rule were "every step must look better than the last," the renovation would never be completed.

Step by step (2026-10-14):

1. Maintain a pool of skill versions, each with execution records and scores on the tasks.
2. Selection for use: pick the currently highest-scoring version for deployment.
3. Selection for improvement: separately pick a version "worth improving further," even if it scores below earlier versions.
4. Contrastive evidence: compare related versions on the same tasks to find "effective steps to keep" and "failures still to fix."
5. Generate a new version from the evidence, returning to earlier versions when necessary and revising them with later evidence.

Pseudocode:

pool = {skill_v0}
repeat:
deploy    = argmax_{v∈pool} score(v)
parent    = select_for_improvement(pool, evidence)   # need not be the top scorer
keep, fix = contrast(parent, related_versions, same_tasks)
child     = edit(parent, preserve=keep, repair=fix)
pool.add(child); evaluate(child)

• score(v): average reward of version v on the task set; deploy: the version in use.
• select_for_improvement: selects promising versions based on evidence; contrast: compares to find effective steps and remaining failures.
• edit: the executing model proposes changes and edits the skill.

Worked example (illustrative; scores hypothetical): A "generate report" skill v1 scores 50. v2 adds a "validate the data source first" step but gets the template path wrong, dropping to 45; an elitist strategy would discard v2 outright. SkillNEO keeps v2, fixes the path in the next step to get v3, and because the validation step reduces data errors, v3 scores 62.

Results (per the paper): On 86 SkillsBench tasks across 8 domains, SkillNEO raises GPT-5.4 Mini's average reward from 49.1% to 66.4%, into the range of GPT-5.5 and GPT-5.6 Luna using the original skills; these skills improved by a small model also boost stronger models without re-editing, lifting GPT-5.6 Luna by 10.5 percentage points on the 41 tasks whose skills were modified [12]. The search history also shows that some lower-scoring intermediate versions ultimately led to the selected skill.

Why it works, and when it fails: It applies the "non-elitist retention" idea from evolutionary search to a readable text object — the skill — and uses version contrasts to supply the direction of edits. Risks: the paper's final evaluation uses the same task instances as the evolution process, so generalization to new tasks needs independent verification; the growing version pool also adds evaluation cost.

5.2 Algorithm ④: AtomSearch — Atomic Edits + State-Tree Search

One-line intuition: When many rules change at once, it is hard to tell which one made the difference. AtomSearch restricts each edit to "one rule," records for each edit the failure cases it targets, a hypothesis, and its intended scope, and then combines these atomic edits with tree search [13].

Step by step (2026-10-14):

1. Contrastive atomic edits: each primitive rule edit is linked to failing and succeeding execution records, a behavioral hypothesis, and an intended scope.
2. Skill state-tree search: evaluate short combinations of edits, selectively keep them as executable states, and later backtrack and continue expanding.
3. Outcome memory: record "fix" and "regression" statistics for each kind of edit to inform later proposals.

Results (per the paper): Evaluated on 4 tasks and 5 target models, with deepseek-v4-flash it beats SkillOpt on 3 of the 4 tasks, including a 9.68-point gain on LiveMathematicianBench; 67% of the best states passed through a "non-top-scoring" ancestor state [13] — corroborating SkillNEO's "allow temporarily worse."

Worked example (illustrative; scores hypothetical): A skill has 10 rules, and the model fails on two kinds of tasks: "date format" and "null handling." AtomSearch generates two atomic edits — "normalize dates to ISO format" and "fill nulls with NA and log them" — each recording the failing samples it targets; evaluated alone, the first gives +2 and the second −1, but combined they give +5, because the null handling fixes an exceptional path in date parsing. The tree search keeps this combined state.

A shared lesson from both evolution methods. SkillNEO and AtomSearch reach the same conclusion from different directions: the search space of skill optimization is "rugged," and greedily keeping only the top-scoring version easily gets stuck in local optima. Both also stress "evidence" — every edit must be traceable to specific successful and failed execution records. This mirrors the software-engineering practice of "linking every commit to an issue and a test case." For enterprises, it means skill evolution cannot just be "let the model edit itself"; it needs three pieces of infrastructure: a version pool, an evaluation set, and an edit log.

5.3 Making Composition Executable: MetaSkill

When several skills must be combined to complete an open-ended task, MetaSkill (2026-10-17) [14] represents the composition as an executable directed acyclic graph, with each node retaining the flexibility of natural language and nodes connected by explicit dependencies and "predecessor text bindings." Per the paper, in the audited GLM-5.2 execution traces, all planned nodes completed and all declared ordering constraints were satisfied. This agrees with [3]: in multi-skill settings, explicit dependencies beat implicit ordering.

6. Side-by-Side Comparison

7. Our Views

First, the bottleneck of skills is shifting from "writing" to "governing." When a user's agent has dozens of skills installed, the biggest risk is not missing skills but not knowing which skill is at work. Only 0.9% of replies state the skill actually used [5] — that number is itself a governance gap.

Second, examples carry the "most weight" in a skill. SkillClash shows that takeover is driven by examples, and the fix relies mainly on one correct example [6]. Enterprises reviewing skills should review examples as rigorously as code.

Third, skill security must be handled as a "supply chain," not as "content moderation." Half with shell capability, 59% under-reporting permissions [8], and bytecode paths outside the source [9] show that "reading SKILL.md once" is nowhere near enough. A sensible architecture: high-recall pre-screening [11] → cross-domain static analysis [10] → execution-aware verification [9] → runtime information-flow guards [7].

Fourth, skill evolution must tolerate "temporarily worse." Both SkillNEO and AtomSearch find that the best path often passes through low-scoring intermediate states [12][13]. If enterprises manage skills with a gate of "every change must raise the score," they may miss genuine improvements.

8. Outlook

6–12 months:

• Skill marketplaces will introduce package-style signing, validation of permission declarations, and automatic comparison of "actual vs. declared capabilities."
• Mainstream harnesses will offer hooks at skill load and first read, and record the skill actually used in replies and logs.
• "Skill conflict detection" will become part of the install flow: installing a new skill will flag existing same-job skills.

1–3 years:

• Skills may evolve into "executable specifications": the natural-language part can be compiled into an intermediate representation for static verification and automated testing, moving SCS-style ideas forward to the authoring stage.
• Skill evolution will become routine: agents will propose revisions during use, approved by humans or evaluation gates, forming "continuous integration" for skills.
• Enterprise skill libraries will have owners, versions, audit records, and retirement processes, just like internal codebases.

9. Implications for Financial Risk Management and Enterprise Deployment

1. Maintain an internal skill whitelist with "one skill per job." Each business process (e.g., pre-loan document verification) should allow only one primary skill, avoiding rule loss from takeover.
2. Review the examples, and get them right. Examples in skills should cover all key rules and be confirmed correct by business experts.
3. Design skills with least privilege. Skills that touch customer data should not also have outbound network capability; before consequential actions (disbursement, credit-limit changes, sending reports externally), add information-flow and authorization checks.
4. Put skill changes through evaluation gates, but allow "exploration branches." Keep the main branch stable, allow experimental branches to score temporarily lower, and decide merges with a fixed evaluation set.
5. Log skill provenance. Every agent decision should be traceable to "which version of which skill was used," consistent with version-traceability requirements in model governance.

Hongxi AI's experience with rule engines and model governance is that rules can be flexible, but they must be traceable and reversible. We believe skill governance will go down the same path.

10. Conclusion

Agent Skills solve "how to hand procedural knowledge to an agent" with a minimalist format, but October's research shows clearly that a simple format needs rigorous governance: utility must be measured, conflicts detected, the supply chain audited, and evolution done methodically. Whoever first manages skills as "software assets" will be able to enjoy the efficiency of agents more safely.

Visit Hongxi AI at https://www.hxallai.com.

References

1. [1] Anthropic Engineering. Equipping agents for the real world with Agent Skills. Anthropic, 2025-10-16 (updated to an open standard on 2025-12-18). (Background reference.) https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
2. [2] Agent Skills. Agent Skills Overview (open specification). agentskills.io, accessed 2026-10-27. (Background reference.) https://agentskills.io
3. [3] Yu Cheng, Dehai Zhao, Zhongxin Liu, Qing Huang, et al. An Empirical Study of Agent Skills' Downstream Utility. arXiv, 2026-10-06. https://arxiv.org/abs/2610.08875
4. [4] Jiajie Wang, Yutong Zhao, Tianlin Li, Huashan Chen, et al. Agent Skill Evolution: How Revisions Affect Coding Agents. arXiv, 2026-10-04. https://arxiv.org/abs/2610.04832
5. [5] Chaoliang Yan, Zihao Xu, Yuekang Li, Shangzhi Xu, et al. One Skill Too Many: How Co-Installed Skills Conflict in Coding Agents. arXiv, 2026-10-08. https://arxiv.org/abs/2610.11647
6. [6] Parsa Razmara, Seyedarmin Azizi, Ardalan Aryashad. One Skill Takes Over: Clashing Agent Skills and a One-File Fix. arXiv, 2026-10-18. https://arxiv.org/abs/2610.25064
7. [7] Yujia Zheng, Tianhao Li, Shangzhi Xu, Yuekai Huang, et al. CoSA: The Conflict of Skills Attack in Real-World LLM Agent Ecosystems. arXiv, 2026-10-26. https://arxiv.org/abs/2610.35082
8. [8] Ratnesh Pandey, Japneet Singh, Harsh Akshit, Sonali Tyagi, et al. Beyond Maliciousness: Static and Runtime Attack-Surface Profiling of Agent Skills. arXiv, 2026-10-13. https://arxiv.org/abs/2610.19264
9. [9] Jie Liao, Simeng Qin, Wenqi Ren, Wei Zhou, et al. PyCache Trap: The Inspection-Execution Gap in Agent Skill Scanners. arXiv, 2026-10-07. https://arxiv.org/abs/2610.10612
10. [10] Shiwu Zhao, Baizhu Wang, Guoqiang Zheng, Tingyu Gao, et al. From Instructions to Exploits: Applying Program Analysis to Malicious Agent Skills Across Natural Language and Code. arXiv, 2026-10-24. https://arxiv.org/abs/2610.33489
11. [11] Jerrold Huang, Junwei Quan, Saiyue Lyu, Zihan Guo, et al. SkillScreen: High-Recall Screening of Malicious Agent Skills with Decision Models. arXiv, 2026-10-13. https://arxiv.org/abs/2610.17727
12. [12] Enze Ma, Chunyu Miao, Yankai Chen, Jie Yang, et al. SkillNEO: Non-Elitist Evolutionary Optimization of Agent Skills. arXiv, 2026-10-14. https://arxiv.org/abs/2610.20926
13. [13] Jia Tong, Senyou Deng, Min Peng, Jianfeng Pan. AtomSearch: Evidence-Grounded Tree Search for Agent Skill Optimization. arXiv, 2026-10-14. https://arxiv.org/abs/2610.19951
14. [14] Meng Shu, Wei He, Hang Zhou, Runke Liu, et al. Where Natural Language Ends in Agents: Executable Skill Composition with MetaSkill. arXiv, 2026-10-17. https://arxiv.org/abs/2610.24723

Research · Frontier AI Deep Dive · Great Unicorn Intelligence