# Locate Where a Behavior Is Implemented in Dart with Atlas (2026) > Atlas locates Dart code three ways at once: codebase_search for meaning, grep through ripgrep for exact text, and the lsp tool for the symbol graph in lib/. 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. ## Key takeaways - Atlas attacks Dart code location three ways at once: codebase_search for meaning, grep for exact text, the lsp tool for the symbol graph. - codebase_search returns candidate declarations in lib/ even when your words never appear in the .dart source. - Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so scoping to *.dart is fast. - The read tool fails loudly with File not found and a Did you mean list, so a wrong path in a deep lib/src/ tree never passes silently. - The lsp tool's findReferences answers reachability across a pub package; workspaceSymbol jumps to a declaration by name. - Every step is read-only and permission-gated, so locating behavior in a Dart package changes nothing in it. ## 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. ## Steps 1. Run atlas in a package with a pubspec.yaml and let Atlas read your libraries, pub dependencies, and analysis options. 2. Describe 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. 3. Confirm 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/. 4. Open 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. 5. Use the lsp tool's findReferences operation on the Dart symbol to see every callsite the analyzer knows about across the pub package. 6. Use the lsp tool's workspaceSymbol operation to jump to a declaration by name when you know the symbol but not the file. 7. Have Atlas summarize the call path back to you with concrete file and line references you can open and verify. 8. Run dart test against the file you located to confirm your understanding, and run dart format only if you end up editing it. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/locate-where-a-behavior-is-implemented-in-dart Source of truth: aeo_pages row `/resources/stacks/locate-where-a-behavior-is-implemented-in-dart` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.