How to Use Claude Code's /init Command to Understand Any Codebase Fast

The Problem With Jumping Into Someone Else's Code

I still remember the first time someone handed me a project folder and said, "just make a few small changes." It had 47 files, zero documentation, and folder names like utils2_final_REAL. I spent two hours just trying to figure out which file actually ran the thing.

If you've been there, Claude Code's /init command is going to feel like a cheat code. It scans your entire project, figures out what's going on, and generates a CLAUDE.md file that gives you (and Claude) a working map of the codebase before you touch a single line.

Even if the project is yours and you built it six months ago and have completely forgotten what half of it does — this command is your friend.

What /init Actually Does

When you run /init inside a Claude Code session, Claude reads through your project structure — your files, folders, config files, package manifests, README if one exists — and generates a CLAUDE.md file at the root of your project.

Think of that file as Claude's notes about your project. It typically includes:

• What the project does and what tech stack it uses
• How to run it, build it, and test it
• Key files and what they're responsible for
• Any patterns or conventions Claude notices in your code
• Things you should know before making changes

The magic part: once that file exists, Claude automatically reads it every time you start a new session in that project. So instead of re-explaining your codebase from scratch every single conversation, Claude already has context. That's a huge time saver when you're working on something over multiple sessions.

Running /init: Step by Step

Here's exactly how to do it. Open your terminal, navigate to your project folder, and start a Claude Code session:

Once you're in the Claude Code session, just type the command:

That's genuinely it. Claude does the scanning, does the writing, and drops the file where it needs to be. Depending on how big your project is, this usually takes between 15 seconds and a couple of minutes.

What the Output Looks Like

Let's say you ran /init on a basic Node.js Express app. Here's the kind of CLAUDE.md it might generate:

Now instead of digging through all those files yourself, you've got a map. And more importantly, Claude has that map too — so when you ask "why is my login route returning a 401?" Claude already knows you're using JWT middleware and exactly where to look.

After /init: What to Do With What You Got

Don't just let the CLAUDE.md sit there. Actually read it. When I ran /init on an old side project recently, Claude's output reminded me that I had a .env.example file that I'd never actually filled in — which explained why the database kept refusing to connect. I'd completely forgotten that detail.

Here's how I suggest using the generated file:

• Verify it's accurate. Claude is reading your files, not your mind. If something is wrong or outdated, fix it manually.
• Add what Claude missed. Did Claude not mention a known bug? A weird workaround you put in? Add a "Known Issues" section yourself.
• Use it as a starting point for questions. Now that you both have the map, ask Claude things like "based on the project structure, where should I add a new API endpoint?" and you'll get much more useful answers.

A Real Use Case: Inheriting a Stranger's Project

Here's a scenario I've seen come up a lot in beginner communities: someone follows a tutorial, builds a project, shares it on GitHub, and then you clone it to learn from it — but the README is basically "install stuff and run it" with zero explanation of how anything actually connects.

Try this instead of spending an hour reading every file:

Then after Claude generates the CLAUDE.md, follow up with questions like:

• "Walk me through what happens when a user submits the form"
• "Which file should I look at to understand the data flow?"
• "Is there anything in this project that looks non-standard or that I should be careful about?"

Because Claude has read the whole thing and written the summary itself, these follow-up questions get surprisingly good answers. Way better than asking a general AI that has no idea what files your project actually has.

The Beginner Mindset Shift This Creates

Here's what I think is the most underrated benefit of /init: it gets you into the habit of understanding before editing.

A lot of beginners (myself included, early on) would just start poking at code to see what breaks. That works up to a point, but it's chaotic. Running /init forces a pause. You're saying "let me understand this first" before you start making changes — and that habit makes you a better developer regardless of whether AI is involved.

It also gives you something concrete to ask about. "I don't understand this codebase" is a hard question to get help with. "I ran /init and it says my auth flow goes through middleware/auth.js — can you explain how that file works?" is a great question that will get you a useful answer fast.

Think of it as the 10 minutes that saves you 3 hours of confusion later. That's a trade I'll take every time.