Skill Folders, Modular Agent Capabilities, And UAIX

A clear industry pattern has emerged: **agentic systems are increasingly built by separating the agent runtime from the capability package**. In practice, the “package” may be a filesystem skill folder with a `SKILL.m...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-c46148d7/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Skill Folders, Modular Agent Capabilities, and UAIX.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-03T16:23:22.0473017Z
Content hash	sha256:c46148d77cd57c73a25d088cfd5af1a1ad8d56cdd19f959a2280f5fe8b8b721b
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-skill-f-c46148d77cd5.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-skill-f-c46148d77cd5.txt

Current File Content

Structure Preview

• Skill Folders, Modular Agent Capabilities, and UAIX
• Executive summary
• Definitions and taxonomy
• Technical architectures and orchestration
• Interoperability, governance, and safety
• Commercial implementations
• Implications for UAIX and recommended spec updates
• Source guide and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 38576
• Preview characters: 11283

# Skill Folders, Modular Agent Capabilities, and UAIX

## Executive summary

A clear industry pattern has emerged: **agentic systems are increasingly built by separating the agent runtime from the capability package**. In practice, the “package” may be a filesystem skill folder with a `SKILL.md`, a plugin manifest, an A2A Agent Card, an OpenAPI-described action group, an MCP server, or a declarative agent manifest. The runtime plans, delegates, invokes tools, and manages state; the package describes **what a capability is, when to use it, what resources it needs, and under what policies it may run**. This division is explicit in UAIX as well: UAI-1 positions itself as a **portable public exchange, trust, and evidence layer**, not a replacement for MCP, A2A, or runtime orchestration. UAIX’s current boundaries are therefore directionally correct. citeturn4view0turn7view0turn25view4turn19view0

The strongest cross-vendor convergence today is around three ideas. First, **progressive disclosure**: only lightweight metadata is advertised initially, while full instructions and resources are loaded on demand. The open Agent Skills specification makes this explicit, and Microsoft’s Agent Framework operationalizes it with advertised metadata plus `load_skill` and `read_skill_resource`-style retrieval. Anthropic, GitHub, Cursor, Microsoft Cowork, and SharePoint all use or adapt this pattern. Second, **capability discovery** is moving toward typed manifests: A2A Agent Cards expose identity, skills, endpoint, and authentication; UAIX has `uai.capability.statement.v1`; Microsoft declarative agents use a machine-readable manifest; AWS Bedrock action groups use OpenAPI; Cursor plugins use `.cursor-plugin/plugin.json`; OpenAI apps and remote MCP integrations expose tool contracts through MCP. Third, **security is being pushed closer to the capability package** through allowlists, approval gates, OAuth, org-scoped catalogs, and audited storage. citeturn16view1turn16view3turn16view6turn26search7turn19view1turn8view1turn27view0turn35search16turn34view2turn23view8

For agentic agents specifically, modular capability packaging is not a luxury; it is a scaling mechanism. ReAct, Toolformer, and MRKL jointly support the idea that robust agents improve when reasoning, tool use, and specialized modules are separated but composable. Voyager adds a particularly relevant result: a usable **skill library** becomes a memory and generalization mechanism, not merely a convenience layer. In modern production platforms, this shows up as subagents with isolated context, runtime delegation, attached MCP servers, action groups, and skill libraries that can be invoked automatically or manually. citeturn38search0turn38search1turn38search2turn38search3turn30view0turn34view0turn35search7

The largest standards gap is that UAIX currently has strong artifacts for **messages, trust, conformance, AGENTS.md linking, and file handoff**, but it does **not yet define a normative capability-package layer** for skills, plugins, action modules, or adapters. That omission matters because the industry now relies heavily on package-level concerns such as package identity, manifest versioning, permitted tools, sandbox requirements, review state, org/distribution scope, provenance attestations, and mapping between local runtime packaging and portable public evidence. UAIX’s own roadmap already treats adapters, exports, trace-to-handoff fixtures, and managed package tooling as future-bound rather than current support, which is honest and appropriate. But that also means UAIX is well-positioned to add a packaging standard without breaking its current boundary. citeturn6view0turn6view1turn6view2turn5view1turn10view0

The most consequential recommendation is therefore this: **UAIX should add a first-class, additive “capability package” specification**—ideally a sidecar manifest that can describe skill folders, plugins, action groups, connectors, adapters, and subagent profiles without taking over their native runtimes. The sidecar should map native artifacts into UAIX’s existing `uai.capability.statement.v1`, `uai.intent.*`, `uai.task.status.v1`, and trust/conformance surfaces. Done correctly, this would let UAIX remain what it already claims to be—a portable evidence and interoperability layer—while becoming relevant to the way real agent ecosystems now package and distribute capabilities. citeturn8view1turn11view1turn11view2turn7view0

## Definitions and taxonomy

The term **skill folder** is best treated as a **filesystem-native capability package**: a directory that contains a required skill document and optional supporting resources. In the open Agent Skills specification, a skill is a directory containing `SKILL.md`, plus optional `scripts/`, `references/`, and `assets/`; the `SKILL.md` uses YAML frontmatter for metadata such as `name`, `description`, and optional fields like `license`, `compatibility`, `metadata`, and experimental `allowed-tools`. Anthropic, GitHub, Cursor, and Microsoft all now describe skills in nearly this exact way. citeturn16view1turn16view3turn25view0turn15view2turn30view1turn32view0turn15view1

A **skill store** or **directory** is the discovery and distribution surface for these packages. Anthropic now exposes a unified directory for skills, connectors, and plugins, including organization-shared skills on Team and Enterprise plans. Cursor has a marketplace and plugin submission flow. GitHub supports discovery and installation through `gh skill` and repository collections. SharePoint stores skills in a managed Agent Assets library, which effectively serves as a governed enterprise-local skill repository. citeturn25view2turn33search6turn15view2turn27view3

A **plugin** is broader than a skill folder. In Cursor, a plugin is a directory with a `.cursor-plugin/plugin.json` manifest and may bundle rules, skills, agents, commands, hooks, and MCP servers. In OpenAI’s current ChatGPT Apps model, the app submission flow distributes approved apps in the ChatGPT app store and creates a plugin for Codex distribution, but the capability contract is increasingly centered on MCP tool surfaces rather than the older ChatGPT plugin schema. In effect, modern plugins are not just UI add-ons; they are **compound capability containers**. citeturn34view2turn33search6turn22view4turn23view0

A **capability module** is the abstract umbrella term across ecosystems. AWS Bedrock’s action groups, Salesforce Agentforce actions, IBM watsonx Orchestrate skills, Microsoft declarative-agent actions/knowledge/instructions, A2A `AgentSkill` objects, and UAIX capability statements all fit within this broader category. They differ in packaging and runtime assumptions, but they all represent a **bounded, describable unit of agent competence**. citeturn35search16turn36search0turn37search11turn27view0turn19view1turn8view2

An **adapter** is a translation layer between native packaging/runtime formats and a portable interoperability surface. UAIX’s Standards Fit and roadmap are already explicit that MCP and A2A can remain in charge of runtime behavior while UAI-1 records the portable exchange and evidence around them; formal bridge profiles remain planned, not yet generalized public support. This is precisely how UAIX should think about skill folders and adjacent packaging: not as replacements for native runtimes, but as things that need a **portable evidence mapping**. citeturn7view0turn6view0turn6view2

The most useful working taxonomy is the following:

| Term | Best definition | Typical format | Primary role | Closest UAIX analog |
|---|---|---|---|---|
| Skill folder | Filesystem package of instructions and resources | `SKILL.md` + optional resources | Specialization and progressive disclosure | AGENTS.md-linked `.uai` sidecar today; no normative package spec yet |
| Skill store / directory | Catalog that distributes skills | Web/app catalog or managed library | Discovery, enable/disable, org sharing | Registry-like discovery, but not yet native UAIX packaging |
| Plugin | Compound installable package | Manifest + components | Distribution and composition | Could map to a future UAIX package manifest |
| Capability module | Generic bounded competence unit | Varies | Reusable task capability | `uai.capability.statement.v1` |
| Adapter | Mapping/export bridge between native runtime and portable record | Code or sidecar manifest | Interop and evidence export | UAIX bridge evidence / future adapters |
| Agent card | Typed descriptor for an agent and its skills | JSON | Discovery, endpoint, auth, skills | `uai.capability.statement.v1` |
| Action group / action | API-centered executable module | OpenAPI or platform DSL | Tool invocation | `uai.intent.*` + capability statement |

The cross-cutting insight is that **the market has converged on bounded capability objects, but not on one universal package manifest**. UAIX should therefore standardize the mapping layer, not insist on replacing native packaging. citeturn19view1turn10view0turn27view0turn35search16turn36search0

## Technical architectures and orchestration

The dominant technical architecture is now **advertise small, load late, execute under policy**. The Agent Skills spec explicitly says only `name` and `description` are loaded at startup, while full instructions and resources are loaded on demand; Microsoft’s Agent Framework mirrors this with advertised skill metadata and explicit skill/resource loading; Anthropic describes skills as dynamically loaded; Cursor says agents automatically discover skills at startup and decide relevance during execution. This pattern is not cosmetic. It is a context-budget, latency, and governance strategy. citeturn16view1turn16view6turn26search7turn25view0turn32view0

At runtime, capability modules plug into agents through several distinct, but increasingly composable, surfaces. MCP standardizes host–client–server tool and resource sessions using JSON-RPC 2.0 between hosts, clients, and servers. A2A standardizes peer-agent discovery and coordination through Agent Cards and task flows. OpenAPI continues to dominate API-shaped actions for systems like AWS Bedrock and Salesforce. UAIX sits above these as an evidence and message layer, with typed profiles, transport bindings, trust channels, and conformance levels. That stratification is healthy: one protocol for local tool sessions, another for agent-to-agent coordination, another for public record/evidence. citeturn25view4turn19view1turn35search16turn7view0turn11view2

Versioning is currently fragmented. Agent Skills leaves versioning to optional metadata. Cursor plugins use semantic versions in plugin manifests. Microsoft declarative agents version their schema and already recommend newer schema versions over older ones. A2A Agent Cards include a `version`. UAIX versions both the overall release and individual profiles, and it also version-controls field ordering for compact formats. This fragmentation is tolerable inside products, but it becomes a portability problem when one wants to prove what was actually executed, approved, or deployed. citeturn16view4turn34view2turn27view0turn19view2turn10view1

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Skill Folders, Modular Agent Capabilities, and UAIX; Executive summary; Definitions and taxonomy; Technical architectures and orchestration; Interoperability, governance, and safety; Commercial implementations; Implications for UAIX and recommended spec updates; Source guide and limitations. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-950 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Skill Folders, Modular Agent Capabilities, And UAIX",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-c46148d7/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Skill Folders, Modular Agent Capabilities, and UAIX.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:c46148d77cd57c73a25d088cfd5af1a1ad8d56cdd19f959a2280f5fe8b8b721b",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-03T16:23:22.0473017Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-950",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}