Skill Folders, Modular Agent Capabilities, And LLM Wikis For LLMWikis

Across the current LlmWikis.org handbook, the site already defines a strong operating model for a governed “LLM Wiki”: predictable folder structure, explicit frontmatter, trust labels, sensitivity classes, agent instr...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-c90afd3f/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Content/Skill Folders, Modular Agent Capabilities, and LLM Wikis for llmwikis.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-03T17:46:08.6688788Z
Content hash	sha256:c90afd3fcf712c4ee4b78efcbb8050f900c08d393d368962b0fb07db16d55479
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-con-c90afd3fcf71.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-03-con-c90afd3fcf71.txt

Current File Content

Structure Preview

• Skill Folders, Modular Agent Capabilities, and LLM Wikis for llmwikis.org
• Executive summary
• Concepts and distinctions
• Architectures and design patterns
• Reference implementation patterns
• Release readiness
• Inputs
• Steps
• Additional resources
• Purpose
• Inputs and outputs
• Safety boundary
• Dependencies
• Validation
• Change log
• Lifecycle engineering and security
• Wiki discoverability and governance for llmwikis.org
• Summary
• Use when
• Do not use when
• Runtime artifact
• Permissions
• Outputs

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: 37477
• Preview characters: 11698

Local absolute paths are redacted in this public view. The source hash and source-side raw layer are based on the unredacted source file.

# Skill Folders, Modular Agent Capabilities, and LLM Wikis for llmwikis.org

## Executive summary

Across the current LlmWikis.org handbook, the site already defines a strong operating model for a governed “LLM Wiki”: predictable folder structure, explicit frontmatter, trust labels, sensitivity classes, agent instructions, a three-layer architecture that separates raw sources from wiki synthesis and schema, deterministic navigation via `index.md` and `log.md`, and a two-step ingest pipeline that stages analysis before writing durable pages. In the pages reviewed, however, there is not yet a first-class handbook treatment of **skill folders** or a broader taxonomy for **modular agent capabilities**. The closest existing material is the agent guidance, starter template, structure standard, architecture, operations, and governance pages. That gap is important because the agent ecosystem is rapidly converging on filesystem-based skill packages and modular orchestration primitives as the practical way to extend agents without bloating always-on context. citeturn3view1turn3view2turn3view3turn4view0turn4view1turn4view4turn16view0

The clearest distinction is this: **LLM wikis** are governed, durable, source-linked knowledge systems; **skill folders** are portable, task-scoped capability bundles that package instructions, metadata, and optional scripts or references; **modular agent capabilities** are the broader execution layer that includes tools, plugins, subagents, workflows, handoffs, and agents-as-tools. In practice, a robust agentic system uses all three together: the wiki supplies durable truth, skills supply repeatable procedures, and capability modules supply runtime execution boundaries and delegation. That division is strongly supported by LlmWikis.org’s own separation of governance and knowledge pages, by OpenAI Codex’s split between `AGENTS.md`, skills, plugins, MCP, and subagents, by Claude Code’s split between persistent context, skills, subagents, hooks, MCP, and plugins, and by GitHub Copilot’s distinction between custom instructions and skills. citeturn14view0turn14view1turn25view3turn22search12turn28view3

For llmwikis.org specifically, the most important strategic move is **not** to collapse these layers into one format. Instead, the site should document and ship them as cooperating artifacts with clean boundaries: a wiki starter bundle for durable knowledge, a skill-folder starter bundle for reusable procedures, and a capability registry pattern for orchestrators and platforms. That design aligns with the Agent Skills open specification, with Codex and Claude plugin distribution models, with Microsoft and Google workflow frameworks, and with LangGraph’s emphasis on durable stateful orchestration plus human checkpoints. citeturn13view1turn25view2turn9view13turn21search23turn20search5turn30search9

The recommended next step is therefore a **three-layer handbook expansion** for llmwikis.org: add a “Skill Folders” page, a “Capability Modules and Orchestration” page, and a “Capability Registry / Catalog UX” page; publish portable templates and JSON-schema / linter rules; and document governance rules that keep executable skills outside the durable wiki tree while documenting them richly inside the wiki. That would extend the current handbook naturally instead of changing its core philosophy. citeturn3view1turn4view4turn16view1turn16view2

