vela
Compiler-exact code search, in any language you index
Where a symbol is defined, every reference, who calls it and what implements it, in about a second. It speaks SCIP, the standard interchange format for a code index, so one set of verbs answers across a whole repository: it indexes .NET itself through Roslyn - including Razor views and Blazor components, with every reference the compiler resolves saved to an index you query with no server running - and reads any other language's SCIP index into the same database. The answers are what a compiler believes rather than what a regex matched, and 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
Razor and Blazor references, resolved and saved
Razor views and Blazor components never exist as files the compiler reads - they arrive as source-generated documents, so a tool that iterates the files on disk skips them, and Sourcegraph's own Roslyn-based indexer is one of those. That gap was measured at 334 views and 62,358 lines of one presentation layer, invisible. csharp-ls and the Roslyn language server reach Razor, but only from a server that has to be running, and CodeGraph matches it by pattern. vela is the only tool DBHQ knows of that writes compiler-resolved Razor and Blazor references into a saved index you can query with no server running. A Blazor component used by its tag is reported against its .razor file with no line, because the Razor compiler records none.
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. An edit to a file an imported index names raises the same stale warning as an edit to C#, and a repository with no .NET in it can be indexed from imports alone.
What implements an interface, and answers that fit
impls lists what implements or overrides a symbol, in C# and Visual Basic. impact names the direct callers and says how many references have no caller to name, such as those in a Razor view, so nothing is left out quietly. On a common name, --files gives a count per file and --limit prints fewer rows without changing the total.
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.
It indexes .NET itself, and imports the rest
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 needs the .NET SDK 10.0 or newer, the solution has to build, and vela does not restore it for you. The plugin install carries the skill only: the vela command comes from the repository's own installer.
It does not sandbox the build it indexes
Indexing evaluates the solution with MSBuild and runs its source generators, as dotnet build does, and those are code from the repository and its packages. So indexing a repository runs that code on your machine: index only code you would build. Importing a .scip file runs nothing from it.
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.