Vela
Compiler-exact code search for .NET
Where a symbol is defined, every reference, who calls it, and what a change breaks, answered from Roslyn in about a second. So it is what the compiler believes rather than what a regex matched, and Razor views and Blazor components are indexed rather than skipped. If a project fails to load, it says so.
Install Vela
Add the DBHQ marketplace, once
/plugin marketplace add dbhq-uk/marketplaceInstall the skill
/plugin install vela@dbhq
Both commands work in Claude Code and in Codex. The marketplace is a public repository you can read first: dbhq-uk/marketplace (external site)
What it is good at
Indexing Razor and Blazor, which almost nothing else does
Razor views and Blazor components never exist as files the compiler reads - they arrive as source-generated documents. Every general-purpose code-intelligence tool iterates the files on disk and therefore skips them, including Sourcegraph's own Roslyn-based indexer. Vela reads the compilation instead of the directory, so they are simply there. That gap was measured at 334 views and 62,358 lines of one presentation layer, invisible.
Ordinary identifiers, where grep gives up
Measured on 30 July 2026 against a real ten-project solution of 388,323 lines of C#, references to one Status property returned 24 results where grep on Status matched 2,257 lines. That is 1.1% precision if you grep it. The same measurement on a Name property came out at 6.6%.
Being deterministic, and only deterministic
No model calls, no API key, no network. Every answer follows from the compiler's semantic model, so there is nothing to triage and nothing to second-guess.
Not staying resident
Index once, then query a SQLite file. A language server held open costs about a gigabyte per project; this costs a file on disk. Loading the same solution into a live Roslyn workspace costs over thirty seconds, and costs it on every invocation.
Merging in another language's index
A real TypeScript SCIP index imports beside the C# one and both answer from a single database, so a polyglot solution does not need two tools and two mental models.
What it does not do
It does not replace grep
For a distinctive identifier grep returns a screenful and needs no index at all. Vela earns its keep on the ordinary names, and on the questions grep cannot answer at any precision - who calls this, and what breaks if it changes.
It says so when it does not know
A tool that silently returns partial results is worse than grep, because you believe it. If a project fails to load, every query that touches it says so and the exit code reflects it. Absence of results is never reported as evidence of absence.
It does not edit, refactor or rename
It reports, and that is the whole scope. Nothing in it writes to your repository, renames a symbol or applies a refactor - answers come back as a file, a line and a column you open yourself.
F# is out of scope
Roslyn covers C# and Visual Basic, plus anything a source generator emits into those compilations. F# has its own compiler. Everything else has to reach the index through an import.
It is not milliseconds, and the index is not free
Roughly half a second for a definition and about 1.3 seconds for a reference set of three thousand results, over a 0.09-second process floor. Indexing that ten-project solution took about five minutes at 2.1GB peak. It also needs the .NET SDK 10.0 or newer, and the solution has to build.
Read it before you install it
Every line is public and MIT licensed. The README is the long version of this page, including the parts that are still rough.