repo-intel-search

name	repo-intel-search
description	Use the repo-intel MCP tools to answer questions about THIS repository's code — what depends on a symbol, who calls it, where it is defined, where behaviour lives, and what the module layout is. Prefer them over grep/glob for any of those questions.

Answering questions about this repository with repo-intel

Five tools over a local index and a compiler-grade semantic graph. The graph tools answer questions grep cannot express at all.

The graph tools — prefer these for structural questions

impact_of — what breaks if this changes. Input { "symbol": "<name>", "depth": 2 }. Returns the symbol's actuals, its dependents to a bounded depth, the downstream modules, and any implementation outside the indexed scope. The answer always states the depth applied and how many results were elided. There is no way to ask this question with a text search.

who_calls — every call and reference site, each at its own file:line, qualified by source set, and including callers in other modules and callers of an expect's actuals. Input { "symbol": "<name>", "module": "<optional>", "sourceSet": "<optional>" }.

find_symbol — where a symbol is defined: the declaration, its compiler-bound actuals, and any actual outside the indexed scope. Input { "symbol": "<name>" }.

Batch these. Asking find_symbol and then who_calls for the same symbol in two separate turns costs a whole extra round trip for an answer the graph could have given at once.

The retrieval tools

search_code — hybrid keyword + semantic search over declaration-aware chunks. Input { "query": "<what you are looking for>", "k": 10, "lane": "fused", "rerank": true }.

repo_map — a token-budgeted module → file → declaration outline. Input { "token_budget": 1200, "module": "<optional>" }.

Reading the response

Every response carries index_state: lanes_available (which of lexical/dense/rerank actually served THIS response), stale, fresh_as_of_commit, and for graph answers graph_status. Read them. If stale is true the working tree moved since indexing and line numbers are approximate. If a lane you expected is absent, it did not run — the response is honest about it rather than silently degraded.

A genuine failure is an MCP protocol error carrying {code, message}. A degradation — no dense lane, a partial graph, an empty result — is a normal result with an honest index_state.