Runtime Behavior of Code Skills
This chapter explains how Code Skills are prepared and executed after discovery and clarifies which files and exports the subsystem actually requires at runtime.
Registration and Generation
When RecursiveSkilledAgent registers a skill of type cskill, it immediately schedules a preparation step through the internal mirror-code-generator skill. That generation request is issued automatically with the skill directory as input. If the directory contains usable files under specs/, the generator can produce or refresh matching files under src/. If the directory does not contain specifications, the generation step may complete without producing code.
This means that the Code Skills runtime should not be described as though generation and execution were the same phase. Generation is an earlier preparation step initiated by the top-level agent. Execution happens later inside the Code Skills subsystem, which simply loads the module that exists on disk at that point.
Module Loading Contract
At execution time, the subsystem searches for src/index.mjs first and then for src/index.js. If neither file exists, execution fails. If one of them exists, the subsystem imports it dynamically and checks for an exported action function. If that function is missing, execution fails again. The runtime contract is therefore narrow and inspectable: the module must exist, and it must export action(args).
src/ and an exported action(args) function.The subsystem does not execute cskill.md. It executes the imported module from src/. The descriptor remains part of the public contract, but the executable artifact is the module loaded from disk.
Execution Arguments
The current runtime path passes the incoming user prompt directly into the module as args.promptText. It also injects the shared runtime references llmAgent and recursiveAgent, together with context, sessionMemory, user, and attachments. The subsystem therefore exposes both the raw prompt and the surrounding agent context to the module.
This detail is important because the current subsystem does not perform structured argument extraction before loading the module. The helper for LLM-based extraction exists in the file, but the active execution path passes the prompt through unchanged. A Code Skill should therefore be written with the expectation that its action(args) function receives the raw prompt text unless a higher-level caller has already provided some richer context.
In practical terms, the generated or maintained module is responsible for turning that prompt and context into the local behavior of the skill. That is why the descriptor and any source specifications should describe the intended interface clearly, but the executable semantics are ultimately determined by the module under src/.