AgentKits Marketing Has 28 Skills. It Never Loads More Than Five.

A Registry Built to Say No

skills-registry.json, the file at the center of AgentKits Marketing’s “Enterprise Skill System,” catalogs 28 skills across five categories — core marketing fundamentals, conversion-rate optimization, content, SEO/growth, and document creation. It also encodes something less obvious: a dependencyGraph object that says which skills require which others before they can run. signup-flow-cro requires form-cro, which requires page-cro. paywall-upgrade-cro requires both page-cro and pricing-strategy. ab-test-setup requires page-cro and analytics-attribution. Every entry in the registry also carries a triggers array — plain keywords like “funnel,” “TOFU,” “bounce rate,” “signup flow” — that a request gets matched against.

None of that machinery exists to help an agent find more skills. It exists to help it load fewer. dependency-graph.md, the companion file that spells the algorithm out in prose, is explicit about the goal in its third step: “Limit context — Load max 3-5 skills to avoid context rot.” Twenty-eight skills are cataloged. A given task is meant to touch three to five of them, chosen deliberately, never the whole shelf at once.

The Research Doc Behind the Registry

The registry isn’t the first artifact in this repo to name the problem. docs/improvement-research-260201.md — dated February 1, 2026, months before the current registry shipped — lays out the reasoning that led to it. Under a section titled “Semantic Skill Selection (RAG Pattern),” it states the problem plainly: “Too many skills causes ‘context rot’ and decision fatigue,” citing Elastic’s public writing on context engineering for AI agents. The proposed fix in that doc was a retrieval pipeline — index every skill’s description as an embedding, match a user’s request semantically, “return top 3-5 relevant skills only.” The same document also cites MuleSoft’s framing of an “agentic enterprise” architecture, which calls for a formal Skill Catalog and Capability Marketplace as first-class infrastructure, and references the Agent Skills open standard directly, noting that AgentKits’ SKILL.md format with YAML frontmatter already matched it.

What actually shipped is a scoped-down version of that proposal. commands/skills/select.md, the /skills:select command, doesn’t call an embedding model or a vector store. Its “Selection Algorithm” is keyword-trigger matching with a manual scoring scheme — exact trigger match weighted 1.0, partial match 0.5, category match 0.3 — followed by a depth-first walk of dependencyGraph to pull in prerequisites, then a hard ceiling: “Maximum 5 skills to avoid context overload.” The command’s own frontmatter restricts it to two tools, Read and Grep — the whole selection process runs by having the agent read skills-registry.json and dependency-graph.md directly and reason over them, rather than standing up retrieval infrastructure to do it. The research doc asked for semantic search; what’s in the repo today is closer to a documented, auditable heuristic that any contributor can read start to finish in two markdown files. It gets the registry’s actual goal — bounded, ordered loading — without the embedding pipeline the original proposal specified.

The Problem Is Real, Not Just Internal

“Context rot” is not a term this project coined. It’s the name Chroma gave its own technical report evaluating how 18 current models — including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3 — handle growing input length (Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance”). The finding that matters here isn’t that long inputs cause outright failure; it’s that model performance degrades unevenly and unpredictably as context grows, even on deliberately simple tasks like retrieval, well before any stated context-window limit is reached. The report’s conclusion — that a bigger context window is not a substitute for choosing carefully what goes into it — is the exact justification the AgentKits registry gives for its own five-skill ceiling, arrived at independently and about a year apart.

The same instinct has since become an industry standard rather than a house rule. Anthropic’s Agent Skills, published as an open format after launching as a developer feature in October 2025, are built around the same shape of tradeoff under a different name: progressive disclosure. Coverage of the standard describes three stages — discovery, where an agent sees only a skill’s name and short description; activation, where a matched task pulls the full instructions into context; and execution, where bundled scripts or reference files load only if the work actually needs them — so a large skill library costs only a small amount of context until something in it is actually relevant (Anthropic, “Equipping agents for the real world with Agent Skills”). AgentKits’ own SKILL.md format already matched that shape before the registry existed, which is presumably why the improvement-research doc could point at the open standard and note the fit rather than propose changing the file format itself.

What This Buys, and What It Doesn’t

The honest way to describe AgentKits’ skill system, as it’s actually built today, is: a keyword-and-dependency heuristic doing the job a semantic-retrieval system was originally scoped to do, in service of a context-budget constraint that the industry’s own research now treats as a real limit rather than a hypothetical one. It isn’t the most sophisticated version of skill selection that’s technically possible — the Feb 1 research doc itself still lists embedding-based matching as unfinished, higher-effort work. But it’s a version that’s legible, that runs on tools the agent already has, and that enforces the one number — five skills, not twenty-eight — that the context-rot research says actually matters more than how the five get chosen.

---

AgentKits is open source and free forever under the MIT license. Read the skills registry and the selection algorithm yourself in the agentkits-marketing repo, or follow what ships next at agentkits.net, or reach us at [email protected].