## Concepts and distinctions

The current LlmWikis.org handbook defines an LLM Wiki as a **governed knowledge system**, not a loose corpus. Its pages emphasize ownership, status, review cycles, sensitivity, agent permissions, source traces, contradictions, and explicit reading order; they also draw a sharp boundary between an LLM Wiki, simple RAG, and portable “AI Memory” bundles. In that model, the wiki’s job is long-lived, reviewable truth with provenance, while retrieval and short-term memory are downstream consumers of that governed corpus. citeturn3view2turn3view3turn14view0turn14view1turn15view0turn15view1turn17view0

By contrast, the **Agent Skills** specification defines a skill as a directory containing a required `SKILL.md` file plus optional `scripts/`, `references/`, and `assets/` directories. The standard requires `name` and `description`, constrains names to lowercase hyphenated identifiers, and relies on **progressive disclosure**: metadata is loaded first, the `SKILL.md` body is loaded when a skill is activated, and supporting files are loaded only as needed. OpenAI’s hosted Skills API, Codex skills, Claude Code skills, and GitHub Copilot skills all reflect that same basic model, though each adds platform-specific extensions. citeturn13view1turn11view2turn25view0turn26view0turn28view0turn28view1

“**Modular agent capabilities**” is the broadest term of the three. It includes any separable unit of capability that can be composed, invoked, or delegated: tools, plugins, function groups, skills, subagents, workflow agents, graph nodes, handoffs, agents-as-tools, and workflows-as-agents. OpenAI makes a useful distinction between **handoffs**, where a specialist takes ownership of a branch of the conversation, and **agents as tools**, where a manager stays in control and invokes specialists as bounded helpers. Google ADK distinguishes LLM agents from deterministic workflow agents such as `SequentialAgent`, `ParallelAgent`, and `LoopAgent`. Microsoft Agent Framework makes a similar distinction between agents and workflows and explicitly supports workflows as agents. LangGraph frames the same design space as state graphs, subgraphs, persistence, interrupts, and human-in-the-loop controls. citeturn9view9turn20search5turn20search7turn20search8turn21search0turn21search9turn21search23turn30search9turn30search8

A practical mental model for llmwikis.org is:

| Artifact | Primary job | Typical scope | When to use it |
|---|---|---|---|
| **LLM Wiki** | Preserve durable, sourced, reviewable truth | Organization, project, architecture, policy, operations | When the question is “what is true, current, authoritative, or sensitive?” citeturn3view1turn3view2turn15view1 |
| **Skill folder** | Package a repeatable procedure or expertise | One workflow or narrow domain task | When the question is “how should the agent perform this recurring task?” citeturn13view1turn25view3turn26view2turn28view3 |
| **Capability module** | Execute or orchestrate work safely and compositionally | Tool, subagent, workflow, plugin, handoff graph | When the question is “which executor should do this, under what boundary?” citeturn9view9turn20search5turn21search23turn30search9 |

A second, equally important distinction is between **always-on instructions** and **on-demand instructions**. OpenAI Codex positions `AGENTS.md` as persistent project guidance and skills as reusable, selectively loaded workflows. GitHub recommends custom instructions for simple rules relevant to almost every task, and skills for richer task-specific guidance that should only load when relevant. Claude Code similarly separates `CLAUDE.md` from skills, subagents, hooks, MCP, and plugins. For llmwikis.org, that implies a clean editorial rule: persistent repository norms belong in `AGENTS.md` / `CLAUDE.md`; reusable procedures belong in skill folders; durable truth belongs in the wiki; runtime orchestration belongs in subagents, workflows, or plugins. citeturn25view3turn28view3turn22search12

