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.

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, 27 GitHub stars, and last pushed on 2026-09-11. It also calls out C# 15 syntax support, 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

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.

Try the narrow version first

Pick one risky C# symbol, generate semantic usage evidence, and ask your agent to explain the impact before editing. If the answer catches one overload or test-only usage that grep blurred, graphify-csharp has already paid for the experiment.

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.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “graphify-csharp Gives Agents C# Find Usages.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• graphify-csharp — source
• Claude — Agent
• Model Context Protocol — specification
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.