Self-Extracting Skill Packing

• Self-Extracting Skill (SFS) Packing is a technique that transforms raw skill data into portable artifacts with explicit boundaries, metadata, and controlled runtime extraction.
• It integrates security and constructive workflows by concealing instructions from scanners and applying trace-to-skill pipelines to enhance deployability and efficiency.
• Empirical evaluations reveal that SFS methods boost task performance and maintain concise skill banks, though they also raise notable security and prompt injection concerns.

Self-Extracting Skill (SFS) Packing denotes a family of techniques for turning skills into bounded artifacts whose operational content can be extracted, packaged, selectively exposed, or re-materialized when needed. In the narrow and explicit sense introduced in "Cloak and Detonate," SFS Packing is the skill-level analogue of self-extracting packing in binary malware: malicious instructions or scripts are hidden outside install-time scanner visibility and restored only during execution. A broader constructive reading maps SFS Packing onto trace-to-skill and compiler-style workflows that extract reusable capability from human traces, agent trajectories, or raw skill text and then pack that capability into portable, inspectable, versioned skill artifacts (Ji et al., 2 Jul 2026, Zhou et al., 29 May 2026, Li et al., 25 May 2026).

1. Definition and conceptual scope

In the explicit security literature, SFS Packing is defined as a method that "hides malicious instructions or scripts outside the scanner's observable scope (e.g., ignored directories or encoded resource blobs) and restores them at execution time." The mechanism exploits a mismatch between the install-time projection of a skill bundle and its runtime-expanded closure: scanners inspect the visible bundle, whereas the agent may later decode and execute additional files under the same skill root (Ji et al., 2 Jul 2026).

In constructive skill systems, the same phrase is best treated as an interpretive umbrella rather than a standardized formal term. "COLLEAGUE.SKILL" is described as an "automated trace-to-skill distillation system" that generates a versioned, inspectable, correctable skill package from heterogeneous source materials; "CODESKILL" treats trajectory distillation, evolution, and compact skill-bank maintenance as a learned management problem; "SkillSmith" compiles raw skill packages into boundary-guided runtime interfaces rather than injecting entire skills into context at runtime (Zhou et al., 29 May 2026, Li et al., 25 May 2026, Xu et al., 12 May 2026).

A recurring conceptual boundary concerns the meaning of "self-extracting." Several systems automate extraction, but not in the strongest introspective sense of an agent autonomously serializing its own latent competence. COLLEAGUE.SKILL is explicitly trace-driven, externally initiated, and based on source materials from a target person or role rather than self-inspection; SkillSmith is compiler-driven and LLM-mediated; HDSO likewise separates a frozen executor from a frozen curator that constructs external skill packages from observed traces (Zhou et al., 29 May 2026, Xu et al., 12 May 2026, Shang et al., 21 Jun 2026). This suggests that, across current work, SFS Packing usually denotes automated or semi-automated extraction from observable evidence, followed by structured packaging.

2. Package representations and artifact contracts

A central theme of SFS Packing research is that a skill is not merely a prompt fragment. It is an artifact with an explicit boundary, metadata, and lifecycle. Different papers instantiate that artifact differently, but the underlying pattern is stable: represent reusable procedure, applicability, dependencies, and deployment surface as an object separate from hidden model state.

System	Formal representation	Packaging emphasis
SkillJect / skill malware	$S=(d,\mathcal{A})$	SKILL.md plus auxiliary artifacts
COLLEAGUE.SKILL	$S=(A,M,L)$	generated files, metadata/install info, lifecycle state
SkillComposer	$s=(n,d,b)$	name, description, body
SkillSmith	$B=(\tau,O,C_{io},R,V,\pi_a,\pi_s,F)$	runtime boundary contract

In "SkillJect," the basic skill package is $S=(d,\mathcal{A})$, where $d$ is the natural-language instruction file and $\mathcal{A}$ is the set of auxiliary artifacts. This formulation is important because it makes the package boundary explicit: the attack surface is not only SKILL.md, but also scripts, configuration data, and resources that the agent may execute (Jia et al., 15 Feb 2026).

COLLEAGUE.SKILL offers a more software-artifact-oriented contract, $S=(A,M,L)$, where $A$ is a set of generated files, $M$ is machine-readable metadata and installation information, and $S=(A,M,L)$0 is lifecycle state such as version, update time, correction count, and rollback history. Its writer emits SKILL.md, work.md, persona.md, work_skill.md, persona_skill.md, manifest.json, and meta.json, with a dual-track split between a capability track and a bounded behavior track (Zhou et al., 29 May 2026).

Other systems reduce the package to a smaller textual or interface-level object. SkillComposer defines each skill as $S=(A,M,L)$1, with name, description, and body, and then uses create, improve, and merge operations over that tuple (Zhang et al., 4 Jun 2026). SkillSmith compiles heterogeneous skill packages into a public boundary contract $S=(A,M,L)$2, where the exposed artifact is an ABI-like runtime interface rather than the original workflow text (Xu et al., 12 May 2026). SSL, in turn, reframes a skill as a layered representation with scheduling, structural, and logical components, explicitly separating invocation-facing data from scene-level execution structure and logic-level action and resource evidence (Liang et al., 27 Apr 2026).

