Understand Anything: a slash command, ten tree-sitter grammars and two data directory names

Installing is a slash command inside an agent, and the tree ships shell installers anyway

The quick start opens with two lines that are not shell commands:

/plugin marketplace add Egonex-AI/Understand-Anything
/plugin install understand-anything

They are typed into an agent session, and the second names the plugin to install. The repository root nevertheless carries install.sh and install.ps1, and four plugin directories: .claude-plugin/, .copilot-plugin/, .cursor-plugin/ and understand-anything-plugin/. The README also carries anchor links for Codex, VS Code with GitHub Copilot, Copilot CLI, Gemini CLI, OpenCode, Mistral Vibe CLI and Trae.

Consequence: there is one documented install path and at least six other hosts, so a reader on Cursor or Copilot has to work out which of the four directories is theirs. The two shell installers sitting in the tree are not what the quick start runs, which leaves a headless box or a CI job with nothing to execute from these instructions.

The first run re-reads the whole codebase and no figure is put on it

There is a callout about token usage, and it is the most useful paragraph in the file. The initial /understand analyses the entire codebase and can consume a significant number of tokens on large projects. The advice is to run it on a token plan or subscription, or to point the platform at a local model provider such as Ollama, at least for initialisation. Later runs are incremental by default, re-analysing only changed files, and use far fewer tokens as a result.

Consequence: the tool's value and its cost land on the same afternoon. There is no partial mode, no sample run and no number for what a 200,000 line repository costs, so you either budget for the whole scan or bring your own weights. The mitigation is real but one-sided, which is why the recommendation is a subscription rather than a smaller project. A live demo is offered for readers who would rather skip the reading, and the project states its aim plainly: the goal is not a graph that wows you with how complex a codebase is, but one that quietly shows how the pieces fit.

Ten tree-sitter grammars decide which languages get parsed at all

The repository publishes no list of supported languages. It publishes a build allowlist. The pnpm section of the root package.json names the packages permitted to run install scripts, and among them are esbuild, sharp and a run of tree-sitter grammars:

"tree-sitter-c",
"tree-sitter-c-sharp",

followed by cpp, go, java, javascript, php, python and ruby, with further entries past the end of what the file shows.

Consequence: that array is the de facto language matrix, and it is a build configuration rather than a feature table. A repository written in a language with no grammar on the allowlist gets no parse tree, and its graph degrades to whatever the language-agnostic pass can do, with no warning naming the gap. Native grammars also mean a first install compiles them, which is the other reason a cold setup is slower than a pure JavaScript tool.

Two data directory names are in use and nothing needs migrating, apparently

New projects write into a dot-directory called .ua. The knowledge graph lands in .ua/knowledge-graph.json and the stored language choice in .ua/config.json. A project that already has a .understand-anything/ directory keeps it: the file states that it stays the data directory when present and that nothing needs migrating.

Consequence: two layouts are live at once, and the compatibility rule is one sentence with no flag behind it. Any script that reads the graph has to look for .ua first and fall back, and a team with one project on each layout has two shapes of output to handle. The reassuring half of that sentence is also the problem, because nothing forces the older directory to be retired, so the split is permanent by design.

The root package is private, has no dependencies, and its main field is generated

The root package.json is marked private, declares no dependencies at all, and lists only development tooling: eslint, typescript, vitest, ajv and the eslint plugins. Its main field points at .opencode/plugins/understand-anything.js, a path inside a directory that does not appear among the top-level entries. The build is driven by two scripts:

"prepare": "pnpm --filter @understand-anything/core build",
"build": "pnpm -r build",

Consequence: there is nothing to add to a package.json. The root is a workspace rather than a library, its real dependencies live in the member packages, and the file main names is produced by a build instead of committed. Anyone hoping to embed this in a service finds out at install time that there is no published artefact, only a plugin that a host agent loads after pnpm has built it.

Five fixed layer names and a colour legend that implies more certainty than exists

Layer visualisation groups the graph automatically by architectural layer, and the legend names five: API, Service, Data, UI and Utility, each with a colour. Other features lean on the same machinery. Guided tours are architecture walkthroughs ordered by dependency, and a domain view lays business processes out as a horizontal graph of domains, flows and steps. Knowledge base mode is the most explicit about its two halves, since a deterministic parser extracts wikilinks and categories from index.md and LLM agents then discover implicit relationships, extract entities and surface claims.

Consequence: five fixed buckets will absorb a codebase that was never organised that way, and a colour-coded legend reads as measurement rather than as a guess. Two more features add confidence the layer view has not earned. Search is described as fuzzy and semantic, so a question like which parts handle auth returns results across the graph rather than exact identifiers, and the interface adapts its detail level to whether the reader is a junior developer, a product manager or a power user. Both are useful and neither is a measurement, so a confident answer in the dashboard is not evidence of a correct one. The knowledge base split is the honest case, because there the deterministic half is bounded by a single file, and it is worth checking which half produced a claim before believing it.

--language is decided once, on the first run, and then reused for good

Six values are supported: en as the default, then zh, zh-TW, ja, ko and ru. The flag applies to node summaries and descriptions, to dashboard labels, buttons and tooltips, and to guided tour explanations:

# Supported languages: en (default), zh, zh-TW, ja, ko, ru
/understand --language zh

Detection only happens on the first run in a project, when no flag is passed and nothing is stored yet. It looks at the language of the conversation, and if that is not English it asks you to confirm before generating. English conversations are unaffected, and the answer is written to .ua/config.json and reused on every later run.

Consequence: an English conversation about a Chinese codebase produces an English graph with no prompt at all, and because the choice is stored, the next run does not ask again. Changing it later means editing the config file by hand, a step the quick start never mentions.

Editorial conclusion

Use Understand Anything when you have just joined a project and want a map before you read anything, and run the first pass on a token plan or against a local model, because the initial scan is the expensive part and the later runs are not. Three things to know before you start. There is no package to install, since the quick start is a slash command inside an agent and the root package.json is private with no runtime dependencies. The languages it can parse are the tree-sitter grammars on the build allowlist, and a codebase in anything else gets a thinner graph without being told why. And the output language is decided on the first run and stored, so a project that starts in an English conversation keeps English node summaries until somebody edits the config.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes