how do I write a README that matches what the code actually does

Have Atlas enumerate the exports with the lsp tool's documentSymbol operation, read each implementation, and check real usage with codebase_search. Atlas writes docs from source, not from memory, so every claim in the README traces to a file it just read.

how do I list every exported function in a module?

Run the lsp tool's documentSymbol operation in Atlas. It reads the symbol table the language server built from the real file, so it cannot miss an export nobody remembered or invent one the model expects to be there.

why does Atlas search for callers when writing documentation?

A signature tells you what a function accepts, and callsites tell you what it is for. Atlas uses codebase_search to find how callers actually use the module in practice, so the README's usage example shows the real pattern rather than the bare signature.

should every README in a repo use the same format?

Yes. Atlas greps the repo for an existing README and matches its heading structure and tone rather than inventing a new format. Consistent structure means a reader who needs the install step knows where to look before opening the file.

do I need to test the code samples in my documentation?

Yes. Atlas verifies every code sample by running it with bash, because a sample that was never executed is a liability. A broken example imports a moved module or omits a required argument, reads perfectly, and costs the next developer more time than no example would.

how does Atlas avoid documenting functions that do not exist?

By deriving the export list from the language server rather than from expectation. The lsp tool's documentSymbol operation returns the symbol table for the real file, so a function the model merely believes should exist never reaches the README's table of contents.

Document a Module with a README Using Atlas (2026 Workflow)

To produce documentation that describes what the code actually does today, not what it was supposed to do a year ago, have Atlas write the docs from source rather than from memory. Atlas enumerates the module's public API with the lsp tool's documentSymbol operation so no export is missed or invented, reads the implementation of each export, and uses codebase_search to find how callers actually use it in practice. Atlas greps the repo for an existing README to match heading structure and tone rather than inventing a new format, writes the README with the write tool quoting real signatures and real file paths, and verifies every code sample by running it with bash.

How do I generate a README from source code with Atlas?

Atlas documents a module in 5 steps: the lsp tool's documentSymbol enumerates the real exported surface, read supplies the behavior, codebase_search shows how callers actually use the module, grep finds an existing README to match, and write emits the new one.

Documentation written from memory is documentation that describes an intention. Documentation written from source describes a program. Atlas writes docs from source, not from memory, and the ordering enforces that: the export list comes from the language server before a single sentence is drafted, and the behavior descriptions come from files Atlas has just read. Because every claim comes from a file Atlas just read, the doc is traceable rather than plausible, which is the only property that makes a README worth trusting a year from now.

How does the lsp tool's documentSymbol find a module's public API?

Atlas enumerates the module's public API with the lsp tool's documentSymbol operation, so no export is missed or invented. documentSymbol reads the symbol table the language server built from the real file, which is why a README written this way in 2026 cannot quietly document a function that no longer exists.

Two failure modes plague generated docs, and documentSymbol closes both. The first is omission: an export nobody remembered, undocumented for three years, still called by two services. The second is invention: a function the model believes should exist because similar modules have one. A symbol table has neither problem, because it is derived from the file rather than from an expectation about the file. The export list documentSymbol returns is the table of contents for the README, before any prose is written.

Why does Atlas use codebase_search when documenting a module?

Atlas uses codebase_search to find how callers actually use a module in practice, because a signature tells you what a function accepts while its 20 callsites tell you what it is for. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so codebase_search surfaces calling patterns a signature alone never reveals.

If 9 of 10 callers pass the same option and wrap the result in the same retry, that pattern belongs in the README as the usage example, and the bare signature does not. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so a codebase_search hit comes back as a whole calling function with enough context to see the pattern rather than as a stray line.

Should a new README match the existing docs in the repo?

Yes. Atlas greps the repo for an existing README to match heading structure and tone rather than inventing a new format. A repository with 14 modules and 14 different README shapes is harder to read than one with a boring shape repeated 14 times, because a reader has to relearn the layout each time.

Consistency is a documentation feature, not a stylistic preference. When every README in a repository opens with the same sections in the same order, a reader who needs the install step knows where to look before opening the file. Atlas greps for the existing README, matches its heading structure and its tone, and puts the new module's content into that shape. Inventing a new format for one module makes that module's docs slightly nicer and the repository's docs meaningfully worse.

How does the write tool create the README, and where do I approve it?

Atlas writes the README with the write tool, quoting real signatures and real file paths. The write tool is permission-gated like every Atlas tool call, checked against 3 rule types, allow, ask, and deny, before it runs, and Atlas computes a unified diff and surfaces it for approval before the README is created.

The approval point is the diff. Read it looking for exactly one thing: whether every signature and every path in the README came from a file Atlas actually read. A signature that does not match the source is not a typo, it is a documentation bug that will outlive the person who introduced it. Quoting real file paths matters for the same reason, since a path that points nowhere teaches the next reader to distrust the whole document. Reject the write and re-scope it if anything looks invented.

