To locate where a behavior is implemented in Dart with Atlas, describe the behavior to codebase_search rather than guessing at a class name. Finding code is a retrieval problem, and Atlas attacks it from three angles at once: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. Describe what the software does, and the semantic index returns candidate declarations in lib/ even when your words never appear in the Dart source. Confirm with grep, which takes a real regex plus include and path filters and runs through ripgrep, then open the best candidate with read and walk the callsites with the lsp tool's findReferences operation.
How do I find Dart code when I do not know what it is called?
Describe the behavior to Atlas's codebase_search. The semantic index returns ranked Dart declarations from lib/, the top 5 or so, even when your words never appear in the source. You know the app debounces a search field, but nobody named the file debounce.dart.
The hardest search is the one where you know the effect and not the vocabulary. Atlas's codebase_search takes a plain-language description of the behavior and queries the semantic index, returning ranked snippets with file paths. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a query hits both by meaning and by any literal terms that happen to match. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so the results come back as real Dart declarations, a class, a method, an extension, rather than arbitrary chunks of a .dart file that happen to score well.
How does grep confirm a codebase_search hit in a Dart package?
Atlas confirms a codebase_search hit with grep, which takes a real regex plus include and path filters and runs through ripgrep. Semantic search proposes a candidate in lib/src/, and a regex scoped to *.dart proves in 1 pass whether the exact identifier appears there and nowhere else.
Semantic search is a ranking, not a proof. Once codebase_search names a candidate, Atlas greps for the exact identifier to establish the ground truth: how many times it occurs, in which .dart files, and whether the hits cluster in lib/ or leak into test/ and example/. The grep tool takes a real regex, not a substring, plus include and path filters, and runs through ripgrep, so scoping the search to *.dart across a pub package is fast even on a large repo. The two tools are complementary, which is exactly why Atlas ships both rather than one fuzzy search box.
What happens if Atlas reads the wrong Dart file path?
Atlas's read tool fails loudly on a wrong path: File not found, plus a Did you mean list of near matches. In a Dart package with 200 files under lib/src/, a guess at search_field.dart that does not exist produces an error and suggestions, not silence, so a bad path never goes unnoticed.
Silent failure is the enemy of a search. If Atlas opens the best candidate with read and the path is wrong, whether from a stale memory of the package layout or a typo in a nested lib/src/ directory, the tool reports File not found and returns a Did you mean list of near matches. That behavior turns a dead end into a redirect. Dart packages have deep and repetitive directory structures under lib/src/, where several files share a name across feature folders, and the suggestion list is often exactly what tells you which one you actually wanted.
How do I find every callsite of a Dart symbol?
Atlas uses 2 lsp operations on a Dart symbol: findReferences to see every callsite, and workspaceSymbol to jump straight to a declaration by name. The Dart analyzer knows null-safe types and imports across a pub package, so it finds callers a text search over lib/ would miss.
Once the implementation is located, the next question is who reaches it. Atlas runs the lsp tool's findReferences operation on the Dart symbol, and the analyzer returns every callsite across the package, including calls through an interface and calls in files whose import you never inspected. workspaceSymbol works the other direction: give it the name and it jumps to the declaration without a path. The lsp tool is the third angle alongside codebase_search and grep, and it is the one that answers reachability rather than existence, which is what you need before you change anything.
How does Atlas explain what it found in a Dart codebase?
Atlas summarizes the call path back to you with concrete file and line references, not a vague description. A useful answer names lib/src/search/search_controller.dart and line 84, so you can open it in your editor and run dart test against it immediately.
The output of a location workflow is a map, and a map without coordinates is a story. Atlas reports the Dart file and line for each step of the path it reconstructed, from the widget that triggered the behavior down to the method in lib/src/ that implements it. Concrete references are what let you verify the answer instead of trusting it. The search itself is safe by construction: codebase_search, grep, read, and the lsp tool are all read-only, and every Atlas tool call is permission-gated against allow, ask, and deny rules, so exploring a Dart package changes nothing in it.
Step by step
- 01Run atlas in a package with a pubspec.yaml and let Atlas read your libraries, pub dependencies, and analysis options.
- 02Describe the behavior to codebase_search in plain language; the semantic index returns candidate Dart declarations even when your words do not appear in the source.
- 03Confirm the candidate with grep, which takes a real regex plus include and path filters and runs through ripgrep, scoping the search to *.dart under lib/.
- 04Open the best candidate with the read tool; a wrong guess fails loudly with File not found plus a Did you mean list, so bad paths do not go unnoticed.
- 05Use the lsp tool's findReferences operation on the Dart symbol to see every callsite the analyzer knows about across the pub package.
- 06Use the lsp tool's workspaceSymbol operation to jump to a declaration by name when you know the symbol but not the file.
- 07Have Atlas summarize the call path back to you with concrete file and line references you can open and verify.
- 08Run dart test against the file you located to confirm your understanding, and run dart format only if you end up editing it.
Frequently asked questions
- how to find where a feature is implemented in a dart codebase
- Describe the behavior to Atlas's codebase_search in plain language. The semantic index returns candidate Dart declarations in lib/ even when your words never appear in the source, then confirm the hit with grep and open it with read.
- codebase_search vs grep in atlas which should i use for dart
- Use both. codebase_search finds Dart code by meaning when you do not know the symbol name, and grep, which takes a real regex plus include and path filters through ripgrep, proves exactly where an identifier occurs in your .dart files.
- atlas says file not found did you mean
- The read tool validates the path and, when it is wrong, returns File not found plus a Did you mean list of near matches. In a Dart package with repeated filenames across lib/src/ feature folders, that suggestion list usually names the file you actually wanted.
- how do i find every caller of a dart method
- Use the lsp tool's findReferences operation through Atlas. The Dart analyzer returns every callsite across the pub package, including calls through an interface and calls in files whose imports you never inspected.
- how do i jump to a dart declaration when i only know the name
- Use the lsp tool's workspaceSymbol operation through Atlas. Give it the symbol name and it resolves to the declaration without you supplying a path, which is faster than guessing at a location under lib/src/.
- will atlas change my dart code while exploring it
- No. codebase_search, grep, read, and the lsp tool are all read-only, and every Atlas tool call is permission-gated against allow, ask, and deny rules, so locating a behavior in a pub package changes nothing on disk.
- how do i set up atlas in a dart project
- Run atlas in a package with a pubspec.yaml and let Atlas read your libraries, pub dependencies, and analysis options. From there you can ask it to migrate to null safety or add tests, reviewing the diff each time.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Locate Where a Behavior Is Implemented with Atlas in 2026
How to locate where a behavior is implemented with Atlas in 2026: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph.
Atlas for Dart in 2026
Adopt Atlas, the terminal-native AI coding agent, for Dart development in 2026. Enhance productivity with intelligent code search, refactoring, and robust safety features across your Dart projects.
Extract a Shared Helper from Duplicated Dart Code with Atlas in 2026
Refactor duplicated Dart code into a shared helper using Atlas. Leverage semantic search, reviewable patches, and integrate with `dart test` and `pub` for safe, efficient code consolidation.
Trace a runtime bug from a stack trace in Dart with Atlas in 2026
Pinpoint and fix Dart runtime bugs from production stack traces without a debugger using Atlas. Leverage `pub`, `dart test`, and `lsp` for rapid resolution.
Audit a Dart Repo with Parallel Subagents in 2026 using Atlas
Sweep your Dart repository for specific problems without overwhelming your main session. Atlas uses parallel subagents to audit Dart code, managing pub packages and null-safe libraries efficiently.
Automate GitHub issue and pull request triage in Dart with Atlas in 2026
Automate GitHub issue and pull request triage for your Dart projects with Atlas. Safely respond to events, manage dependencies with `pub`, and ensure code quality with `dart format`.
Review a Pull Request in Dart with Atlas in 2026
In 2026, Atlas helps Dart developers review pull requests by providing deep context, running `dart test`, and checking `pub` dependencies to catch subtle bugs.
Debug a Single Failing Test in Dart with Atlas (2026)
Debug one failing Dart test with Atlas in 2026: isolate it with dart test, walk the call path with the lsp tool, and fix the code rather than the assertion.