Consider aggregating more of these skills into agents

We're still learning how to factor / when to prefer agent groupings, so our guiding principle should probably be "do reasonable things that allow us to learn"

Proposal --

# Skill-to-Agent Grouping Proposal

The `dotnet` plugin has 13 skills but only 1 agent (`optimizing-dotnet-performance`). (MSBuild does have an agent in its plugin, with 3 skills.) 12 of 13 skills are not referenced by any agent. This proposal identifies natural clusters and evaluates whether wrapping them in an agent adds value.

## Proposed Groupings

| Agent | Skills | Notes |
|-------|--------|-------|
| `optimizing-dotnet-performance` (existing) | `analyzing-dotnet-performance`, `microbenchmarking`, `optimizing-ef-core-queries` | Already references the first. The other two are natural extensions: EF Core is a specific perf domain the agent should detect, and benchmarking is the natural follow-up to finding issues. |
| `dotnet-diagnostics` (proposed new) | `dotnet-trace-collect`, `dump-collect`, `android-tombstone-symbolication`, `clr-activation-debugging` | All address "something is wrong at runtime." User often doesn't know which tool applies — triage by symptom/platform is the core value. |
| `dotnet-modernization` (proposed new, weakest case) | `dotnet-aot-compat`, `migrate-nullable-references`, `thread-abort-migration` and the version to version upgrade skills currently in PR | All are "upgrade my codebase" playbooks. But entry points are specific (IL warnings, CS86xx, SYSLIB0006) so triage ambiguity is low. Could defer. |
| *(no agent)* | `csharp-scripts`, `dotnet-pinvoke`, `nuget-trusted-publishing` | Standalone topics with no sibling skills to orchestrate. Users know exactly what they want when invoking these. |

## When does an agent add value over standalone skills?

An agent adds value in three scenarios:

1. **Triage under ambiguity** — The user's problem doesn't map cleanly to one skill. "My app is crashing" could mean `dump-collect`, `android-tombstone-symbolication`, or something else. An agent asks clarifying questions and selects the right skill.

2. **Multi-skill orchestration** — The task naturally requires multiple skills in sequence. The existing `optimizing-dotnet-performance` agent demonstrates this: it runs its own analysis, then loads `analyzing-dotnet-performance`, deduplicates, and merges results.

3. **Model-invoked routing** — Agents with `disable-model-invocation: false` can be automatically selected by the runtime based on the user's natural-language request. Skills are only loaded when explicitly invoked or when an agent references them.

An agent does **not** add value when the user's intent is clear and maps to exactly one skill, skills are independent and rarely combined, or the maintenance overhead exceeds the routing benefit.

## Assessment by group

### Diagnostics agent — strongest case

The diagnostics agent has the clearest value. "My app is crashing" is genuinely ambiguous — it could mean an Android tombstone, a server crash dump, or a .NET Framework activation issue. An agent that triages by asking about platform and symptom saves the user from needing to know which of 4 skills exists. It also enables model-invoked routing: the runtime can match natural-language requests to the agent without explicit invocation.

### Performance agent expansion — low cost, natural fit

This is low-cost/high-return — the agent already exists, and adding two skill references extends its coverage without changing its structure. When it detects EF Core patterns (`DbContext`, `Include(`, `.ToListAsync()`) during its code scanning pass, it loads domain-specific guidance from `optimizing-ef-core-queries`. After analysis, it can suggest benchmarking with `microbenchmarking` when findings warrant measurement.

### Modernization agent — weakest case, consider deferring

These three skills are rarely needed together, and users typically arrive with a specific compiler warning rather than "modernize everything." The main value would be an assessment step — "I'm upgrading to .NET 8, what do I need?" — but that's a thin orchestration layer over a few grep commands. Recommend deferring unless there's evidence users struggle to find the right migration skill on their own.

Start by inspecting the dotnet plugin's existing agent and its 13 skills, especially optimizing-dotnet-performance and the proposed diagnostics group. Compare the listed skills with current agent references and invocation behavior. Done means a decided grouping plan, with any accepted agent additions or skill references reflected consistently and the deferred modernization case recorded.

Written by the indexing model from the issue text.