by wlsdks
Understand what your codebase builds, why it is structured that way, and what a change could affect. One shared Markdown ontology for humans and coding agents—visualized for people, accessible to agents through MCP, and reviewed with Git. Local-first. Open source.
# Add to your Claude Code skills
git clone https://github.com/wlsdks/ontology-atlasGuides for using ai agents skills like ontology-atlas.
Last scanned: 9/15/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-09-15T09:14:04.497Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}See how ontology-atlas compares with popular alternatives.
ontology-atlas is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by wlsdks. Understand what your codebase builds, why it is structured that way, and what a change could affect. One shared Markdown ontology for humans and coding agents—visualized for people, accessible to agents through MCP, and reviewed with Git. Local-first. Open source. It has 122 GitHub stars.
Yes. ontology-atlas passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/wlsdks/ontology-atlas" and add it to your Claude Code skills directory (see the Installation section above).
ontology-atlas is primarily written in TypeScript. It is open-source under wlsdks on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh ontology-atlas against similar tools.
No comments yet. Be the first to share your thoughts!
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.

When an agent finishes a change, you still need to judge what it understood, which rules matter, and what needs your attention. File lists and the producing agent's summary are starting points; they do not by themselves establish that the system's meaning or boundaries were preserved.
Atlas keeps those answers in an atlas/ folder of Markdown inside the
repository, so meaning is cloned, branched, and reviewed with the code. Each
file's frontmatter declares what it is — project, domain, capability,
element, or a linked document — and what it points at. That folder is the
whole database.
Atlas compiles that folder into a typed graph. Your coding agent can request context for a task: recorded capabilities, implementation anchors, declared dependencies, evidence, and unknowns. You can inspect those same records and relations in the workbench, open their evidence, and decide which proposed meaning changes to keep. The files remain available to the next person or agent, alongside the code in Git.
The goal is understanding and actionable control, with confidence proportionate to the evidence. A graph path is a declared relationship, not proof of a complete runtime blast radius. A current source path does not prove its recorded meaning is correct. Atlas keeps those distinctions visible so missing evidence can lead to further inspection rather than automatic reassurance. Its five-kind discriminator and standards boundary live in the vault specification.
With a populated vault and an MCP connection, ask your agent for the context of
the change you want to make. The current task-aware entry is
query_ontology with operation: "agent_brief", detail: "compact", a selected
project, and your task. It supplies bounded context and follow-up reads;
the coding agent still inspects source and verifies its work.
When meaning changes, review the exact proposal and its evidence, then keep the accepted Markdown change with the code's Git history. You need not open Atlas for every task; its map, documents, and change review are there when you need to understand or correct the recorded meaning. Meaning acceptance, code review, merge, and deployment are separate decisions. Host support and configured permissions determine how agent writes reach review; an MCP connection alone does not enforce every agent's behavior.
What still needs proof: reliable meaning reconstruction from unfamiliar legacy code, a complete task-bound Meaning Diff, and improved outcomes across successive real tasks remain development and validation work. Current graph, write-review, and task-context features do not guarantee that an agent's code change is safe. See the quality authority map and development priorities.
The download page is the release authority: a generated record of the published tag, real asset sizes, checksums, platforms, and signing state. This README pins no tag, so it cannot contradict the files you are about to install. GitHub Releases is the second direct source.
.mcpb bundle or a container image (channels).-rc.N build walks the same signing, notarization, installer, and updater
checks as a final one — what it lacks is a wide run behind it. The in-app
updater reads a fixed Pages manifest staged from the newest non-draft release,
release candidates included, and every archive must pass the bundled signature
check before installation.Not a roadmap. This summarizes behavior documented in the feature inventory, the specification, and the decision history and independent record workflow.
Each worktree adds its own decision/change/pilot fragments with pnpm record:new
and pnpm po:record. pnpm test:records checks composition and writer contracts.
Docs Vault JSON and public copies are ignored build products, materialized by
installation and checkout/merge hooks; use pnpm docs-vault:build after an
installation with scripts disabled.
Working today
tools/list. Agent guide.mcp-verify. File presence is never
presented as a live connection.init installs the agent's procedures where the agent runs, and prints the
one sentence to paste into your own CLAUDE.md or AGENTS.md. Atlas does not
edit files you wrote.Shipping, not settled