[DandyLyons]

Hi HN,

I built treedocs, a CLI that shows a tree of your file structure, side-by-side with docs.

The idea is simple: your filesystem already tells you what exists, but not what each path is for. treedocs mirrors the file tree into a treedocs.yaml file and lets you define short descriptions, references, and links to files and folders. It can then render that back as a documented tree, detect drift when files move or disappear, and fail checks when descriptions are missing.

I originally wanted this for two related problems: 1. Helping humans acclimate to unfamiliar repositories faster. 2. Giving coding agents concise project context without forcing them to rediscover the repo structure over and over.

Some things it does: - treedocs init creates a treedocs.yaml - treedocs sync reconciles it with the filesystem - treedocs check catches stale entries and missing descriptions - treedocs explore implements progressive disclosure for efficient token usage. - Nested treedocs.yaml files act as documentation boundaries for delegated subtrees - The YAML format is backed by a public JSON Schema

I’d be interested in feedback on the file format, CLI ergonomics, and whether this kind of repo-level map is useful for your workflows.

[gritzko]

The question is who maintains it. I think, LLM is the only practical option. In my agent rules, I tell it to maintain INDEX.md on each level. That takes 1 line of instruction and starting with an example file. Then, it self-maintains.

[DandyLyons]

In practice, the LLM, treedocs and I all work together to maintain it. treedocs finds missing and extra paths, and missing descriptions. The LLM writes descriptions. git makes sure I never forget to run treedocs sync. And I always have the ability to easily correct incorrect descriptions by the LLM, or add my own special instructions.

Sure the LLM can do all of that but it's a waste of a lot of tokens, and in my experience it often makes incorrect assumptions or doesn't realize certain details.

[tekacs]

This is lovely! I'd done something similar in my own setup.

I'm curious what your experience has been with fork/merge – why a monolithic file rather than something more diffuse?

[DandyLyons]

treedocs already has the ability to read multiple treedocs.yaml files. (I should probably document this better.) treedocs.yaml files can be "nested". So you would have one at the top of your repo, and then you could optionally have one or more in subdirectories. Then your top treedocs.yaml is responsible for the repo, but the subdirectory treedocs.yaml files are responsible for their own subdirectory. The idea is that you might have situations where you install a dependency and it clones a subdirectory. Well that subdirectory could just define its own treedocs.yaml.

So it doesn't have to be monolithic.