Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · November 1, 2026 · repo

haydenschmitty/floorplanclaude-codecodexai-skills

Floorplan Draws a Plain-English Map of Your Codebase. Here's Which Parts to Trust.

A new Claude Code and Codex plugin maps your app for you. Most of the lines come from your actual code, and knowing which ones don't is the whole trick.

Coding agents write software faster than people can read it. A weekend with Claude Code or Codex can produce a working app with forty files, three outside services and endpoints you never looked at. It runs. You just do not know what you have.

That gap shows up at the worst moments. A bug lands and you cannot say which part of the app it lives in. A new teammate asks how a login flows from the screen to the database, and the honest answer is "let me ask the agent." You are now depending on a system you cannot picture.

Floorplan is a plugin for Claude Code and Codex that tries to close that gap. It reads your codebase and draws an interactive, plain-English map of the app: its parts, files, endpoints, screens and the outside services it talks to. It climbed Trendshift, a daily board of fast-rising GitHub repos, this weekend, with version 0.6.0 released October 31 and about 1,100 stars as of November 1.

Plenty of tools promise an AI-generated overview of your code. What makes Floorplan worth a look is a design choice buried in its docs. Most of the map's lines come from parsing your code. The AI names things and fills in the few links code cannot show. That split decides how much you can trust each part of the map, and it is a good question to ask of any AI tool that claims to explain your code.

What you get

Picture a building plan for software. At the top level you see the big parts of the app, named in plain English: "Checkout," "User accounts," "Payment provider." Zoom in on a part and you see its files and endpoints. Zoom further and you reach a single file with a short description of what it does.

The README lists the main views:

  • A zoomable map from the whole app down to individual files and endpoints, with plain-English labels and a toggle for a developer view
  • "Start from a screen," which traces what happens behind a page in your app
  • "Ask the map," a question box that answers with a mini-map and a walkthrough
  • A Health check that flags issues like exposed keys, open database tables and endpoints with no login check
  • A "Recent work" board that shows what changed since the last map
  • Cross-repo matching, so a frontend in one repo connects to its backend in another
  • Export to a single HTML file you can send to someone

It also works backward. Hand it a product spec (a PRD, the product requirements document a team writes before building) for an app that does not exist yet, and it produces a "blueprint," a map marked as a plan.

Language support covers TypeScript, JavaScript, Python, Go, Rust, Java, Kotlin and Scala, plus Vue, Svelte and Astro files. It recognizes endpoints in common server frameworks (Express, Hono, Next.js, FastAPI, Django, Gin, Spring and others) and screens in common frontend ones (Next.js, React Router, SvelteKit, Nuxt, Angular and others).

The insight: who draws which lines

Here is where Floorplan earns its place. Its how-it-works doc splits the job between ordinary scripts and the AI, and the split is deliberate.

The scripts do the measuring. A scan script finds the git repos in a folder, lists files through git (so your .gitignore is respected), and pulls out imports, exports, doc comments, endpoints and outgoing web requests. A second script matches each outgoing request to the endpoint that handles it, including cases where a group of routes is attached under a shared path like /api. A build script then checks the AI's output, assigns every file to a part, wires up the connections and runs the Health check.

The AI does the naming, plus a little drawing. It reads a summary of the scan, your READMEs and setup files, then decides what the app's parts are, what to call them and which outside services exist. It fills in a short description for each file and endpoint, and writes a "Start here" tour. It also adds what the docs call "connections the scan can't see, like queues, scheduled jobs and webhooks."

Why does this matter? Think about the difference between a surveyor and a tour guide. A surveyor measures where the walls are. A tour guide tells you what each room is for. If the tour guide drew all the walls, you would have no way to know whether a hallway exists or just sounds plausible.

In Floorplan, the surveyor draws most of the walls. When your checkout screen calls your payment endpoint, that line comes from matching the request in the code to the route that answers it. The tour guide sketches in a few passages the surveyor cannot see, like a background job that fires every night or a webhook a payment provider calls. Those are useful, because a map without them would be wrong. They are also the lines most worth double-checking, along with every description, since the model wrote them.

That gives you a simple rule when you read the map. Trust request-and-import lines most, AI-added links less, and descriptions least. The docs do not say whether the map styles AI-added links differently, so the practical move is to ask the map how it knows a connection exists when one surprises you.

