Explore Claude Code: an interactive file-tree tour of .claude/ config

What Explore Claude Code actually solves

Claude Code documentation tells you that a CLAUDE.md file exists and that .claude/settings.json controls permissions. What it does not do well is show you the shape of a repository that uses all of it at once. The files are spread across several reference pages, and the relationships between them (which folder holds slash commands, which one holds hooks, which one holds subagents) are easy to mix up on a first read.

Explore Claude Code answers that with a simulated project you click through. The README describes it as "a simulated Claude Code project you can click through", and says every file and folder in the sidebar is a real Claude Code concept: the same .claude/ directory, config files and scaffolding you would find in an actual repo. Clicking a file shows what it does, how to set it up, and annotated examples.

The intended reader is someone who has decided to use Claude Code and now needs to lay out a project. It is also usable as teaching material, since the whole thing is a single static site that opens in a browser. It is not for people who want to run Claude Code itself, and it is not a linter or a scaffolder that writes files into your repo.

The file tree is the interface, and manifest.json is the content

The architecture is deliberately plain. The README states the site is static HTML, CSS and vanilla JavaScript with zero build steps, zero frameworks and zero bundlers. There is no server component and no API calls; the browser loads index.html and the JavaScript modules under site/js/.

Content lives in two places. site/data/manifest.json drives the entire UI: the tree, the content references, the badges and the feature groupings. The README calls it "the single source of truth" and says that is where you go to add or change content. The prose and config samples themselves sit in site/content/ as markdown and config files. site/js/content-loader.js is described as a custom markdown parser and renderer, which means the site does not pull in a markdown library at runtime.

Navigation is split across small modules: app.js handles routing, keyboard navigation and theme; file-explorer.js renders the sidebar tree with animated canvas connectors; search.js powers the Ctrl/Cmd+K palette; terminal.js runs the slash-command emulator; progress.js tracks feature completion in localStorage. That last one is the only state the site keeps, and it stays in your browser.

The explorer separates two kinds of material. Everything under .claude/ is project config you create and commit. Everything under built-in/ covers features that ship with Claude Code and need no setup, including bundled skills such as /simplify, /batch, /debug, /loop and /claude-api. A visual separator divides the two halves. That split is the most useful design decision in the project, because it answers the question a new user asks first: do I have to create this, or is it already there?

Running it locally and opening your first entry

The README points to exploreclaudecode.com as the fastest route, with no install, signup or build step. If you want it offline, the repository ships a site/ directory that any static server can host. The README gives these options verbatim:

git clone https://github.com/LukeRenton/explore-claude-code.git
cd explore-claude-code

npx serve site
# or
python -m http.server -d site 8080
# or just open site/index.html directly in your browser

After the server starts, open the address it prints (port 8080 for the Python command) and you land on the single-page app. The sidebar shows the fake repository tree. Press Ctrl or Cmd plus K to open the search palette, which the README says jumps to any file or feature by title, path or badge. Typing a feature name there is faster than expanding folders.

Once you have an entry open, use the arrow keys to step through files in order. The terminal panel at the bottom runs a slash-command emulator covering /help, /init, /doctor and others. The title-bar toggle switches between light and dark themes and follows your system preference. Each page also has a copy link control for sharing a deep link to that entry.

To see how content is wired up, open site/data/manifest.json in your editor. Adding a feature means adding an entry there and a matching file under site/content/. Nothing is generated, so the manifest and the content directory have to stay in step by hand.

Where the site stops being useful

The content is written, not extracted. The README says every piece of content is written as if it were a real config file in a real repo, and that you are reading the config itself, annotated. That framing is honest about what it is, but it also sets the boundary: nothing in the repository verifies those samples against a Claude Code release. The README does not document any version pinning, and no releases were retrieved for this repository.

There is a second constraint in the same sentence. The site is only as current as its last content commit. The last push to the repository was on 2026-08-12, so anything Claude Code added after that date is absent unless a contributor has since added it. The README's contributing section asks for exactly that work: content for new Claude Code features as they ship.

A third limitation is scope. The explorer covers configuration and built-in features. It does not cover the Claude Code CLI itself, authentication, model selection or pricing, and the README makes no claim to. If your question is operational rather than structural, this is the wrong tool.

Finally, the zero-dependency choice has a cost. The custom markdown parser in content-loader.js means the site does not inherit the edge-case handling of an established markdown library. For hand-written educational content that is a reasonable trade, but it does mean unusual markdown in a contributed file may not render as its author expects.

How it compares to the official Claude Code docs

The obvious alternative is Anthropic's own Claude Code documentation. The difference is not coverage, it is form. Official docs are organised by feature and written to be accurate for the current release; they are the authority on what a setting does. Explore Claude Code is organised by file path and written to show what a project looks like when the features are used together. A reference page for settings.json tells you which keys exist. A clickable tree that includes .claude/settings.json, .claude/rules/, .claude/commands/, .claude/skills/, .claude/agents/, .claude/hooks/, .claude/plugins/ and .mcp.json in one sidebar tells you how they sit next to each other.

The second alternative is a real starter repository you clone and edit. That gets you working files immediately, but it also gets you someone else's choices, and it usually covers a subset of the config surface. Explore Claude Code is narrower in output (you copy scaffolding out of it rather than running it) and wider in coverage of the concepts, because it is not constrained by being a working project.

Neither alternative replaces the other. Use the official docs to confirm a key name or a permission syntax. Use this site when you are deciding which folders to create in the first place.

Licence, maintenance and the cost of keeping it current

The repository is MIT licensed, which permits reuse and modification with the licence and copyright notice retained. That matters here because the README explicitly invites you to copy the scaffolding into your own projects. If you fork the site and republish the educational content, keep the LICENSE file with it. This is a description of the licence text, not legal advice.

The repository is not archived, and its last push was on 2026-08-12. There are no retrieved releases, so there is no versioned changelog to track. Upgrades are therefore a git pull on the main branch, not a dependency bump. Nothing in the site has a package.json to update for runtime dependencies, because there are none.

The real maintenance cost is editorial. Every new Claude Code feature needs an entry in site/data/manifest.json plus a file under site/content/, and stale entries are worse than missing ones because they look authoritative. The README lists content for new features, accessibility work, mobile refinements and translations as the areas where contributions help. If you fork it for internal training, budget for someone to read the Claude Code release notes and reconcile them against the manifest on a schedule you choose.

Editorial conclusion

Adopt it if you are new to Claude Code and want to see what a real .claude/ directory looks like before you write one, or if you are teaching that layout to a team. Skip it if you need executable examples validated against a specific Claude Code version, or if you want a reference that is generated from the tool itself. Before relying on it, open site/data/manifest.json and check whether the feature you care about is listed there, since that file is the single source of truth for what the site covers.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. LukeRenton/explore-claude-code on GitHub
4. Project website
5. README