Daniel Lyons ships Treedocs 0.2.0 to make repo maps fail when they go stale

Why it matters

Treedocs shows where AI-era developer tooling is moving: not only toward code generation, but toward small, repo-native checks that keep agents and humans grounded in current context.

Daniel Lyons (aka DandyLyons on GitHub) released Treedocs 0.2.0 on June 22, turning a familiar developer habit - keeping a mental map of a repo - into a checked, version-controlled file that can fail when it drifts from the filesystem.

This reads as an individual developer tool rather than a venture-backed product: the Treedocs project page is hosted on GitHub Pages, the repository is public, and the package documentation is published through the Swift Package Index.

That matters because Treedocs reads like a solo builder's answer to a problem that has become sharper in the agentic coding cycle: teams keep writing docs for humans, while agents spend tokens rediscovering file structure every time they enter a repo. Treedocs stores a concise description of each file and folder in treedocs.yaml, then checks that documented map against the actual tree on disk.

The project page puts the thesis plainly: Treedocs is meant to help new teammates, future maintainers, and coding agents get concise context without wandering through a codebase. That is the right target for a small CLI. Repo structure is not usually the glamorous layer of developer tooling, but it is one of the first things a human or agent needs before making a safe change.

A YAML map, not another wiki

The core move in Treedocs is deliberately plain. treedocs.yaml mirrors the repository's file tree and stores human-readable descriptions for files and folders. The CLI can render that map as a terminal tree, with current entries shown as valid and stale or invalid entries called out so drift is visible immediately.

The basic workflow is small enough to fit in a shell alias: treedocs init creates the map, treedocs sync reconciles it with the current folder structure, treedocs show . renders the documented tree, and treedocs check validates the file. The project page also lists treedocs explore . as a progressive-disclosure mode aimed at codebase exploration, including by agents.

The design choice worth watching is that the documentation lives next to the code, not in a separate knowledge base. Treedocs is not asking a team to maintain a second system of record. It asks them to commit a YAML file, review changes to it, and let automation complain when the map is stale.

That puts Treedocs closer to a contract than a README. The homepage says the CLI can warn or fail CI-style checks when the tree is stale or descriptions are missing, and you can install a Git pre-commit hook so you never commit undocumented changes.

For teams using AI coding tools, that is the useful part. The YAML map becomes a small, reviewable context object. An agent can fill in short descriptions, according to the project page, but treedocs check is the mechanism that keeps the result tied to the filesystem rather than letting it become another abandoned note.

What changed in 0.2.0

Version 0.2.0 is mostly a schema and compatibility release, not a distribution breakthrough. It publishes the canonical treedocs.yaml schema at 0.2.0 (with a latest schema endpoint), and keeps distribution source-only through SwiftPM-backed tooling. The release notes say no prebuilt artifacts are included.

The schema changes are practical. Treedocs 0.2.0 improves IntelliSense hints for editors such as VS Code, renames object metadata keys from description and references to _description and _references, keeps compact string descriptions unchanged, and reserves underscore-prefixed keys inside the tree object for Treedocs metadata. That reserves more room for actual filesystem entries named description or references without colliding with Treedocs' own metadata.

Lyons also kept a migration path. The release notes say the 0.2.0 CLI can still read, validate, sync, and update files using schema_version: "0.1.0", while warning that 0.1.0 files are deprecated and pointing users to a migration document. They also note swift build passed, swift test passed with 111 tests, treedocs check passed, and a fresh treedocs init --non-interactive now writes schema_version: 0.2.0.

A Swift tool with Apple-shaped constraints

Treedocs is also constrained by its implementation choices. The package manifest uses Swift tools version 6.0 and the homepage lists macOS 13+ as the supported platform. Installation through Homebrew, Mint, or mise requires a Swift 6-capable build environment, usually Xcode 16 or newer.

That narrows Treedocs' immediate audience. Documentation drift is not a macOS-only problem, but Treedocs is currently most accessible to developers already inside the Apple and Swift ecosystem. The source-only distribution reinforces that. The project page says Homebrew installs through the DandyLyons tap, Mint builds the Swift executable package from tagged source, and mise uses its experimental Swift Package Manager backend when installed with MISE_EXPERIMENTAL=true.

The broader pattern: local tools for AI-era code review

Treedocs fits a pattern that has been showing up in small developer tools: builders are not only trying to generate more code with AI, they are building guardrails around the code and the review process. AISlop ships a CLI and GitHub Action to catch AI-generated code smells. Codiff gives developers a local Git diff reviewer with an AI walkthrough. Treedocs tackles an earlier step: giving both humans and agents a current map before the change begins.

The common thread is locality. These tools live in the repo, the terminal, the Git hook, or the local review loop. They do not require a team to buy a full platform before getting value. That is why small projects like Treedocs are worth watching even when there is no funding round, no user count, and no commercialization plan.

There are still open product questions. Treedocs does not disclose any revenue model in the public materials, the sources do not establish a company behind it, and cross-platform support beyond macOS is not documented yet.

Those gaps are not fatal for a v0.2.0 developer tool. They simply define the stage. Treedocs is a small, opinionated CLI for people who already believe repo context should be committed, checked, and reviewed. If coding agents are going to work safely in larger codebases, that kind of context cannot live only in memory, stale wiki pages, or one senior engineer's head.