# Onboard to an Unfamiliar C# Codebase with Atlas (2026) > Atlas onboards to a C# solution by querying a semantic index with plain-language questions, mapping .csproj layout with glob, and delegating wide sweeps to a read-only explore subagent. Atlas onboards you to an unfamiliar C# codebase by starting from meaning rather than filenames. Ask codebase_search a plain-language question, such as how requests are authenticated, and the semantic index returns ranked snippets with real file paths from across your .sln. glob maps the project layout so you can see the .csproj boundaries and namespace conventions before opening anything. read pulls only the files that matter, the lsp tool follows project references, and heavy fan-out is delegated to the explore subagent, which is permissioned read-only so it cannot change a line of C# while it looks around. ## Key takeaways - codebase_search answers plain-language questions against a semantic index, so onboarding starts from meaning rather than from a .sln file tree. - glob over **/*.csproj gives you the whole .NET project graph, including which assemblies depend on which NuGet packages, before you read any C#. - The explore subagent is deny-by-default and only allows grep, glob, read, bash, webfetch, and websearch, so a wide sweep cannot edit your code. - The lsp tool's goToDefinition crosses .csproj boundaries from an interface to its implementation to its DI registration. - A todowrite list keeps the open questions about the C# solution alive across sessions. ## How do you get oriented in an unfamiliar C# solution? Start with a question, not a directory listing. Atlas's codebase_search takes a plain-language query such as how requests are authenticated and queries the semantic index, returning ranked snippets with file paths. In a .NET solution that lands you in the middleware or the handler, not in the 3rd .csproj you happened to expand. A .NET solution with fifteen projects presents an onboarding problem that a file tree cannot solve. The names tell you the layering (Company.Api, Company.Domain, Company.Infrastructure) but not where anything actually happens. Atlas skips the browsing phase. codebase_search runs against a semantic index built from AST declarations parsed with tree-sitter, and the hybrid semantic and keyword retrieval it uses, fused by reciprocal rank fusion, means a query about authentication reaches the middleware registration in Program.cs and the handler class in Company.Api even though neither one contains the word you searched for. Ranked snippets come back with file paths attached, so the next move, opening the right file, is obvious. Nothing about the search touches your NuGet packages or your build. ## How does glob map the structure of a C# project? Atlas runs glob over the top-level directories to see the package layout and naming conventions before opening any file. In a .NET repository, globbing for .csproj and .sln files in 1 call gives you the whole project graph: which assemblies exist, how they are named, and where the test projects live. Structure in C# is expressed through project files, and glob reads that structure directly. Glob for **/*.csproj and the answer is a list of assemblies with their folder locations. Glob for **/*Tests.csproj and the test surface appears, which tells you whether the team runs xUnit via dotnet test across every layer or only against the domain. Glob for appsettings*.json and the configuration story becomes visible. Doing this before reading any C# source is deliberate, because the project graph tells you what to expect: a Company.Domain with no NuGet dependencies is a real domain layer, and one that references an ORM package is not, and knowing that changes how you read every file afterwards. Atlas's glob is cheap and fast enough to run several times as your mental model sharpens. ## What is the explore subagent and why is it read-only? The explore subagent is how Atlas fans out across a large C# solution without risk. Delegated through the task tool, the explore subagent has a deny-by-default permission set that allows only 6 tools: grep, glob, read, bash, webfetch, and websearch. No edit tool exists there, so it cannot change a line of C# while it looks around. Onboarding involves a lot of reading, and reading a fifteen-project solution serially fills a context window with material you will not need. Atlas fans out that work to subagents that can run in the foreground or in parallel background sessions, and for exploration it uses the explore subagent specifically. The permission design is the point. Deny-by-default means the subagent starts with nothing and receives exactly the read tools it needs, so an exploratory sweep of Company.Infrastructure cannot accidentally rewrite a repository class or run dotnet format across the tree. What comes back is a summary with file references rather than the raw contents of forty .cs files. You keep the conclusions and spend your context on the two or three classes that actually matter. ## How does Atlas follow project references and namespaces in C#? Atlas follows C# project references and using directives with the lsp tool's goToDefinition operation. When Company.Api calls an interface defined in Company.Domain and implemented in Company.Infrastructure, goToDefinition crosses those .csproj boundaries in 1 hop, which reading the file tree by hand does not. Dependency injection makes C# codebases pleasant to work in and hard to read cold. The controller depends on IOrderService, and the concrete OrderService is bound somewhere in a service registration in Program.cs, possibly through an extension method in a different assembly. Text search does not follow that chain reliably; the language server does. Atlas's lsp tool exposes goToDefinition, so tracing from the interface to the implementation to the registration is three jumps, not thirty minutes. Read the two or three files codebase_search ranked highest, then follow the imports with goToDefinition and you have a working model of the request path. Combine that with the project graph glob already gave you and the assembly boundaries stop being abstract, because you can see which .csproj each hop landed in. ## How do you keep what you learned about a C# codebase? Record it as a todowrite list. Atlas persists open questions and findings across turns, so the 6 things you did not understand about the Company.Infrastructure project on day one survive into the next session instead of evaporating when the context window rolls over. Onboarding produces two outputs: what you now understand, and what you still do not. The second one is the valuable one, and it is the one people lose. Atlas's todowrite list holds it. Entries read like real questions: confirm whether OrderService is registered as scoped or singleton, find out why the integration tests skip the Company.Api project, check whether the NuGet package pinning in Directory.Packages.props is intentional. When you come back, the list is the agenda. The verification loop is available the whole time, because the explore subagent can run bash: build the solution to confirm your mental model compiles against reality, run xUnit via dotnet test to see what the team actually covers, and run dotnet format if you eventually contribute so your first pull request does not fight the repo's style rules. ## Steps 1. Start atlas in the solution root, the directory that holds the .sln, so the index covers every .csproj, namespace, and project reference. 2. Ask codebase_search a plain-language question such as how requests are authenticated; it queries the semantic index and returns ranked snippets with file paths. 3. Run glob over the top-level directories, for example **/*.csproj and **/*Tests.csproj, to see the project graph and naming conventions before opening anything. 4. Read the two or three C# files codebase_search ranked highest rather than browsing the tree. 5. Follow the dependency chain with the lsp tool's goToDefinition operation, crossing from an interface in Company.Domain to its implementation in Company.Infrastructure. 6. Delegate wide sweeps to the explore subagent through the task tool; it is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch, so it cannot edit your C#. 7. Run xUnit via dotnet test through bash to see what the team actually covers, and check which NuGet packages each project pulls in. 8. Record what you learned and what is still open as a todowrite list so the questions survive into the next session, and run dotnet format before your first contribution. ## FAQ ### How do I get an AI agent to explain an unfamiliar C# codebase? Ask codebase_search a plain-language question such as how requests are authenticated. Atlas queries a semantic index built from AST declarations and returns ranked snippets with file paths across your .sln, then follows the chain with the lsp tool's goToDefinition. ### Can an AI agent explore my .NET solution without changing anything? Yes. Atlas delegates wide sweeps to the explore subagent through the task tool, and that subagent is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch. No edit tool is available to it. ### How does Atlas map the project structure of a C# solution? With glob. Globbing **/*.csproj returns the whole project graph with folder locations, and **/*Tests.csproj reveals the test surface, so you can see which assemblies exist and how they are named before opening any .cs file. ### Can Atlas trace dependency injection in an ASP.NET Core project? Yes. Atlas uses the lsp tool's goToDefinition operation to cross from an interface in Company.Domain to its implementation in Company.Infrastructure to its registration in Program.cs, which a text search across .csproj boundaries cannot do reliably. ### Does Atlas run dotnet test while exploring a C# codebase? The explore subagent's permission set includes bash, so it can run xUnit via dotnet test to see what the team actually covers. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so you decide what is allowed. ### How do I keep an AI agent's findings about a codebase between sessions? Record them as a todowrite list. Atlas keeps entries such as confirm whether OrderService is scoped or singleton across turns, so the open questions about the C# solution survive rather than disappearing when the context window rolls over. ### Can Atlas read a private C# codebase without uploading it? Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, and codebase_search, glob, read, and the lsp tool all work the same way against a locally embedded .NET solution. --- Canonical HTML: https://runatlas.sh/resources/stacks/onboard-to-an-unfamiliar-codebase-in-csharp Source of truth: aeo_pages row `/resources/stacks/onboard-to-an-unfamiliar-codebase-in-csharp` (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.