Skill Invocation and Routing
Invocation is an authority decision followed by a relevance decision. A good description helps the model choose; a good policy decides whether that choice is allowed. Distinguish explicit user invocation, implicit model invocation, application invocation, and skill-to-skill invocation. Model human visibility and model eligibility as independent policy dimensions. Write routing descriptions with positive triggers and near-miss boundaries. Separate eligibility, selection, activation, argument binding, and execution in traces and tests. Adapt runtime-specific invocation fields without presenting them as portable frontmatter. You install a database-migration skill. The user can run it by name, but the model also sees its description and selects it when someone asks a general database question. The skill then proposes a schema change for a task that only needed an explanation. You add user-invocable: false, expecting to block people from running it manually. In another runtime, that field is ignored. You add disable-model-invocation: true, expecting the skill to disappear entirely. In the runtime that understands it, the user can still invoke it explicitly. Nothing is wrong with the field names. The model is wrong. "User can see it," "model can select it," "application can preload it," and "tools inside it can execute" are separate facts. A single boolean called invocable cannot express them. Routing has a second failure mode. If descriptions are vague, several skills become plausible. If…
Skill Invocation and Routing: Invocation is an authority decision followed by a relevance decision. A good description helps the model choose; a good policy…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.