Being respectful of the users context window

I wanted to share some feedback on the current Azure Skills installation approach.

First, I appreciate the work that has gone into the Azure skills. They are valuable when I’m working in Azure, and I understand the goal of making them broadly available across compatible agent hosts.

My concern is with the decision to install the full Azure skill set globally into the user’s ~/.agents/skills directory.

That directory is becoming a shared ecosystem for all agent-based tooling, not just Azure. Installing approximately 25 Azure skills globally assumes that Azure is a primary concern for every agent session. In reality, many of us work across multiple ecosystems throughout the day. My environment includes Azure, AWS, Google Cloud, Python, .NET, JavaScript, Kubernetes, GitHub, and many other technologies. If every extension adopted the same approach and installed 20–30 skills globally, users could easily accumulate hundreds of globally discoverable skills.

Even if skill retrieval is intelligent, every additional globally available skill increases discovery overhead, metadata, and potentially prompt context. A few dozen 50–80 token skill descriptions quickly become several thousand tokens. Scaled across many extensions, this could result in 15,000–20,000 tokens of context devoted to capabilities that are irrelevant to the current task.

I believe this is fundamentally an ecosystem issue rather than an Azure issue. Extensions should strive to minimize their global footprint and avoid assuming they are the only consumer of the shared .agents space.

Some alternatives that would preserve the excellent Azure experience while being more considerate of the broader ecosystem include:

* Adopt progressive disclosure by grouping related capabilities into a small number (for example, five) high-level Azure skills. Those skills could then expose more specialized capabilities only when they become relevant, keeping the initial discovery cost well under 200 tokens.
* Support just-in-time installation, where Azure skills are added to a project only when the user explicitly enables them or when Azure work is first detected.
* Make project-local installation the default, with global installation as an explicit opt-in.
* Provide a setting to disable automatic global skill installation entirely for users who prefer to manage their own shared agent environment.

As the agent ecosystem continues to grow, I think it will become increasingly important for extensions to behave as good citizens of the shared environment. Keeping global context lightweight benefits everyone and helps ensure that agent platforms remain scalable as users adopt more tooling over time.

This feedback is offered in the spirit of improving what is already a very useful feature. I hope the team will consider approaches that balance discoverability with minimizing the impact on the user’s overall agent ecosystem.

The issue does not name implementation files, tests, or an entry point. Start by locating the Azure skill installation flow and its handling of ~/.agents/skills, then establish which installation policy the maintainers want; done should include an agreed scope and acceptance criteria for reducing or controlling global skill installation.

Written by the indexing model from the issue text.