{"slug": "skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent", "title": "Skills Sprawl: When Too Much of a Good Thing Confuses Your AI Agent", "summary": "Darren 'Dazbo' Lester, a Google Cloud developer advocate, warns that installing too many agent skills can cause 'skills sprawl,' leading to LLM decision fatigue and reduced tool selection accuracy. He explains that while skills use progressive disclosure to load only frontmatter initially, an excessive number can overwhelm the model, and pruning skills can improve agent performance and save hundreds of thousands of tokens per session.", "body_md": "In this post, we’re going to look at the problem of **Skills Sprawl**.\n\n*What happens if you have too many skills?*\n\nWe’ll understand LLM decision fatigue and tool selection accuracy, inspect the mechanics of excluded vs inactive skills in Google Antigravity, and see how pruning your setup can make your agent smarter and save hundreds of thousands of tokens per session.\n\nEveryone knows that *agent skills* are awesome. If you don’t, then:\n\nIn some of my previous posts I’ve talked about how skills act as **on-demand power-ups** for our agents. We use them to provide knowledge, rules, and workflows to do things the agent (or more specifically, the model) didn’t otherwise know how to do effectively.\n\nYou might have seen me compare this to how Neo loads his skills in the Matrix. *“I know Kung Fu!”*\n\nThis *just-in-time knowledge* provides a number of advantages to our agents:\n\nIn short: **faster, cheaper, and more reliable**.\n\nQuick aside: when I say *agent*, I’m typically talking about your agentic partner in development crime, like [Google Antigravity](https://antigravity.google/?utm_campaign=DEVECO_GDEMembers&utm_source=deveco), Claude Code, or whatever. But when you’re building your own agentic solutions, you can use skills in exactly the same way. For example, check out my blog [Automated GitHub Code Reviews Using Google Gemini](https://medium.com/google-cloud/automated-github-code-reviewsusing-google-gemini-7b4d027b3092?utm_campaign=DEVECO_GDEMembers&utm_source=deveco), where I’ve built an agentic PR review solution that leverages skills.\n\nSkills use a cool mechanism called **progressive disclosure** to load on-demand.\n\nLet’s quickly recap this mechanism:\n\nWhen your agent starts up, it reads **the frontmatter** — and **only the frontmatter** — of **every installed skill** in your global configuration and workspace.\n\n*By the way, if you don’t know where these skills should be placed, or you don’t know the difference between global and workspace locations, check out my earlier blog:* *Confused About Where to Put Your Agent Skills?*\n\nThe frontmatter is simply the descriptive YAML at the top of each skill which contains the skill name, a description (what it does and when it should be used), and any additional useful metadata (such as what tools it might use, author, etc).\n\nFor example, this is from my `maintaining-core-documentation`\n\nskill:\n\n```\nname: maintaining-core-documentation\ndescription: |\n  Creates, maintains, and synchronises core project documentation \n  (README, TODO, DESIGN, Architecture, Testing, Deployment). \n  Use when the user needs to write, update, or structure project documentation \n  based on codebase changes, or whenever asked to perform documentation \n  reviews or updates.\nmetadata:\n  author: Darren \"Dazbo\" Lester\n  repository: https://github.com/derailed-dash/dazbo-agent-skills\n```\n\nCrucially, this frontmatter section is *tiny*. So even though the agent reads it up-front, it consumes very few tokens. Typically fewer than 100 tokens per skill.\n\nThe agent now has a mental model of all the skills that are available to it.\n\nWhen the agent is asked to do a task that one of these skills might be useful for, the model selects the skill (based on the frontmatter), and then **activates** it. When this happens, the agent reads the `SKILL.md`\n\nbody into context.\n\nThis will typically add several hundred, if not thousands of tokens.\n\nSome skills may package additional resources, such as scripts, reference documents, or other assets. For example, my `maintaining-core-documentation`\n\nskill has a `references`\n\nsubdirectory with several document template files.\n\nThese assets are only loaded as needed.\n\nWhen we have skills, we don’t need to include massive quantities of instructions in our global `GEMINI.md`\n\nor `AGENTS.md`\n\nfiles. Instead, all this knowledge is packaged into individual, self-contained, portable, on-demand units of knowledge.\n\nIt is an elegant, modular pattern that massively reduces your token consumption.\n\nThere’s no shortage of skills out there! You can use a public hub like [skills.sh](https://skills.sh/) to find just about any skill you need. And, of course, you can create your own.\n\nCheck out my blog [ Dialling Our Agents to 11: Agent Skills You Need to be Using!](https://dev.to/gde/dialling-our-agents-to-11-agent-skills-you-need-to-be-using-2o2k), where I list some of my favourite skills.\n\nThe problem is… You end up *collecting.*\n\nI recently asked Antigravity to tell me how many skills I have. (I have sarcasm dialled up…)\n\n```\nWell, Dazbo, according to my context window — which is currently groaning \nunder the crushing weight of your digital hoard — you currently have a \nstaggering 170 skills installed.\n\nBecause obviously, why settle for a sleek, efficient setup when you can \nforce your AI assistant to lug around the instruction manual for every \nobscure file converter, niche API, and hypothetical cloud deployment \nscenario known to humanity?\n\nTruly, nothing says 'peak productivity' quite like burning thousands of \ntokens before we've even started speaking, just so I know how to format a \nDev.to post while simultaneously standing by to orchestrate a multi-region \nSpanner failover.\n\nI'm sure you'll be adding a 171st skill any second now - presumably \none to help you manage the utter chaos of the first 170.\n```\n\nHilarious. 170. *Maybe I have too many.*\n\nThe irony here is that Antigravity’s last comment was spot on. I decided to **build a skill to organise and optimise my skills!**\n\nAs we’ve already covered: with progressive disclosure, the agent framework performs **Tier 1 Discovery** on startup. It parses the frontmatter of **every installed skill** and injects this straight into the system prompt.\n\nA well-crafted skill description needs enough context, trigger keywords, and intent markers for the LLM to know when to select it. (*“Use when…”*)\n\nWhen I analysed my 170 skills, it turns out that my average skill frontmatter contained 103 tokens. Now let’s do some quick maths:\n\n170 active skills × 100 tokens/description = 17,000 tokens\n\nThat means my agent is injecting **17,000 tokens of system prompt overhead on every single turn**.\n\nIf I’m engaged in a typical 30-turn pair-programming session:\n\n30 turns × 17,000 tokens = 510,000 tokens\n\nThat means I am burning an additional **half a million tokens** just to re-read the index of my skill library over and over again.\n\n*So what?*\n\nLet’s look at some of the potential issues this creates:\n\nSkills sprawl causes **decision fatigue and skill selection accuracy degradation**.\n\nWhen a model is presented with 170 potential skills simultaneously, it faces **choice ambiguity**. Many skills will naturally have overlapping domain descriptions. For example, my 170 skills had overlaps in each of these areas:\n\nDoes academic research back this up? Absolutely.\n\nIn a recent paper titled [ “How Many Tools Should an LLM Agent See? A Chance-Corrected Answer”](https://arxiv.org/pdf/2605.24660) (\n\nThey concluded:\n\n*“Show too many tools and the model struggles to choose. Show too few and the correct tool may not appear.”*\n\nThere is an important nuance here: if you only give a model 2 choices, it has a 50% chance of guessing correctly by pure luck. If you show it 50 choices, blind luck drops to 2%.\n\nWhen the researchers **corrected for random chance** — measuring genuine model comprehension rather than lucky guesses — the impact of list size was striking:\n\nRelated benchmarks like [ MetaTool](https://arxiv.org/abs/2310.03128) and\n\nOkay, in this blog, I’m talking about skills, not tools. But the principle is the same. Too many skills lead to the same problems of confusion caused by description collision.\n\nWe want:\n\n**I need a way to optimise my installed skills!**\n\nBefore I start pruning my skills, I need to understand why I have so many.\n\nI went back and reviewed my Git history to trace how I got here. Here’s what I discovered:\n\n`google/skills`\n\n`google/agents-cli`\n\n`google-gemini/gemini-skills`\n\n`GoogleCloudPlatform/vertex-ai-creative-studio`\n\n`derailed-dash/dazbo-agent-skills`\n\n`addyosmani/agent-skills`\n\n`shubhamsaboo/awesome-llm-apps`\n\n`deep-research`\n\n, `fact-checker`\n\n, `strategy-advisor`\n\n, `technical-writer`\n\n, `content-creator`\n\n).`wshobson/agents`\n\n`documentation-and-adrs`\n\n, `interview-me`\n\n), `coreyhaines31/marketingskills`\n\n`seo-audit`\n\n), `remotion-dev/skills`\n\n`remotion-best-practices`\n\n), and `vercel-labs/skills`\n\n`find-skills`\n\n).Here is the complete breakdown of the 170 skills I had installed, grouped by category and origin repository:\n\n| Group / Category | Count | Source Repository / Origin Link | Summary of Included Skills |\n|---|---|---|---|\nGoogle Cloud Core Services & WAF |\n82 |\n`google/skills` |\n\n`addyosmani/agent-skills`\n\n`using-agent-skills`\n\n).`google/agents-cli`\n\n`find-skills`\n\n).`google-gemini/gemini-skills`\n\n`google-genai`\n\nSDK), multimodal streaming, Live API, NotebookLM auth, and server-managed interactions.`vertex-ai-creative-studio`\n\n`derailed-dash/dazbo-agent-skills`\n\n`dazbo-content`\n\n), secrets management (`git-crypt`\n\n), UTM link tagging, PR review actions, skill organisation, and deployment.`shubhamsaboo/awesome-llm-apps`\n\nSo you can see how easy it is for your skills base to get out of hand! Especially if you work with Google Cloud and Google AI services like I do. It’s super easy to install over 100 Google-related skills, by just following a few Google blog recommendations.\n\nI asked Antigravity to read all of my skills in detail, and identify any areas of overlap and redundancy.\n\nThere was a LOT of redundancy! We uncovered seven major categories of overlap, duplication, and inefficiency:\n\n`google/skills`\n\n`gemini-agents-api`\n\ndeclared `name: gemini-managed-agents-api`\n\nin its frontmatter. This directory vs. frontmatter mismatch caused installation tools to spawn two exact duplicate folders (`gemini-agents-api`\n\nand `gemini-managed-agents-api`\n\n) carrying 100% byte-for-byte identical content.`google-generativeai`\n\npackage and obsolete model strings, directly contradicting modern `google-genai`\n\nSDK standards and confusing the agent during code generation.`gemini-api`\n\nskill in `google/skills`\n\n`gemini-api-dev`\n\nin `google-gemini/gemini-skills`\n\n`gemini-api`\n\n, `gemini-api-dev`\n\n, `gemini-agents-api`\n\n, `gemini-interactions-api`\n\n, and `gemini-live-api-dev`\n\n).`google/skills`\n\n`addyosmani/agent-skills`\n\n`test-driven-development`\n\nand `code-review-and-quality`\n\n) were loaded into system prompt context at startup, despite being child sub-skills already orchestrated on-demand by `using-agent-skills`\n\n. Similarly, 20 sub-skills from `google/agents-cli`\n\n`google-agents-cli-workflow`\n\n.`adk-docs-mcp`\n\nserver were redundant because `google-developer-knowledge`\n\nalready indexes ADK documentation (`adk.dev`\n\n).`documentation-and-adrs`\n\n(`addyosmani/agent-skills`\n\n`architecture-decision-records`\n\n(`wshobson/agents`\n\n`content-creator`\n\n(`shubhamsaboo/awesome-llm-apps`\n\n`dazbo-content`\n\nBeyond the sheer volume of redundant skills, I made another cool discovery: **many skill collections come with a “parent” Meta-Skill.**\n\nWhen you install a large collection of skills — such as Addy Osmani’s engineering skills ([ addyosmani/agent-skills](https://github.com/addyosmani/agent-skills)), or Google's 20 Agent Platform skills (\n\n`google/agents-cli`\n\nHowever, these skill suites are designed to be **hierarchical**:\n\n`addyosmani/agent-skills`\n\n:`using-agent-skills`\n\nmeta-skill.`google-agents-cli-workflow`\n\nmeta-skill.`gcp-data-pipelines`\n\nmeta-skill.In each case, the parent meta-skill is supposed to work as a sort of skills index or decision tree. When a specific task comes in — such as writing unit tests or running a security audit — the parent meta-skill directs the agent to fetch and read *only* the specific *child* sub-skill from disk on demand.\n\nConclusion? **We don’t need to load the frontmatter of all the child skills. We only need the parent skill!** In the examples above, I can easily replace nearly 50 skills with just 3 orchestration skills!\n\nSo now I could implement a solution to organise my skills. The primary objectives:\n\nTo design a lean agent workspace, we must be crystal clear on the three distinct states a skill can occupy throughout its lifecycle. They can be:\n\nLet’s define these in more detail:\n\n`SKILL.md`\n\nbody has been loaded into the current turn context, i.e. Level 2 loading (and Level 3, where supporting files are present and appropriate).Crucially, **both installed and inactive and installed and excluded skills can transition into this Activated state.**\n\nSo now we know that a good optimisation strategy is to use exclusion to prevent a bunch of skills being loaded at startup into the “Installed and inactive” state.\n\nBut how can we do this?\n\nIn **Google Antigravity**, global skill exclusions are managed via `~/.gemini/config/skills.json`\n\n(or `.agents/skills.json`\n\nfor workspace-level skills).\n\nThe native `exclude`\n\narray accepts skill folder names. For example:\n\n```\n{\n  \"exclude\": [\n    \"alloydb-basics\",\n    \"cloud-spanner-migrations\",\n    \"firebase-basics\"\n  ]\n}\n```\n\nAny skill listed in the `exclude`\n\narray is completely skipped during Tier 1 discovery. Its frontmatter is therefore **not** injected into the system prompt, saving tokens instantly.\n\nSo this is easy!\n\nBut here’s a cool trick. You can easily “un-exclude” a skill by prefixing its name with `//`\n\ninside the quotes. This is useful because it allows us to re-enable up-front skill loading, without having to check our disk to find the skill and its name.\n\nSo my approach is to always have *all* my available skills in the `exclude`\n\nlist, but to comment-out the ones that need to be discovered automatically.\n\nNote: I have the `//`\n\n*inside* the quotes. Why? Because this is not valid JSON:\n\n```\n{\n  \"exclude\": [\n    //\"alloydb-basics\",\n    //\"find-skills\",\n    \"firebase-basics\"\n  ]\n}\n```\n\nBut this is:\n\n```\n{\n  \"exclude\": [\n    \"//alloydb-basics\",\n    \"//find-skills\",\n    \"firebase-basics\"\n  ]\n}\n```\n\nAnd because the `exclude`\n\nlist uses *exact* string matching, you can use this `//`\n\ntrick to enable/exclude skills on the fly, without having to remove the skill from the `exclude`\n\nlist entirely.\n\nIn the example above:\n\n`alloydb-basics`\n\nand `find-skills`\n\nare `firebase-basics`\n\nNow we’ve got everything we need to implement a repeatable mechanism to organise and clean up our skills.\n\nBecause: when you’ve got too many skills, you definitely need one more. (In this way, skills are a lot like guitars, or cats.)\n\nAnyway, based on what I learned, I created a skill that:\n\nLet’s see how it performs! After installing my skill, I said to Antigravity:\n\n*“Optimise my skills please”*\n\nMy skill ran and presented this proposal summary table:\n\n| Metric | Baseline (Unoptimised) | Proposed (Optimised) | Delta / Savings |\n|---|---|---|---|\nInstalled Skills Directories |\n170 | 165 | -5 (-2.9%) |\nInstalled & Discoverable Skills |\n170 | 49 | -121 (-71.2%) |\nInstalled & Excluded Skills |\n0 | 116 | +116 |\nPrompt Token Overhead |\n~17,000 tokens | ~3,350 tokens | -13,650 tokens (-80.3%) |\n\nIt goes on to say:\n\n```\nUpon your confirmation, I will execute the following steps:\n\n1. **Retire Redundant Skills**: Delete the 5 redundant skill directories\n   (`gemini-managed-agents-api`, `liveapi-service`, `documentation-and-adrs`, \n   `gemini-api-dev`, `gemini-live-api-dev`) from `~/.gemini/config/skills/`.\n2. **Generate Optimised `skills.json`**: Write the full-inventory \n   `~/.gemini/config/skills.json` with 49 active skills (`//` prefix) and \n   116 excluded skills.\n3. **Verify Context Footprint**: Re-audit the active skill prompt token \n   overhead to confirm successful reduction to ~3,350 tokens.\n\n---\n> [!IMPORTANT]\n> **Mandatory Guardrail Confirmation**: In accordance with \n  `organise-agent-skills` guardrails, please confirm if you would like me \n  to proceed with deleting the 5 redundant skill directories and creating \n  the optimised `~/.gemini/config/skills.json`.\n```\n\nBy trimming back to a core of 49 active skills and delegating the rest to meta-skills and on-demand rules:\n\nAgent skills are awesome. They’re so easy to find, install and use. But when we allow skills to sprawl unchecked, we start confusing our agents. This impacts accuracy, reliability, performance, and cost.\n\nSo increasingly, we need a way to manage and optimise our skills. For this, I’ve done some work so you don’t have to!\n\nFeel free to download my optimisation skill off-the-shelf:\n\n```\n# Install all the Dazbo Agent Skills\nnpx skills add https://github.com/derailed-dash/dazbo-agent-skills\n\n# Install just the `Organise Agent Skills` skill\nnpx skills add https://github.com/derailed-dash/dazbo-agent-skills --skill organise-agent-skills\n```\n\nOr if you have the Vercel `find-skills`\n\nskill installed, you can just ask your agent:\n\n*“Install dazbo-agent-skills for me.”*\n\nSo, that’s it, folks. Go forth and optimise. If you find this skill useful, please give the [repo](https://github.com/derailed-dash/dazbo-agent-skills) a star.\n\n*Have you experienced Skills Sprawl in your agentic environment? How many skills are currently active in your setup? Let me know in the comments below!*", "url": "https://wpnews.pro/news/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent", "canonical_source": "https://dev.to/gde/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent-4nij", "published_at": "2026-08-17 10:13:26+00:00", "updated_at": "2026-08-17 10:43:24.537592+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-tools"], "entities": ["Google Antigravity", "Claude Code", "Google Gemini", "Darren Lester"], "alternates": {"html": "https://wpnews.pro/news/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent", "markdown": "https://wpnews.pro/news/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent.md", "text": "https://wpnews.pro/news/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent.txt", "jsonld": "https://wpnews.pro/news/skills-sprawl-when-too-much-of-a-good-thing-confuses-your-ai-agent.jsonld"}}