Tool

explore

Find the files and symbols that are likely to help answer a question, even when you do not know their names.

explore searches both the words in the index and their meaning. It returns ranked locations with enough context to decide what to read next. This is useful when you know the behaviour you are looking for, but do not know which part of the repository implements it.

Give the search a question and a scope

Search terms identify the subject: a feature, a class name, or a short phrase. A question explains what you want to learn about it. “Authentication” could mean configuration, token validation, or a login failure; the question helps distinguish those results when reranking is available.

The scope selects the repositories or directories to search. Start with your workspace when the question is about your code. Include an imported dependency when its implementation matters. Searching everything at once can return useful-looking answers from the wrong project.

Read the results as leads

Each result names an indexed location and describes it with a headline, signatures, or a snippet. Follow the relevant addresses with read to check the implementation. A relevance score measures the match to your search; it does not establish that a result implements the behaviour or that the search found every relevant file.

If results are weak, try discover_vocabulary to find the names this repository uses. Also check the scope and the index status in the response. A search made while indexing is incomplete can miss files that have not arrived yet.

Choose how much context to return

The token budget limits the response size. With a small budget, results tend to be short descriptions; a larger budget allows more signatures and source snippets. Narrowing the scope can make the same budget more useful.

breadth controls how widely the search and its context are spread. Lower values concentrate on stronger candidates; higher values give a wider survey. It is not a maximum result count. Leave it at the automatic setting unless you need to steer that trade-off.

Example: locate an implementation

This searches the engine in RepoQL’s own repository. It can return the matcher, its tests, and design notes. Read the implementation before deciding which document describes the current behaviour.

Terminal

rql explore "gitignore matching" --question "where is gitignore matching implemented?" \
  --uri-glob "src/L1/engine/**" --token-budget 700

Parameters

Further reference

In the installed manual: help:///tools/explore.md.