Taken together, these formalisms mark a shift from opaque prompting toward explicit artifactization. A packed skill may be a directory bundle, a versioned file set, a structured textual tuple, or a compiled runtime contract, but in each case the operative unit is intended to be portable, inspectable, and separable from model-internal memory (Zhou et al., 29 May 2026, Xu et al., 12 May 2026, Liang et al., 27 Apr 2026).

3. Extraction, consolidation, and packing workflows

Constructive SFS-style systems differ mainly in what they extract from and how they consolidate it. COLLEAGUE.SKILL begins with heterogeneous personal or role traces and follows a full trace-to-portable-artifact pipeline: collect traces, normalize them into local knowledge directories, analyze for capability and behavior evidence, render structured markdown, generate derived entrypoints, emit metadata and lifecycle files, and then install, invoke, update, or distribute the result. Its source corpus can include chat logs, work documents, design documents, code-review comments, incident notes, email, screenshots, public research material, subtitles, interviews, and lightweight profile fields (Zhou et al., 29 May 2026).

CODESKILL treats packing as a learnable skill-bank management problem over coding-agent trajectories. It assumes a frozen downstream policy $S=(A,M,L)$3, represents a trajectory as $S=(A,M,L)$4, stores skills in a bank $S=(A,M,L)$5, and learns a management policy $S=(A,M,L)$6 that outputs an operation $S=(A,M,L)$7 to update the bank. The extracted skills are multi-granularity procedural markdown items with title, when_to_apply, and rules, and maintenance chooses among add, merge, and drop. Packing quality is therefore defined not by textual elegance, but by future downstream utility, bank compactness, and resistance to redundancy growth (Li et al., 25 May 2026).

SkillPyramid extends consolidation into a hierarchical repository. It organizes skills as $S=(A,M,L)$8, applies downward atomic extraction to factor shared low-level capability into atomic skills, and upward abstract induction to construct generalized schemas above concrete skills. Reuse is serialized explicitly as $S=(A,M,L)$9, recording the reused skill name, identifier, reuse condition, and provided capability. This turns packing into a refactoring operation: source skills are rewritten to delegate shared parts to canonical modules rather than re-encoding them independently (Xiong et al., 2 Jun 2026).

Other systems target different source media but preserve the same logic. Uni-Skill constructs a hierarchical SkillFolder from large-scale unstructured robotic videos, representing a self-augmenting repository in which semantically labeled demonstration slices, trajectories, and orientation patterns are retrieved to ground new manipulation skills (Xie et al., 3 Mar 2026). SSL normalizes existing SKILL.md-style documents into a typed representation for indexing and governance rather than execution (Liang et al., 27 Apr 2026). SkillSmith compiles already-authored skill packages into minimal executable interfaces, replacing repeated online interpretation with offline extraction of operational boundaries (Xu et al., 12 May 2026). A plausible implication is that SFS Packing is best viewed not as one algorithm but as a design space spanning trace distillation, semantic consolidation, and runtime interface compilation.

4. Runtime execution, portability, and selective disclosure

Packed skills matter operationally only if they can be invoked across hosts and surfaced at the right granularity. COLLEAGUE.SKILL makes this explicit: the package is composable across a full skill entrypoint (SKILL.md), a capability-only entrypoint (work_skill.md), and a behavior-only entrypoint (persona_skill.md). It aligns the format with the Agent Skills standard, names SKILL.md as the primary entrypoint, and lists supported hosts including Claude Code, OpenClaw, Codex, and Hermes (Zhou et al., 29 May 2026).

SkillSmith generalizes this runtime surface into a compiler-runtime architecture. At runtime, each compiled artifact is advertised through a compact run_{skill} handle and a boundary summary. The runtime then progressively discloses relevant boundary fields, chooses among blocked, guidance, and execute outcomes, and falls back losslessly to the original package when the compiled interface is insufficient. This execution model is explicitly partial by construction: the packed artifact contributes only the relevant operator or guidance path instead of injecting the whole source package into context (Xu et al., 12 May 2026).

Progressive disclosure also appears in HDSO. The executor sees at most a small number of compact skill cards per step, may request the full content of one relevant skill, and otherwise preserves the executor-only path. This yields a tight runtime analogue of packing: repository objects are stored richly, surfaced sparsely, and unpacked only on demand (Shang et al., 21 Jun 2026).

Portability is clearest in tool-coupled workflow systems. ColPackAgent pairs a portable Markdown/YAML skill with an MCP tool server and a domain package, and the paper states that the skill can be installed on any compatible agent system while the MCP server is invoked the same way across clients. Tested clients include Claude Code, Gemini CLI, OpenAI Codex, and OpenCode (Ding et al., 15 May 2026). This suggests that SFS Packing is not only about compact representation, but also about host-independent transport of procedural knowledge over stable execution substrates.