The academic literature supports this layered picture. MRKL argued early for modular language-plus-tool architectures that combine neural models with external reasoning or knowledge modules. Toolformer showed that models can learn to decide **which tool to call, when, and with what arguments**. ReAct established the now-standard reasoning–action loop for tool-using agents. HuggingGPT demonstrated task planning and model selection across external expert models. Voyager is especially relevant to skill folders because it used an ever-growing skill library of executable code as a persistent capability store. AutoGen then generalized the practical engineering pattern of multiple customizable, conversable agents with tools and human participation. citeturn18search0turn18search1turn18search2turn19search1turn18search3turn19search0

```mermaid
flowchart LR
    U[User task] --> O[Orchestrator]
    O -->|needs truth| W[LLM Wiki]
    O -->|needs procedure| S[Skill folder]
    O -->|needs execution| C[Capability module]
    W --> R[Raw sources and provenance]
    S --> A[Scripts references assets]
    C --> T[Tools subagents workflows plugins]
    O --> H[Human approval gate]
```

The diagram above reflects the strongest synthesis from the source base: **wiki for truth, skill for procedure, capability module for execution, human gate for risk**. That is also the cleanest architectural stance for llmwikis.org. citeturn4view0turn15view2turn24view1turn27view5turn30search3

## Architectures and design patterns

The most robust architecture is a **layered system** in which storage, synthesis, and execution are deliberately separated. LlmWikis.org already states this principle explicitly: raw sources remain immutable, compiled pages live in the wiki layer, and schema files tell agents how to change things. The handbook also recommends explicit navigation artifacts, trust labels, and staged automation. Those ideas map naturally onto skill folders and capability modules: let the wiki describe durable truth, let skills describe reusable procedures, and let the orchestrator decide which capability to invoke under which runtime constraints. citeturn4view0turn14view2turn15view2

A useful pattern taxonomy is:

**Persistent guidance pattern.** Put enduring human/team norms in `AGENTS.md` or `CLAUDE.md`. Codex treats these as layered project guidance, with closer files taking precedence. They are a poor fit for large, conditional, or highly procedural content because they are always in scope. citeturn9view7turn25view3

**Skill-on-demand pattern.** Put narrow procedures in skill folders using the open Agent Skills format. This minimizes context overhead because skills are discovered from metadata first and only fully loaded when chosen. OpenAI, Claude, GitHub Copilot, and the Agent Skills spec all align on this progressive-disclosure model. citeturn13view1turn11view2turn24view0turn22search9turn28view1

**Plugin distribution pattern.** Use direct skill folders for local authoring and repository-scoped workflows; use plugins when distributing reusable skills across teams or bundling them with app integrations, MCP servers, or UI metadata. OpenAI Codex and Claude Code both make this distinction explicitly. citeturn25view1turn25view2turn9view13

**Manager–specialist pattern.** Use a manager agent to stay responsible for the final answer while calling specialists as tools when bounded help is enough; use handoffs or subagents when a specialist needs isolated context or ownership of a branch. OpenAI’s orchestration guide and Codex/Claude subagent docs are consistent here. citeturn9view9turn24view3turn22search2turn26view3

**Deterministic workflow pattern.** Use workflow agents or graphs when the control flow itself should not depend on model improvisation. Google ADK’s `SequentialAgent`, `ParallelAgent`, and `LoopAgent`, Microsoft Agent Framework workflows, and LangGraph state graphs all exist for exactly this reason. Deterministic flow is especially valuable when compliance, repeatability, or recovery matter. citeturn20search1turn20search2turn20search5turn21search0turn21search10turn30search1turn30search6

Why This File Exists

This is a memory-system evidence file from llmwikis.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 LLM Wikis for llmwikis.org; Executive summary; Concepts and distinctions; Architectures and design patterns; Reference implementation patterns; Release readiness; Inputs; Steps. 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-975 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Skill Folders, Modular Agent Capabilities, And LLM Wikis For LLMWikis",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-c90afd3f/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-03/Content/Skill Folders, Modular Agent Capabilities, and LLM Wikis for llmwikis.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:c90afd3fcf712c4ee4b78efcbb8050f900c08d393d368962b0fb07db16d55479",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-03T17:46:08.6688788Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-975",
    "duplicate_role":  "primary",
    "related_files":  [

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