Repo Snapshot for AI — Hand a Project Tree to Your LLM
Paste the output of tree / find / fd to convert it into pre-formatted Markdown that is easy to pass to AI coding assistants (Claude Code / Cursor / GPT, etc.). Features include exclusion patterns, file size and line count display, grouping by file extension, depth limiting, and token count estimation.
📋 How to capture input (shell commands)
# The usual choice: tree — recommended, easiest to read tree -L 3 -I 'node_modules|.git|dist' # When tree is unavailable: find find . -type f -not -path '*/node_modules/*' -not -path '*/.git/*' | sort # The fast Rust alternative: fd fd --type f --hidden --exclude node_modules --exclude .git # Mac/Linux 標準: ls -R ls -R # Windows PowerShell Get-ChildItem -Recurse -File | Select-Object FullName
📖 Where people get stuck
Paste the output of tree or find and it applies exclusion patterns, a depth limit and a file-count limit to produce Markdown that is easy to hand to an AI, with an approximate token count. Everything runs in the browser. A file listing is material for asking where to look, not something that contains the answer — a filename tells you nothing about the contents, so handing over the structure alone and then asking a specific implementation question will not get you a precise reply.
| Case | What happens | What to do |
|---|---|---|
| The listing alone consumes the whole context | Run tree without exclusions and node_modules, .git, vendor, dist and .next come along whole, running to hundreds of thousands of tokens — enough on its own to exceed the context limit, leaving no room for the actual question and the relevant code. Even if it does fit, the situation does not improve: a mass of unrelated files dilutes what the model should attend to, and the accuracy of the answer goes down rather than up. Give it everything and it will consider everything does not hold; more information is not monotonically better. |
Set the exclusions first — node_modules, .git, dist, build, vendor and *.lock can be dropped in virtually any project without loss. More effective still is not handing over the whole tree at all: for a question about authentication, a listing of src/auth/ and src/middleware/ is enough, and narrowing the scope improves the answer as well. Setting the depth limit to two or three yields a listing that shows only how responsibilities are divided across directories — that is all you need to convey the shape of a project, and the filenames deeper down can be supplied later, once you have decided where to look. The approximate token count is shown precisely so you can make this decision before sending anything. |
| Sending only the structure and expecting a specific answer | A filename does not tell you what the file does. The contents of utils.ts are unknown, as are the methods on UserService.php. So a question like where is the cause of this bug cannot be answered from the structure alone, and what comes back is a guess along the lines of probably somewhere around here. The risk of this usage is that a guess arrives phrased as a specific assertion, which makes it easy to believe without checking — function names that do not exist, or descriptions of responsibilities that do not match the code, can find their way in. |
Use the structure to ask where to look, then supply the contents of the files that answer names — that two-step is what actually produces accurate results. Phrase the first question as something like which files should I read to follow the authentication flow, then open only the candidates that actually exist and hand over their contents. Some questions can be answered from the structure alone: which design pattern does this directory layout follow, which directories have no tests, where is the naming convention inconsistent — questions where the filenames and their arrangement are themselves the answer. Being conscious of which kind of question you are asking settles naturally whether the structure suffices or the contents are also needed. |
| The filenames themselves are the confidential part | A directory layout says a great deal without exposing any code. Names like acme-corp-migration/, 2026-q3-layoff-tool/ or client-nintendo/ contain unpublished facts in themselves. Likewise, the information that .env.production, credentials.json or id_rsa exists in the repository is useful to an attacker on its own. And the output of tree often carries a username at the head of the path — /home/tanaka/projects/... or C:\Users\yamada\... — so a personal name comes along too. |
Read the output from top to bottom before you paste it. Exclusion patterns can only remove names you already know about, so project and client names have to be found and replaced by you. In practice, running tree from the project root and stripping the leading path before pasting disposes of the username problem. Put .env*, *.pem and *credential* into the exclusions — there is rarely any need to communicate that they exist at all. And, most importantly: before handing anything to an AI, check that service policy on using your input for training, and your own organisation rules. Paid API access generally does not train on your data, but consumer services depend on the settings, and plenty of organisations forbid sending internal code outside altogether. |
How you produce the input changes the result. tree is the most readable, drawing the hierarchy with rules so that both a model and a person can follow it. Where tree is not installed, find . -type f substitutes, but that format puts a complete path on every line, so the deeper the tree the more the same strings repeat, and the more tokens it costs — with many files, installing tree works out cheaper. Using fd honours .gitignore automatically, so node_modules and its like never appear even without exclusion patterns — the least effort of the three. One operational suggestion to finish: rather than regenerating this listing every time, keeping a file that describes the structure at the project root — an ARCHITECTURE.md — pays off over time. A document with one line per directory serves equally well when handing context to an AI, when someone joins the team, and when you return to it in six months — and unlike a file listing, it can record why things are divided the way they are.
❓ Frequently Asked Questions
No tree command?
Too many files?
Privacy?
Token estimate accuracy?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.