There is no /claudemd-builder command in Claude Code. The built-in command that bootstraps a project CLAUDE.md is /init. This page describes the real, documented workflow for creating and maintaining CLAUDE.md memory files.
What /init does
Run /init inside a project and Claude analyzes your codebase, then generates a starting CLAUDE.md containing build commands, test instructions, and the project conventions it discovers. From there you refine the file by hand with instructions Claude would not find on its own.
- If a
CLAUDE.md already exists, /init suggests improvements rather than overwriting it.
- If the repo already has an
AGENTS.md, /init reads it and incorporates the relevant parts into the generated CLAUDE.md. It also reads other tool configs like .cursorrules, .devin/rules/, and .windsurfrules.
/init
Interactive multi-phase flow (opt-in)
Set the environment variable CLAUDE_CODE_NEW_INIT=1 to enable an interactive flow. In this mode /init asks which artifacts to set up (CLAUDE.md files, skills, and hooks), explores your codebase with a subagent, fills gaps with follow-up questions, and presents a reviewable proposal before writing any files.
CLAUDE_CODE_NEW_INIT=1 claude
# then, inside the session:
/init
/init takes no flags such as --template, --validate, or --hierarchy. Those do not exist. You shape the output by editing the generated file and re-running /init to get improvement suggestions.
Where CLAUDE.md files live
CLAUDE.md files can live in several locations, loaded from broadest scope to most specific:
| Scope |
Location |
Shared with |
| Managed policy |
/Library/Application Support/ClaudeCode/CLAUDE.md (macOS), /etc/claude-code/CLAUDE.md (Linux/WSL), C:\Program Files\ClaudeCode\CLAUDE.md (Windows) |
All users on the machine |
| User instructions |
~/.claude/CLAUDE.md |
Just you, all projects |
| Project instructions |
./CLAUDE.md or ./.claude/CLAUDE.md |
Team, via source control |
| Local instructions |
./CLAUDE.local.md (gitignore it) |
Just you, this project |
Files in the directory hierarchy above the working directory load in full at launch. Files in subdirectories load on demand when Claude reads files in those directories. Across the tree, content is concatenated (not overridden), ordered from the filesystem root down to your working directory, so the most specific instructions are read last. Aim for under ~200 lines per file; longer files consume more context and reduce adherence.
Splitting and importing
CLAUDE.md files can pull in other files with @path/to/import syntax. Imported files are expanded into context at launch. Both relative and absolute paths work; imports can recurse up to four hops.
See @README for project overview and @package.json for npm commands.
# Additional Instructions
- git workflow @docs/git-instructions.md
If you already keep guidance in AGENTS.md, create a CLAUDE.md that imports it so both tools read one source of truth:
@AGENTS.md
## Claude Code
Use plan mode for changes under `src/billing/`.
Path-scoped rules with .claude/rules/
For larger projects, split instructions into .claude/rules/*.md. Rules without paths frontmatter load every session with the same priority as .claude/CLAUDE.md. Rules with a paths field load only when Claude works with matching files:
---
paths:
- "src/api/**/*.ts"
---
# API Development Rules
- All API endpoints must include input validation
- Use the standard error response format
This is the documented way to get directory- or filetype-specific context, in place of the fictional --hierarchy flag.
Inspecting loaded memory with /memory
/memory lists every CLAUDE.md, CLAUDE.local.md, and rules file loaded in the current session, lets you toggle auto memory, and opens the auto memory folder. Use it to confirm a file is actually being loaded when an instruction is being ignored, and to open any file in your editor.
/memory
A custom command alternative
If you want a repeatable, project-specific routine for editing CLAUDE.md (for example, "audit CLAUDE.md against the current stack and propose updates"), create a custom command, which is a user-authored file, not a built-in. Custom commands have been merged into skills: a file at .claude/commands/<name>.md and a skill at .claude/skills/<name>/SKILL.md both create /<name> and work the same way. Existing .claude/commands/ files keep working.
mkdir -p .claude/commands
cat > .claude/commands/refresh-claude-md.md <<'EOF'
Review the project's CLAUDE.md against the current dependencies in package.json
and the directory layout. Propose concise updates to build/test commands,
conventions, and architecture notes. Keep the file under 200 lines and do not
add secrets or frequently changing data.
EOF
Invoke it with:
/refresh-claude-md
This is a normal prompt template you maintain yourself. It has no special flags and no guaranteed behavior beyond the instructions you write in the file.
What to put in CLAUDE.md
Keep it to facts Claude should hold every session: build and test commands, naming and code-style conventions, project layout, and "always do X" rules. Move multi-step procedures into a skill, and move filetype-specific guidance into a path-scoped rule. Do not store secrets, credentials, or data that changes often.
When to use which
- Bootstrapping a new repo or a repo with no CLAUDE.md: run
/init.
- Improving an existing CLAUDE.md: run
/init for suggestions, then edit by hand.
- Verifying which instruction files load: run
/memory.
- A repeatable editing routine: a custom
.claude/commands/*.md command.
Notes on accuracy
The original version of this entry documented a /claudemd-builder command with --init, --template, --update, --validate, --hierarchy, and template/scope flags. None of those exist in Claude Code. Use /init, /memory, @path imports, and .claude/rules/ as documented above.