Tutorials Search / Native Mac IDE / Generate a CLAUDE.md with /init
📝 Written ● Beginner Updated 2026-05-13

Generate a CLAUDE.md with /init

Type /init in any repo. The agent reads the codebase, picks out what matters, writes a CLAUDE.md at the project root. Every future chat in the project gets that context loaded automatically — and you didn't have to write a word.

Every chat the agent has about your project starts cold. It sees the files it's asked to look at, infers the rest, and proceeds. That works fine for trivial work — finding a function, fixing a typo. It doesn't work well for anything that depends on conventions the codebase chose: which testing library is in use, what the deployment story is, where the canonical README lives, what's been deprecated, which patterns the team avoids.

A CLAUDE.md file at the project root is how you fix that asymmetry. It's a small, hand-curated document of project-level context that LingCode loads into every chat about that project. Done well, it turns "agent guesses" into "agent knows." The cost is that someone has to write it — and that someone usually never gets around to it, because writing documentation for a tool feels like overhead instead of work.

/init is the cheat. The agent reads the codebase itself — file layout, manifests, dependencies, READMEs, scripts, recent commits — and writes a first draft of CLAUDE.md based on what it found. You read the draft, edit anything wrong, commit. Five minutes from "nothing" to "every future chat is project-aware."

What you'll learn

Step 1: Run /init

1

One command in the chat panel

Open a chat with the project loaded. Type /init and send. The skill kicks in — the agent walks the file tree, reads the obvious entry points (README.md, package.json, Cargo.toml, Makefile, .github/, scripts/, etc.), looks at recent commit messages for signals about ongoing work, and writes a draft CLAUDE.md in the project root.

The whole thing takes a minute or two on a typical project. The agent shows its work — you'll see it reading files in the chat as it goes. The output is a real file on disk, ready for you to inspect.

Step 2: Read the draft

2

Three things to look for

Open CLAUDE.md. A good draft has:

  • What the project is. One paragraph at the top. The agent often gets this right by reading the README.
  • How to build, test, and run. Concrete commands the agent should use, not vague descriptions. npm test beats "the tests are run with npm."
  • Conventions and gotchas. Naming patterns, files to be careful with, "don't edit X manually," things only an insider would know. The agent infers some of this from .editorconfig, lint configs, and recent commits; it misses the rest.

A weak draft is one that reads like a README — descriptions without prescriptions. That's the right time to edit, not just trust.

Step 3: Edit for the things the agent can't infer

3

Add the institutional knowledge

The draft is good at facts visible in the code. It misses things that are visible only to humans:

  • "We're migrating away from X; don't add new uses of it."
  • "This file looks important but is actually dead — ignore it."
  • "This whole subdirectory is owned by another team; don't touch it without asking."
  • "The tests in integration/ are flaky on slow machines; if they fail intermittently, re-run rather than debug."

These are the entries that pay back the most. Add them in your own words. The agent isn't trying to write a polished doc — it's seeding one for you to grow.

Keep it tight. A 300-line CLAUDE.md loads into every chat. The agent has to read all of it, every time, and your token budget pays. Aim for the smallest set of things that change behavior — not a tutorial, not a marketing pitch, not a tour. The phrase "high-signal traps only" applies.

Step 4: Commit it

4

It belongs in the repo

Stage and commit CLAUDE.md like any other file. It's project-level context; your teammates' chats benefit too. Every new clone, every new developer's first chat, every CI agent run — all of them pick up the same context.

A reasonable commit message: "Add CLAUDE.md for agent context."

Step 5: When to re-run /init

5

Rarely; usually edit by hand

Once you have a CLAUDE.md in place, re-running /init overwrites it. That's almost never what you want — you've added human-written context that the agent doesn't see and won't regenerate.

Re-run /init when:

  • The project has changed shape substantially (major rewrite, new top-level structure).
  • You've never been happy with the existing one and want a fresh start.

For everything else, just edit by hand. Most updates are one-line additions: a new gotcha learned, a deprecation to add, a convention to record.

Step 6: User-level and nested CLAUDE.md

6

Project, user, and subdirectory scopes

LingCode reads CLAUDE.md from three places, merged at chat-start:

  • Project root — what /init writes. Loaded for every chat in the project.
  • User-wide at ~/.claude/CLAUDE.md — personal habits across all projects ("I always want commits in imperative voice"). /init doesn't touch this.
  • Subdirectories — a CLAUDE.md inside a subfolder applies only when working in that folder. Useful for monorepos where each package has its own conventions.

If a chat is in packages/api/, all three apply: user-wide, project-root, and packages/api/CLAUDE.md. Project conventions override user habits; subdirectory rules override project root.

Don't put secrets in CLAUDE.md. It's a normal file in your repo. API keys, tokens, internal URLs — those belong in env vars or Keychain, not in a doc the agent loads. Treat CLAUDE.md as public, even if your repo is private.

What's next