Atlas

Why I built it

Agent tools usually treat repository documentation as loose files. Every run starts with another search through READMEs, package docs, hidden instructions, and whatever happened to be open in the editor. That works on a small repo. It falls apart when the work spans several repositories or when the useful docs are mixed with stale plans and private notes.

Atlas turns documentation into a maintained artifact. The artifact has stable IDs, metadata, checksums, a local SQLite corpus, and enough structure to answer a query without reading the entire repository again.

How it works

A maintainer runs the build against a checkout:

atlas init
atlas build --profile public
atlas artifact verify --fresh

The build discovers packages, modules, documents, and skills. It compiles Markdown into canonical sections, creates retrieval chunks, stores provenance, and writes the public artifact under .moxel/atlas.

A consumer can then import it directly:

atlas repo add moxellabs/atlas
atlas search "how does incremental rebuild recovery work"
atlas inspect retrieval --query "incremental rebuild recovery"

Query-time search stays local. Atlas does not fetch source files while an agent is asking for context.

What exists today

Atlas ships as @mrmendez/atlas with an atlas CLI. The same local corpus is available through an HTTP server and MCP. The repository contains separate packages for topology, compilation, tokenization, storage, retrieval, indexing, source adapters, and protocol surfaces.

The public artifact can include both documentation and SKILL.md files. Atlas exposes those skills through CLI, server, and MCP surfaces instead of treating them as invisible editor configuration.

The boundary

Atlas is not an autonomous coding agent and it does not take over Git. It does not choose branches, commit changes, open pull requests, or bypass repository review. Its job is narrower: make the repository’s maintained knowledge queryable, local, and traceable.