Documentation
RepoQL, end to end
A structural index of your code — every file, symbol, and relationship already parsed — that your agent queries instead of reading. You do not drive it. You ask for what you want, in the sentence you would have used anyway, and it reaches for whatever it needs.
Here is one real exchange, start to finish, with nothing removed but length.
“how does gitignore matching work in this repo?”
What it reached for — no tool was named to it
keywords “gitignore, ignore rules, exclusion patterns, skip files”
read design.md;design-native-matcher.md => content
read GitIgnoreMatcher.cs;LayeredFileFilter.cs;PatternTransformer.cs => structure
read LayeredFileFilter.cs#symbol=IncludeNormalizedPath;#symbol=ShouldDescend
… seven calls, no file opened at random
What came back
Three layers, one native matcher. Every path decision is three checks in fixed order — and the answer arrived with the line numbers to check it against:
It went on through the pattern rewriting, the two-pointer matcher that replaced a regex library, the divergences from git that are pinned deliberately in tests — and then closed with something nobody asked for: one of the design documents it had just read has gone stale, naming the two claims in it that the code no longer honours.
That is the whole interface. Everything below is the vocabulary behind that exchange — worth knowing when you want to steer, never required to start. Read it in any order; nothing here depends on anything else here.
Where it runs
On your machine beside your IDE, in a container, or on your own infrastructure where a team and its agents share one warm index. Indexing, search, SQL, and git work with no network at all — a cloud account buys better embeddings and reranking, not the ability to run.
Addressing
Everything RepoQL indexes has a URI — a file, a single symbol, a line range, a repository you imported, the manual inside the binary. Globs widen the address, fragments narrow it, and a modifier decides what comes back. That one grammar is what makes ten tools feel like one.
Your data
A full accounting of what we receive and what we store — what passes through in memory and is discarded, every field of a usage record with a real sample, and the one-line opt-out. Kept in step with the software; a mismatch is a bug.
Bringing more in
A GitHub repository, any git remote, an S3 bucket, a folder on disk, a SARIF report from your linter. Once imported it answers to the same addresses and the same tools as your own code — so you can trace a call out of your service and into the library it depends on without leaving the question.
The tools
Ten, each under the name it answers to. Every one is a door to its own page.
| explore | Search by meaning across the whole index, ranked by how well each result answers your question. The first call teaches you the repository’s real vocabulary. |
| keywords | Your rough words mapped to the names this codebase actually uses, with evidence. Reach for it when a search comes back weak. |
| read | Retrieve exactly one slice by address — a symbol, a line range, a glob — and choose what comes back with a modifier. |
| query | DuckDB SQL over the whole graph: files, symbols, git history, parsed data, and connected MCP servers, in one statement. |
| explain | A synthesized answer with citations, read from far more source than you would spend context on yourself. |
| import | Pull another repository, an S3 bucket, a local folder, or a SARIF report into the same graph and the same addresses. |
| execute | Sandboxed JavaScript for the shape SQL cannot express — loops, branching, diagrams, files written back. |
| watch | Run a process under an OTEL collector; its traces, logs, metrics, and resource use become tables you can query. |
| capture_concept | Write an invariant into the repository’s own memory, so the next session inherits what this one learned. |
| command | Manage the host — status, configuration, imports, accounts, diagnostics. |
What people do with it
Three tasks carried from cold start to answer.
| An unfamiliar codebase | Land in a repository you have never seen and get to the code that matters, without opening files at random. |
| Profiling with watch | Run an application under RepoQL, then query its telemetry beside the code that produced it. |
| Keeping what you learn | Turn an expensive lesson into something the next session inherits automatically. |
Not installed yet? One line, on your machine. — and once it is,
the full manual ships inside the binary at help:///, where your agent can read it
the same way it reads your code.