shinyobjectz/montology
A repo's vocabulary as a database, enforced against the code by a tree-sitter scan in every language it declares — Python, TypeScript, Go, Rust, Swift, Java, Ruby, Elixir, C/C++. Check a name before declaring it, mine the words a codebase is already asking for, propagate a rename by token, and inherit one org ontology across every repo. Design tokens are one kind of word among many.
The guided walkthrough for a codebase that has just installed montology (or has never written its vocabulary down) — phased questions served to the people who own the code as a clean one-question-at-a-time form in their browser (a local HTML file, no hosted service), answers returned to the agent on disk, each round written from the last and from what the code itself declares, closing with one glossary page rendered from the ontology. Use right after monty init, when someone asks how to START using montology or set up an ontology in a new repo, when a repo has few or no words, when someone says "let's define our terms", or before any rename, migration or design-token adoption in a codebase whose vocabulary was never written down.
A repo's vocabulary as a database, enforced against the code by a tree-sitter scan — in every language it declares (Python, TypeScript/JS, Go, Rust, Swift, Java, Ruby, Elixir, C/C++, and more). Use BEFORE naming anything in code — a class, struct, function, type, module, table, column, endpoint, event, env var, CLI flag or plain concept; when two names collide or mean two things; when a rename must propagate through the tree; when building a vocabulary out of what a codebase already declares; when setting montology up in a repo for the first time; and for design tokens, which are one kind of word among many rather than the point. Triggers on montology / monty / ontology / vocabulary / naming / "what do we call this" / drift.