Code Skills

Stable Executable Capabilities

Some capabilities are not well served by repeated prompt-level improvisation. They benefit from an execution surface that remains inspectable, testable, and stable across runs. In such cases, the main problem is no longer how to obtain one plausible answer from a model, but how to preserve a bounded behavior that can be executed again without reinterpretation of the same local logic.

Code Skills address this need by placing the operational center in a module under src/. The skill descriptor remains important because it defines the public contract of the capability, but the domain work is performed by executable code rather than by a free-form LLM session. This gives the library a family of skills whose runtime behavior is more explicit and more predictable than that of the more fluid skill types.

In the broader architecture, this makes Code Skills a useful intermediate form between natural-language specification and stable execution. They still belong to the skill system, they are still discovered and routed by the shared agent runtime, and they can still be orchestrated by other skills. At the same time, their local behavior is delegated to a module that must satisfy a concrete entrypoint contract. In that sense, they are a more specialized and more bounded local interpretive regime.

How Code Skills Operate in Practice

A Code Skill is discovered through cskill.md. When the skill is registered, RecursiveSkilledAgent automatically requests a generation pass through the internal mirror-code-generator skill. If the skill directory contains a specs/ folder, that generation pass can produce or refresh files under src/. If no such specifications exist, the runtime can still execute a maintained module directly from src/, provided that the required entrypoint is present. The authoring patterns for these two cases are described in Authoring.

The execution contract is stricter than the current page previously suggested. The subsystem looks for src/index.mjs first and then for src/index.js. It imports the located module dynamically and requires it to export an action(args) function. The user prompt is passed through as args.promptText, together with the shared runtime references such as llmAgent, recursiveAgent, context, sessionMemory, user, and attachments. The subsystem therefore loads and executes code from disk; it does not execute the descriptor itself. The exact loading and argument rules are documented in Runtime.