dotnet-selfeval

Evaluating the toolkit against the repo it is pointed at

This plugin's whole claim is that its tools answer C# questions more completely, and for fewer tokens, than Grep and Read. That claim is only ever exercised against whatever repo the server happens to be loaded with — and repos differ in exactly the ways that break retrieval tools: nested types, partial classes split across files, heavy overloading, generics, multi-targeted .csprojs, .slnx vs .sln, source generators, unconventional folder layouts. This skill is the measurement pass that turns "the tools feel efficient" into a per-call token number with a cheaper alternative next to it.

Prerequisite: Load dotnet-read skill

Before proceeding, ensure dotnet-read has been loaded. This skill contains the validated cheap-route table that serves as the ground truth for route comparison, and teaches how to interpret limitedBy values and workspace readiness. If you haven't read it yet, invoke dotnet-read.

This takes <1s and gives you:

• The cheap-route table of verified cheaper alternatives
• Workspace readiness rules for stale, degraded, and index_only
• Best practices for taskId isolation and metrics sampling
• Field naming conventions and response structure

Reading this before the evaluation ensures you're comparing against the correct baseline and can recognize when your own route analysis aligns with established guidance.

The one rule: specimen vs subject

The consuming repo is the specimen. dotnet-toolkit is the subject.

Every probe reads the repo the server is pointed at — whatever workspace_status reports as root, resolved by SolutionLocator from DOTNET_TOOLKIT_PROJECT_DIR, then CLAUDE_PROJECT_DIR, then the working directory. When this repo is the target it probes itself; installed elsewhere, it probes that repo. Never aim the probes at a different repo than the loaded workspace — the semantic tools can only answer for the loaded solution, so a cross-repo probe measures nothing.