Subsystems and Skills

Operational Taxonomy of Skill Families

Not all skills in the library behave in the same way. Some are primarily descriptor-driven interfaces to an LLM-guided workflow. Some plan tool use. Some load generated code from disk. Some model table-oriented data operations. If all of these were treated as though they shared one uniform runtime contract, either the more constrained skills would lose their determinism or the more flexible skills would be forced into an artificial structure that does not match their purpose.

For this reason, the library does not treat a skill as a single generic abstraction with one universal execution path. It treats a skill as a filesystem-discovered unit whose descriptor filename determines its type, and whose type determines which subsystem will parse, prepare, and execute it. The category is therefore operational rather than merely descriptive.

RecursiveSkilledAgent delegates three distinct responsibilities to separate internal services. The discovery service locates skills directories and scans them for recognized descriptor filenames. The registry stores the discovered skill records together with aliases and canonical names. The subsystem factory then resolves each skill type to the subsystem that knows how that skill family should be handled. In the current implementation, the filename-to-type mapping is explicit: SKILL.md maps to anthropic, dcgskill.md to dynamic-code-generation, cskill.md to cskill, mskill.md to mcp, oskill.md to orchestrator, and tskill.md to dbtable.

Once a skill has been discovered, the agent asks the matching subsystem to parse the descriptor if that subsystem exposes a descriptor parser. The skill is then registered, and the same subsystem may prepare it for execution. Preparation is not uniform across the system. A DBTable skill may parse and generate runtime helpers, an MCP skill may normalize its allowlisted tools and optional script, an Anthropic skill may collect scripts and resources, and a code skill may rely on generated files under src/. This is precisely why the subsystem boundary exists.

Execution follows the same principle. When a request names a specific skill, the agent resolves the corresponding skill record and delegates execution to the subsystem associated with that record’s type. When no explicit skill is provided, the executor first tries to select a registered orchestrator. If no orchestrator is available, it falls back to ad hoc routing over the available non-orchestrator skills. The overall architecture therefore separates discovery, registration, and routing from subsystem-specific execution logic.

Current Skill Families in Practice

Each current skill family should be understood through the execution contract implemented by its subsystem rather than through a generic slogan. Orchestration Skills coordinate other skills through structured sessions. DBTable Skills model table-oriented workflows and derive runtime behavior from tskill.md. Code Skills execute generated or maintained modules from src/index.mjs or src/index.js, and in that case an exported action() function is required by the code-loading subsystem. Dynamic Code Generation Skills use a different contract, centered on descriptor-guided text-or-code decisions and temporary snippet execution rather than the cskill entrypoint rules. MCP Skills structure MCP tool access through allowlists, scripts, and plan execution. Anthropic Skills use their descriptor content together with discovered scripts and resources to build a loop-session runtime surface.

This means that a skill is not simply “a smarter tool” in one uniform sense. In this library, a skill is a registered unit whose runtime semantics depend on its descriptor type. Some skills expose generated code, some expose orchestration guidance, some expose structured table definitions, and some expose tool-planning constraints. The commonality is not identical internal behavior. The commonality is that all of them can be discovered, registered, selected, and executed through the same top-level agent while preserving the execution discipline appropriate to their own family.

The filesystem structure reflects this arrangement. Skill discovery begins from directories named skills, and each concrete skill is recognized by the presence of one of the supported descriptor filenames. A minimal illustrative layout is shown below.

This example should be read as a type-oriented sketch rather than as a claim that every family has the same companion files. The actual runtime details belong to the dedicated pages for each subsystem. The function of the present page is to establish the governing principle: skill categories are first-class runtime categories, and subsystems are the mechanism that makes those categories executable without collapsing them into one misleading abstraction.