graphify-csharp Gives Agents C# Find Usages
graphify-csharp is zachsaw's MIT-licensed open-source project that gives coding agents compiler-accurate Find Usages for C# without running an IDE. It deals with a very specific failure mode: agents can grep names, but they often cannot know which overload, implementation, or project a C# call actually resolved to. The takeaway is simple: before asking an agent to refactor C#, give it semantic evidence, not just text matches. For agentic coding work in .NET repos, this is the kind of small tool that can remove a surprising amount of guessing.
See the symbol graph, not the spelling
graphify-csharp is a headless Roslyn and MSBuild indexer for C# source code. It loads a project the way the compiler understands it, then emits deterministic relationships: callers, references, implementations, inheritance, and overrides. GitHub Copilot Workshop is part of Harness Institute.
That matters because C# names lie all the time. A method name can be overloaded. A call can bind through an interface. A generic method can look obvious in text and still resolve to a different symbol than the one an agent guessed.
The trap is treating text search as a poor person's IDE. ripgrep is still excellent for finding words fast, but it cannot answer whether SaveAsync means the repository method, the mock, the extension method, or the interface member in another project.
As of September 2026, the repository was small but concrete: mainly C#, MIT licensed, 47 GitHub stars, and last pushed on 2026-09-12. It targets C# 14 through .NET 10, with C# 15 preview support through the .NET 11 SDK. The README also calls out no required IDE, no compiled project DLL requirement, no database, and optional Graphify output.
Why Hacker News cared
The Hacker News reaction was not about a flashy agent demo. Developers cared because the project exposes something many C# users assumed should already exist as a clean command-line primitive.
Several readers had the same basic reaction: Roslyn already knows this information, so why is compiler-accurate Find Usages still mostly trapped inside full IDE experiences from Microsoft and JetBrains? That is a fair question. C# has unusually good compiler infrastructure, but agents often meet it through a terminal, not through Rider, ReSharper, or Visual Studio.
One reader adapted the idea for Unity package work, keeping graphify-csharp as an external analysis tool. That is the interesting shape here. The tool does not need to become the agent; it can sit beside the agent and answer boring semantic questions reliably.
There was also a useful objection: some agents try to inspect compiled code with reflection to find references, and that can feel painful and inefficient. graphify-csharp points at the cleaner boundary. If the question is about source relationships, ask Roslyn and MSBuild before you reach for runtime reflection.
Try it when names lie
The best first use case is impact analysis. Before Claude Code, Anthropic's coding agent, changes a C# API, ask for the exact callers, overrides, implementations, and test-only references.
A real example: you want to rename or narrow IInvoiceCalculator.Calculate. Text search may find every spelling of Calculate, but it will blur overloads and mocks together. A semantic index can show whether production code calls the interface, whether tests call a concrete fake, and whether another project implements the same member.
This is especially useful in monorepos with shared contracts, Unity projects with generated glue, and service code where tests intentionally mirror production method names. It is also a natural fit beside a Claude Code slash command: run the indexer, paste the relevant JSON evidence into the session, then ask for the patch.
The trap is using it for every tiny edit. If you are changing copy in one file, semantic indexing is ceremony. If you are touching public C# symbols, cross-project interfaces, or overloaded methods, it earns its keep.
For a broader look at how these small agent-side tools fit into review habits and codebase boundaries, see the related training topic. For a different example of developer tools becoming agent workbenches, gpty Puts Agent Terminals in Godot is a useful companion story.
Copy this Claude Code experiment
Use this as a small .claude/commands/csharp-impact.md slash-command note. It keeps the experiment narrow and makes the agent cite semantic evidence before it edits code.
# /csharp-impact
Goal: inspect the C# symbol impact before editing.
Input I will provide:
- Target symbol name and file path.
- graphify-csharp output for callers, references, implementations, inheritance, and overrides.
- The intended code change in one sentence.
Claude Code should:
- Identify the exact symbol being changed.
- Separate production callers from test callers when the project names make that clear.
- List risky overloads, interface implementations, and overrides.
- Propose the smallest patch plan.
- Ask before editing if the graph evidence is missing or ambiguous.
Do not:
- Treat grep matches as proof of usage.
- Modify public API signatures until semantic callers are reviewed.
- Assume a same-named method is the same symbol.
The important part is the refusal rule. If the graph evidence is missing, the agent should pause instead of confidently inventing a call graph.
If you later wrap this behind an MCP server, keep the first version read-only. A tool that reports symbol relationships does not need write access to the repository, package registry, or issue tracker.
Fit and non-fit cases
| Use graphify-csharp when... | Skip it when... |
|---|---|
| You are changing public C# APIs, interfaces, overrides, or overload-heavy code. | You are editing comments, strings, docs, or a single private helper. |
| The repo has multiple projects and test projects with mirrored names. | The codebase is tiny and grep already gives a complete answer. |
| The agent needs evidence before a refactor. | The task is exploratory and no code will be changed. |
| Runtime reflection would only show compiled shape, not source-level intent. | The project cannot be loaded by MSBuild in the current environment. |
This table is deliberately boring. The win is not magic autonomy. The win is giving the agent the same kind of semantic navigation a human expects from an IDE before it starts editing.
Common questions
Does graphify-csharp need Visual Studio or Rider?
No. It runs Roslyn and MSBuild headlessly from the command line. You need a .NET SDK that can load the project, but no IDE, no compiled DLL, and no database.
Is this only useful for Claude Code?
No. The output is plain JSON, so any agent that can read a file can use it. Claude Code is a natural fit because a slash command can wrap the indexer and the refusal rule in one place.
What happens when MSBuild cannot load the project?
You get no graph, and the agent should say so. That is the point of the refusal rule above. Do not let a missing index silently fall back to grep.
How does this relate to MCP?
It does not ship an MCP server today. If you wrap it in one, keep the tool read-only. Reporting symbol relationships needs no write access to anything.
Best ways to use this research
- Best for: .NET teams that let an agent refactor shared contracts, overloaded methods, or interfaces across several projects.
- Best first artifact: one
/csharp-impactslash command that requires graph evidence before any edit to a public symbol. - Best comparison angle: run the same rename with grep evidence and with graphify-csharp evidence, and count the callers each one missed.
Further reading
One methodology lens
One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.