In Claude Code, /init is the command you run the first time you point Claude at a project. It scans what's in the folder and writes a file called CLAUDE.md at the top of your project: a plain-English guide that documents how the project is laid out, the key commands to build and test and run it, the conventions it follows, and how the pieces fit together. From then on, Claude reads that guide automatically at the start of every session, so you're not re-explaining the same background each time. That is what the /init command in Claude Code is for.

If some of those words are new: a "project" here just means the folder of files you're working in. "CLAUDE.md" is an ordinary text file (Markdown, the same simple format used for README files). You don't have to write it by hand -- /init drafts it for you.

What the /init command does in Claude Code

When you run it, Claude reads through the project the way a new hire would skim a codebase on day one: what folders exist, what language it's written in, how you start it, how you test it, what patterns show up over and over. Then it writes all of that down into CLAUDE.md so the knowledge is captured once instead of living only in your head.

/init

Run it once in a new project. No arguments needed. Click to copy.

It takes no required arguments. You type /init, Claude does the reading and writing, and you end up with a starter guide you can review and adjust.

What ends up in the CLAUDE.md guide

The point of the file is to answer the questions Claude would otherwise have to ask you again and again. A typical guide covers a handful of things.

CLAUDE.md
▣Project structureWhat the main folders are and what lives where.captured
▶Key commandsHow to build, test, and run the project.captured
§ConventionsNaming, style, and the way things are usually done here.captured
☷ArchitectureHow the pieces connect, in plain language.captured

A starter CLAUDE.md documents the things Claude would otherwise re-ask every session.

Because it's just Markdown, you can open CLAUDE.md and edit it by hand afterward. Fix anything Claude got wrong, add a note it couldn't have known, or trim what you don't need. It's your file.

Where /init fits when you start a project

Think of it as step one of getting set up in a new folder. You run it once, review the result, and move on.

Step 1Open the projectStart Claude Code inside the folder you want to work in.
Step 2Run /initClaude reads the project and drafts a CLAUDE.md guide for you.
Step 3Review and refineRead the file, correct anything off, and you're set for every future session.

A real example

Say a colleague hands you a project you've never seen and you want Claude's help with it. Without a guide, your first session goes sideways: Claude doesn't know how the project starts, so it guesses at the wrong command, and you spend the first ten minutes explaining the layout before any real work happens.

Instead, you open the folder and run it:

/init

Claude reads the project and writes a CLAUDE.md that records the structure, the build and test commands, and the conventions it found. You skim it, fix one detail it got slightly wrong, and save. Now every future session starts with Claude already oriented: no re-explaining, no wrong guesses. You went from "here's how this project works, again" to that context being written down once and reused.

Good to know: you can run /init again later to rebuild or refresh the guide. If the project has changed a lot, re-running it gives you an updated draft you can then trim by hand.

Why writing context down matters

The real value isn't the one file. It's the habit of capturing how something works so a tool can help without a running commentary from you. /init is the smallest version of that idea: answer the "how does this work" questions once, write them down, and everything after gets faster. That same move -- capture the context once, reuse it forever -- is what separates poking at an AI tool from actually running work through it.