How do I verify the code samples in a README are correct?

Atlas verifies every code sample in the doc by running it with bash. A sample that was never executed is a liability, because a broken example in a README costs the next developer more time than no example at all would have, and in 2026 it is the first thing they will copy.

Running the samples is the step teams skip and the step that decides whether the README is trustworthy. An example that imports a moved module, calls a renamed option, or omits a now-required argument fails immediately when executed and looks completely fine when read. Atlas runs each sample with bash, which is permission-gated before it runs, and fixes any that fail before the README is considered done. A verified sample is a claim the reader can act on.

Step by step

01Enumerate the module's public API with the lsp tool's documentSymbol operation so no export is missed or invented.
02Read the implementation of each export with the read tool, so the behavior described in the README comes from the source rather than from memory.
03Use codebase_search to find how callers actually use the module in practice, since the real usage pattern is what belongs in the example.
04Grep the repo for an existing README and match its heading structure and tone rather than inventing a new format.
05Write the README with the write tool, quoting real signatures and real file paths, and approve the unified diff Atlas surfaces before the file is created.
06Verify every code sample by running it with bash, and fix any sample that fails, because a sample that was never executed is a liability.

Frequently asked questions

how do I write a README that matches what the code actually does: Have Atlas enumerate the exports with the lsp tool's documentSymbol operation, read each implementation, and check real usage with codebase_search. Atlas writes docs from source, not from memory, so every claim in the README traces to a file it just read.
how do I list every exported function in a module?: Run the lsp tool's documentSymbol operation in Atlas. It reads the symbol table the language server built from the real file, so it cannot miss an export nobody remembered or invent one the model expects to be there.
why does Atlas search for callers when writing documentation?: A signature tells you what a function accepts, and callsites tell you what it is for. Atlas uses codebase_search to find how callers actually use the module in practice, so the README's usage example shows the real pattern rather than the bare signature.
should every README in a repo use the same format?: Yes. Atlas greps the repo for an existing README and matches its heading structure and tone rather than inventing a new format. Consistent structure means a reader who needs the install step knows where to look before opening the file.
do I need to test the code samples in my documentation?: Yes. Atlas verifies every code sample by running it with bash, because a sample that was never executed is a liability. A broken example imports a moved module or omits a required argument, reads perfectly, and costs the next developer more time than no example would.
does Atlas ask before creating a README file?: Yes. The write tool is permission-gated against allow, ask, and deny rules like every Atlas tool call, and Atlas computes a unified diff and surfaces it for approval before the file is created. Review the diff for any signature or path that did not come from the source.
how does Atlas avoid documenting functions that do not exist?: By deriving the export list from the language server rather than from expectation. The lsp tool's documentSymbol operation returns the symbol table for the real file, so a function the model merely believes should exist never reaches the README's table of contents.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Document a Module with a README in Unity with Atlas in 2026

Generate accurate README documentation for your Unity C# modules in 2026 using Atlas. Ensure docs reflect current code behavior, not outdated plans, leveraging Unity's toolchain.

Document a Fiber Module with a README using Atlas in 2026

In 2026, Fiber developers use Atlas to generate accurate READMEs for their modules. Atlas reads your app.Group routes and fiber.Ctx handlers, ensuring documentation reflects current code, not outdated plans. Get precise

Document an Elixir Module with a README in 2026 using Atlas

Generate accurate, up-to-date README documentation for your Elixir modules with Atlas. Leverage Mix, Hex, and ExUnit for verified, traceable docs.

Document a module with a README in PowerShell with Atlas in 2026

In 2026, Atlas helps PowerShell developers generate accurate README documentation directly from module source code. It leverages lsp for API enumeration, read for implementation details, and bash for verification

Document a FastAPI Module with a README in 2026

Learn how Atlas, the terminal-native AI coding agent, helps FastAPI developers in 2026 generate accurate, up-to-date README documentation directly from their codebase, using real tools like pytest and uv.

Document a module with a README in Lua with Atlas in 2026

Generate accurate README documentation for your Lua modules in 2026 using Atlas. Leverage `luarocks`, `busted`, and `stylua` to describe what your code actually does today, not what it was supposed to do a year ago.

Document a Go Module with a README Using Atlas (2026)

Atlas writes a Go module README from source in 2026: documentSymbol enumerates the exported API, codebase_search finds real callers, and go test verifies samples.

Document an Apache Airflow Module with a README in 2026 using Atlas

For Apache Airflow developers in 2026, Atlas generates accurate READMEs for modules by analyzing live code, ensuring documentation reflects current behavior, not outdated plans. It integrates with `pytest (DagBag)` and

Browse this resource hub