5. Evaluation and empirical evidence

Empirical evidence for SFS-style packing spans retrieval quality, downstream task performance, deployment efficiency, and repository maintenance. SSL shows that making a skill machine-usable can improve non-execution tasks directly: in Skill Discovery, MRR improves from 0.573 to 0.707; in Risk Assessment, macro F1 improves from 0.744 to 0.787 (Liang et al., 27 Apr 2026).

In coding agents, CODESKILL reports that the full lifecycle—extraction, evolution, and maintenance—improves average pass rate by 9.69 over the no-skill baseline and by 4.01 over the strongest prompt-based or memory baseline, while maintaining the skill bank at a stable size. The same study reports that maintenance reduces the bank from 1252 skills to 676, showing that packing is not only skill creation but also semantic consolidation under continual growth (Li et al., 25 May 2026).

SkillSmith supplies the clearest efficiency case for compiler-style packing. On SkillsBench, compiled artifacts reduce solve-stage token usage by 57.44%, thinking iterations by 42.99%, solve time by 50.57%, and token-proportional monetary cost by 57.44% relative to raw skills, while remaining reusable across different runtime models (Xu et al., 12 May 2026).

SIRI provides a parametric rather than external-packaging result. By self-mining compact skills from successful skill-free rollouts, validating them, and internalizing only beneficial action tokens into the plain policy, it improves GiGPO from 0.908 to 0.930 on ALFWorld and from 0.728 to 0.813 on WebShop. The final policy runs with the original prompt only, so the skill scaffold is discarded after training (He et al., 1 Jun 2026).

HDSO demonstrates that validated external repositories can improve frozen executors without training. On ALFWorld, it improves executor-only baselines by +6.9 Avg. SR points for Qwen3-8B and +4.0 points for Qwen3.6-27B, and under 20% randomly flipped success/failure feedback during discovery and validation it preserves a +7.1-point gain for Qwen3-8B (Shang et al., 21 Jun 2026).

Evidence is not uniformly benchmark-centric. COLLEAGUE.SKILL reports approximately 18.5k GitHub stars, a gallery listing 215 skills from 165 contributors, and more than 100k cumulative stars across listed skill cards, while explicitly cautioning that these are deployment and distribution signals rather than evidence of task impact or behavioral fidelity (Zhou et al., 29 May 2026).

6. Limitations, safety, and controversies

A persistent misconception is that SFS Packing necessarily means autonomous self-introspection. Current constructive systems are usually more limited. COLLEAGUE.SKILL is automated but trace-driven and externally initiated rather than self-compiling from latent model state; SkillSmith is compiler-mediated and boundary-first rather than self-descriptive; SIRI self-mines from successful behavior but does not maintain explicit packed skill modules at inference time because it internalizes them into policy parameters (Zhou et al., 29 May 2026, Xu et al., 12 May 2026, He et al., 1 Jun 2026).

Another limitation is formal incompleteness. Several systems remain systems-oriented rather than mathematically complete: COLLEAGUE.SKILL gives no training objective, no extraction scoring formula, and no sentence-level evidence binding for every rule; SkillSmith provides no correctness guarantee and notes that compiled artifacts depend on tool versions, file formats, and execution policies; SkillPyramid explicitly models only two reuse axes and leaves richer temporal or causal relations unrepresented (Zhou et al., 29 May 2026, Xu et al., 12 May 2026, Xiong et al., 2 Jun 2026).

The major controversy is security. SkillJect shows that the same package abstraction enabling reusable skills also enables stealthy skill-based prompt injection. Its poisoned skills split into a benign-looking documentation channel and a hidden operational channel in helper scripts, achieving 95.1% average attack success rate versus 10.9% for naïve direct injection (Jia et al., 15 Feb 2026). "Cloak and Detonate" sharpens this into the explicit notion of SFS Packing as malware-style staged materialization: across eight scanners and 1,613 in-the-wild malicious skills, SFS Packing bypasses every scanner at over 90%, and SkillDetonate is then introduced as a behavior-centric runtime auditor that detects 97% of attacks at a 2% false-positive rate; its ablation shows that removing closure lift collapses packed-skill detection from 95.3% to 30.0% (Ji et al., 2 Jul 2026).

This dual use is central. Constructive systems argue for portable, inspectable, correctable, versioned skill artifacts rather than opaque prompts or hidden memory (Zhou et al., 29 May 2026). Adversarial systems exploit the same artifact boundary to hide executable payloads, defer materialization to runtime, and evade appearance-based auditing (Ji et al., 2 Jul 2026, Jia et al., 15 Feb 2026). A plausible implication is that any mature theory of SFS Packing must treat packaging semantics, lifecycle governance, and runtime auditability as inseparable from skill utility itself.