I'm not sure when I would use something like this. My VS copilot already writes one-off scripts that use Roslyn to analyze code. I don't even have to prompt it to do this with gpt5.5+
C#/.NET feels unreasonably effective as a target for LLMs. The reflection and compiler services are not found anywhere else and have profound effects that HN still seems to be taking massive naps on.
Hey man, just wanted to say thanks! I pulled this down and adapted the skill for Unity development, keeping Graphify C# as an external analysis tool. My adapted skill isn’t publicly available yet, and I'm going to add it into my standard Unity Package development workflow to see if I can find some additional value in how the CLI and structured JSON make semantic information accessible to coding agents. I think this will help (maybe not on a full Unity game) but if you'r building multiple Unity Packages or have existing Unity Packages. Appreciate you sharing this!
The tool recommends you to use this skill <https://github.com/zachsaw/graphify-csharp/blob/main/.agents...>, but I wonder if this is the right approach if one just want to use this as a consumer in a .net project. It seems very wordy, but wording like these
"Read the relevant design documents under docs/ before changing architecture."
makes me think that developing 'graphify the tool' and using 'graphify as a tool' are mixed up in the same document? How does an LLM keep track of both this gigantic skill and the user development problem at the same time?
Very good point! the graphify the tool and using graphify AS A tool have definitely beed mixed up! I'll fix this up.
Thanks again and appreciate you looking into it!
Interesting! Have you tried it on any large code bases? I have to wonder if json is going do become unwieldy at the scale of millions of LOC - a SQLite db might be a better choice.
Exactly! I'd be more than happy to hand it over to Microsoft to continue maintaining it just to be clear. But MIT licensing it, hopefully the community will help keep it up to date with future C# versions too.
(Microsoft) GitHub Copilot already builds a semantic index of your solution in a cloud cache, which is used to give higher code intelligence than what you can get from Claude Code alone or LLM interfaces which don't have native support for the Roslyn API like GitHub Copilot does.
GitHub Copilot's semantic index can work for any SaaS repo provider (GitLab, Bitbucket, etc.) or any local repos but this requires you to opt into the feature. Repos hosted in GitHub and Azure DevOps do NOT require opting into it since Microsoft already has your code.
I'm hoping Rider get some support for switching between worktrees efficiently - until then, it becomes a tool only the primary / interactive agent sessions can access.
lol I actually didn't know that. This is MIT licensed though.
EDIT: I think the differentiation is that this isn't MCP based. Dumping a portable json file allows much more flexibility than just having to run Rider IDE in the background with the solution loaded and indexed. e.g. the graph works with jq, CI (gates), arbitrary agents without MCP support, non MCP tools, bulk questions etc.
Interesting, thanks.
Seeing agents querying compiled code using reflection to find references looks painful and inefficient. Made me want to help little buddy somehow, but had no idea how
compiler accurate find usages is exactly the context coding agents keep missing. how heavy is the roslyn integration at runtime, does it index on save or on demand
It updates based on an interval that you can set as well as on demand. When file changes the file system watcher holds the events in memory until indexing is requested (interval/on-demand).
C#/.NET feels unreasonably effective as a target for LLMs. The reflection and compiler services are not found anywhere else and have profound effects that HN still seems to be taking massive naps on.
Unions coming in .NET 11 / C# 15 are going to be great.
GitHub Copilot's semantic index can work for any SaaS repo provider (GitLab, Bitbucket, etc.) or any local repos but this requires you to opt into the feature. Repos hosted in GitHub and Azure DevOps do NOT require opting into it since Microsoft already has your code.
EDIT: I think the differentiation is that this isn't MCP based. Dumping a portable json file allows much more flexibility than just having to run Rider IDE in the background with the solution loaded and indexed. e.g. the graph works with jq, CI (gates), arbitrary agents without MCP support, non MCP tools, bulk questions etc.