The same thinking shows up in updates. When you ask Floorplan to refresh the map, a script compares two fingerprints per file against the last build. One tracks exact content, which spots edits, renames and moves. The other tracks the file's signature (its exports, endpoints and doc comments), and edits inside function bodies don't change it. Descriptions carry over to moved files, and entries whose signature changed get flagged for review. The AI only describes what is new or flagged, and rechecks the structure after a large change. That keeps refreshes fast, and it keeps earlier descriptions from drifting each time you rebuild.

Install it and make your first map

Floorplan needs Node.js 18 or later. It has no other dependencies and asks for no API keys, because it uses the Claude Code or Codex account you already have.

In Claude Code:

claude plugin marketplace add haydenschmitty/floorplan
claude plugin install floorplan@floorplan

In Codex, add the haydenschmitty/floorplan marketplace from the Plugins panel in the Codex app, or from a terminal:

codex plugin marketplace add haydenschmitty/floorplan
codex plugin add floorplan@floorplan

The README recommends installing the Claude Code command-line tool even if you mostly use the desktop app, so the map's question box can read your actual code.

Then open your project and say: "Make me a floorplan of this app." In Codex you can also type $floorplan.

What to expect: the plugin writes a floorplan/ folder in your project that ignores itself in git, so it never lands in a commit. The output is floorplan/index.html, and a small local server opens it in your browser. That server only accepts connections from your own machine. In Claude Code, Floorplan may offer to add a section to CLAUDE.local.md, a local notes file for the agent; it asks first, and that file is not committed either.

After you change code, say "Update the floorplan." Only changed files get reread.

Three ways to use it this week

Before you hand an agent a big change. Open the map, find the part you are about to touch and look at what connects to it. If the payment endpoint is called from four screens, you now know four places to test. This takes two minutes and saves the "why did the settings page break" afternoon.

On a codebase you inherited or vibe-coded (built mostly by prompting an agent). Run the Health check first. Exposed keys, open database tables and endpoints with no access check are exactly the problems that slip into fast, agent-written apps. The check depends on what the scan finds, so it is a first pass, not an audit.

For explaining the app to someone. Export the map to a single HTML file and send it to the teammate, client or cofounder who keeps asking how it all fits together. The plain-English labels are the default; a developer view is a toggle away.

Where it stops

Floorplan is honest in its docs about its limits, and they are worth knowing before you rely on it.

Matching is pattern-based, so it misses links. The docs say the request-to-endpoint matching is "pattern matching, not a compiler." Unusual routing, URLs built at runtime or homegrown wrappers can slip through. You can add missing links by hand as explicit connections. A missing line on the map does not prove two parts are unconnected.

Every description, and every AI-added link, needs a human read. The naming, the descriptions and the queue, job and webhook connections come from the model. They will usually be right and occasionally confident nonsense. Spot-check the parts you care about.

"Runs locally" has edges. The scan, the map and the server run on your machine, and Floorplan says it has no analytics; the one network exception it documents is the optional Floorplan Cloud waitlist, which sends your email. But the AI steps run through your Claude Code or Codex account, which means the agent sends code to Anthropic or OpenAI the same way it does for any other task. Each question in the Ask bar starts a real agent session: claude -p with read and search tools, or codex exec in Codex's read-only sandbox (not saved to your Codex history). That counts against your usage like any other session. If you ask from inside the Claude desktop app, questions go through the app without access to your source code, so answers rely on the map alone.

Some placements are guesses. Firebase background functions get listed, but the AI decides which part they belong to. Blueprints are only as accurate as the spec you feed in.

It is young. Version 0.6.0, MIT-licensed, about 1,100 stars. Expect rough edges and changes between releases.

The pattern worth stealing

The most useful thing about Floorplan might not be the map itself. It is the division of labor.

A lot of AI developer tools ask the model to do everything: read the code, decide what connects to what, and explain it. When that tool is wrong, you cannot tell which part failed. Floorplan gives most of the facts to code that can be checked and keeps the model mostly on the job it is good at: naming things for humans and filling the gaps parsing cannot reach.

Look for that split the next time a tool offers to explain your codebase. Ask which parts were measured and which were written. If nobody can tell you, treat the whole thing as a guess.

Install Floorplan on the project you understand least. Read the measured lines first, then the AI's additions and labels, and see which ones you would have gotten wrong.

Sources: haydenschmitty/floorplan README (v0.6.0, reviewed Nov 1, 2026); How it works doc at v0.6.0; Trendshift; releases; MIT license per the repo's LICENSE file.