For .NET · works with Claude Code, Cursor & Copilot
Sidekit runs next to your .NET solution and answers the questions your coding agent keeps asking — where the code lives, what compiles, which tests to run, and what actually broke.
A grep across the repository, or a cold dotnet test, spends thousands of tokens to
say what fits in a line. Same answer, a fraction of the cost, back sooner.
…and it keeps going. Kilobytes, to say “yes”.
{"generation":7,"unchanged":true}
This is one edit, start to finish. Your agent asks each of these without leaving its loop — and the answers come back small enough that it can afford to ask every time.
Before it edits. The code downstream of this file and the tests guarding it. Point at a line and it narrows to that one symbol.
Right after it edits. Real compile errors, structured, without paying for a cold build every single time.
Before running anything. Only the tests your change actually reaches — read from your working tree, not guessed at.
When something goes red. Grouped by root cause, so one broken helper is one line instead of eighty.
Before anyone panics. Checked against run history, so your agent doesn’t spend the afternoon chasing a ghost.
Plus run_tests to actually run them, find_symbol and
find_usages to locate code, and doctor when something looks wrong.
Parameters and example answers for each.
Before an agent can change anything it has to find it — and its usual move is to grep the repository and read a few hundred matching lines hoping the right one is in there. These two questions are answered from the structure of your solution instead of by matching text.
Kind, file, line and signature for every match — 37 tokens where the
grep that answers the same question costs 2,496.
Every use across the whole solution, grouped by file. Sixty of them across twelve files came back in 264 tokens — and none of them were comments or strings.
Parameters, example answers, and what happens when the name you asked about is declared nineteen times.
A cold dotnet test dumps restore logs, build logs and per-test noise into the
context window — thousands of tokens, most of it irrelevant, every time round the loop.
Here is what Sidekit sends back for the same questions.
These are ceilings its own test suite enforces, not averages measured on a good day.
| A status check where nothing changed | ~33 B | |
|---|---|---|
| Which tests cover this file | ≤ 100 B | |
| What should I run for this change | ≤ 150 B | |
| A green test run, start to finish | ≤ 200 B | |
| A run with a hundred failures | ≤ 800 B | |
| Every use of a symbol, across sixty files | ≤ 900 B |
Full width of the track = 1 kB.
Three steps, and the third is the one people skip.
Checks for the .NET 10 SDK before it changes anything. Running the same command again later is how you upgrade — there is no second command to remember.
curl -fsSL https://sidekit.net/install.sh | sh # macOS / Linux iwr -useb https://sidekit.net/install.ps1 | iex # Windows
Then sidekit doctor in a .NET repository to confirm the toolchain.
Install notes, including how to do it by hand.
Sidekit binds to the directory your agent launches it in, so there are no absolute paths and this file works for everyone who clones the repository.
{ "mcpServers": { "sidekit": { "command": "sidekit", "args": ["mcp"] } } }
Cursor and GitHub Copilot use the same shape with one key renamed — all three are here.
Wiring it up is not enough. An agent that already knows dotnet test will
keep running dotnet test unless its instructions say otherwise — and then
you have installed Sidekit and saved nothing. Add this to CLAUDE.md,
.cursorrules or .github/copilot-instructions.md:
## Test intelligence
This repository runs a Sidekit MCP server. Prefer it over raw `dotnet`:
- To find code, `find_symbol` and `find_usages` instead of grepping the repository.
- After editing, `get_status` for build truth — it is warm and costs a few tokens.
- To test a change, `select_tests`, then `run_tests` on what it returns.
- On failure, `get_failures`. Never re-run tests just to see the output again.
- If a failure looks non-deterministic, `get_flaky_tests` before believing it.
The full version covers the other two hosts and a couple more habits worth nudging.
Sidekit decides which of your tests are worth running. That only works if you believe it.
It doesn’t simulate anything. Sidekit builds and runs your tests on the real .NET toolchain, out of process — the same way your CI would — and never loads your code into its own process. What it reports is what your toolchain actually did.
It’s pointed at real open-source .NET repositories at pinned commits — projects nobody here designed, with all the awkwardness that implies. The bar it has to clear is that it loads, stays diagnosable, and never leaves out a test that should have run. Not that the tests pass.
It answers less precisely and says so, rather than guessing. Every answer carries its own
confidence label, so your agent can tell a narrow answer from a wide one instead of
trusting a precision it never got. When something is genuinely wrong,
sidekit doctor names what’s degraded and how to fix it.
A .NET global tool that runs locally and talks to your agent over stdin and stdout.
Sidekit itself opens no network connections — no account, no telemetry, no
license check. Everything it learns about your solution stays in a
.sidekit/ folder you can delete.
It does run dotnet on your behalf, so a restore still reaches NuGet exactly
as it would from your own shell. Nothing else leaves the machine.