A Type System for Agent Skills
Six categories, one linter, and what breaks when you make three hundred skills composable.
An agent skill library grows the way any codebase grows: one useful thing at a time, until one day you have three hundred of them and no way to know which ones compose. Chaining skills by intuition works at ten. At three hundred it produces pipelines that typecheck in your head and fail in reality.
So I typed them. Every skill in my library declares one of six categories: a generator produces material from nothing, a transformer refines material into more material, a reducer collapses many candidates into one, a distributor fans one input into many paths, an effector changes world state, and an auditor reads state and reports. Each carries an input type, an output type, and an effect list.
Why six categories work
A linter enforces the schema across the library in a tenth of a second, and a two-tier router uses the types at selection time: first recall by relevance, then scoring with type compatibility as an explicit weight. The library stopped being a folder of prompts and became something closer to a standard library, checkable, composable, and prunable by utility.
The deeper effect was cultural. Typing three hundred skills forces a confession about each one: what does this actually consume and produce? Roughly a tenth of the library could not answer cleanly, and most of those turned out to be duplicates or dead weight. A type system, here as everywhere, is less about catching errors than about forcing definitions.
One open edge keeps me honest: the silent action. A monitoring skill that must speak every time it runs is a notification machine nobody trusts. Making stay-silent a first-class, type-legal output, an auditor that returns nothing most of the time by design, turned out to be the single most useful addition to the whole system.