Back to blog
DesignApril 11, 2026·7 min read

Designing the Skills library

Capabilities as apps you toggle on. How we kept the model honest about what it can and can't do at any given moment.

The Froots team
Froots

There’s a quiet problem with most agent frameworks: the model has access to fifty tools and the prompt instructs it to “use them when appropriate.” That works for demos. It breaks the moment a user asks something ambiguous and the model picks the wrong tool with confidence.

Skills are our answer. They’re a unit between “tool” and “app” — a named, scoped capability that you toggle on for a session.

The mental model

Think of skills like apps on a phone. You don’t have every app open all the time. You open Maps when you need to navigate. You open Camera when you want a photo. The phone doesn’t ask the OS to “figure out from context” which app to open — *you* decide, and the apps make themselves available to the OS.

Skills work the same way. Each skill bundles a system prompt fragment, a set of tools, and trigger conditions (keywords, file types, MCP servers, schedules). When you toggle on the “Research” skill, the model gains web search, scraping, and citation tools, plus a system prompt that explains *when and how* to use them. Toggle it off and those tools vanish — the model can’t accidentally call them.

Why this beats one big prompt

Models trained on long, kitchen-sink system prompts are worse at every individual task than models with focused prompts. The cost of an unused instruction isn’t zero — it’s mild confusion. Skills let us keep the active prompt small and sharp, and let the user opt into complexity exactly when they want it.

It’s also better for debugging. When the model does something weird, you can ask “which skill was active?” and inspect the exact prompt + tools it had access to. No more “why did it just call the wrong API?”

The hard part: honesty

The trickiest design decision was making the model *honest* about what it can and can’t do. If you turn off the Email skill, the model needs to say “I can’t send email right now — want me to enable the Email skill?” instead of either silently failing or hallucinating that it sent something.

We landed on a small meta-skill that’s always on: the model knows which skills exist, which are active, and how to ask for one to be enabled. That gives you the best of both worlds — a clean active surface, and a model that knows what’s behind the curtain.