How to create a CLAUDE.md file: 4 approaches compared (manual, CLI, generators, and ContextKit)

A good CLAUDE.md file can transform how useful Claude Code is on a project. A bad one — or none at all — leaves you fighting generic output that doesn't match your codebase conventions.

The problem is that there's more than one way to create one, and the options have different trade-offs depending on your situation. This guide compares four approaches honestly: writing by hand, using Claude Code's built-in /init command, using a web form generator, and using ContextKit.

No approach is universally best. The right one depends on whether you already have Claude Code running, how complex your stack is, and whether you need to export configs for multiple AI tools.

What makes a CLAUDE.md actually useful

Before comparing approaches, it's worth being clear about what a CLAUDE.md needs to do. It's a context file that Claude Code reads at the start of every session. A useful one typically covers:

• Tech stack and key dependencies
• Project structure and how the codebase is organized
• Coding conventions (naming, file organization, patterns to follow or avoid)
• How to run tests and linting
• Anything Claude should never do in this project

The goal is to make Claude's default behavior match your project's actual conventions without you having to re-explain things in every prompt.

Approach 1: Write it manually

Writing your CLAUDE.md from scratch is the most straightforward option. You open a text editor and write markdown. No tools required.

How it works

You start with a blank file, usually at your project root, and write sections covering your stack, file structure, coding style, test setup, and any rules you want Claude to follow. Most developers end up with something between 50 and 200 lines.

Pros

• Full control — you include exactly what matters and nothing else
• Forces you to think clearly about your own conventions, which often improves consistency
• Works for unusual or highly custom setups that generators can't anticipate
• No dependency on any external tool

Cons

• Time-consuming — a thorough file takes 30-60 minutes to write well
• Easy to miss important sections if you don't know what Claude looks for
• No validation — you won't know if your instructions are clear until Claude starts making mistakes
• No export to other AI tool formats

Best for

Teams with highly specific setups, monorepos with unusual structures, or anyone who wants to deeply understand what they're putting in the file. Also worth considering if you're already an experienced Claude Code user who knows which sections matter most for your workflow.

Approach 2: Claude Code's built-in /init command

Claude Code ships with a /init command that reads your codebase and generates a CLAUDE.md automatically. This is often the most overlooked option because many developers don't know it exists.

How it works

Open Claude Code in your project directory and run:

/init

Claude scans your project files — package.json, directory structure, existing config files, test setup — and generates a CLAUDE.md based on what it finds. The whole process takes under a minute.

Pros

• Free and built-in — no extra accounts or tools needed
• Reads your actual codebase, so the output reflects reality rather than what you describe
• Fast — useful when you want something working immediately
• Good starting point that you can then edit

Cons

• Output quality is basic — it captures structure but often misses conventions and style preferences
• No scoring or validation of the output
• Can't export to Cursor, Codex, or Gemini CLI formats
• Requires Claude Code to already be installed and running
• May infer incorrect conventions if your codebase is inconsistent

Best for

Quick starts. If you're setting up Claude Code on an existing project and want something working in under two minutes, /init is the right move. Treat the output as a rough draft you refine over time.

Approach 3: Web form generators (codewithclaude.net and similar)

Several websites have built form-based CLAUDE.md generators. You fill in fields about your stack and preferences, and they produce a file you can copy.

How it works

You visit the site, answer questions about your tech stack, language preferences, and project type, then download or copy the generated CLAUDE.md. No installation required.

Pros

• Free and requires no login
• Works without Claude Code installed
• Guided — the form prompts you to think about sections you might skip manually

Cons

• Static forms — they can't read your actual codebase, so output is based entirely on what you describe
• No scoring or quality analysis of the generated output
• Output quality is limited by how generic the form questions are
• No versioning, shareable configs, or multi-tool export
• The file you get is a template with your answers filled in, not a config derived from your project

Best for

Starting from zero when you have no Claude Code installation yet and want something quick to paste into a new project. It's a step up from a blank file, but you'll likely need to do significant editing afterward.

Approach 4: ContextKit

ContextKit is a 5-step wizard that generates a CLAUDE.md (and config files for other AI tools) and includes a separate analyzer that scores your existing file.

How it works

The wizard walks you through five structured sections: project overview, tech stack, code style and conventions, workflow and testing setup, and custom rules. At the end you can export in four formats:

• CLAUDE.md — for Claude Code
• .cursorrules — for Cursor
• AGENTS.md — for GitHub Copilot and Codex
• GEMINI.md — for Gemini CLI

The analyzer takes an existing CLAUDE.md (paste or upload) and returns a 0-10 score with specific feedback on what's missing or vague.

Pros

• Structured wizard covers all the sections that actually affect Claude's behavior
• Four export formats from a single session — useful if your team uses multiple AI tools
• Analyzer gives concrete improvement suggestions, not just a generic score
• Shareable configs with README badges so teammates can find and use the same config
• Works in any browser, no installation needed

Cons

• Web-based — it can't read your local repository directly, so you describe your setup rather than having it inferred
• Direct codebase scanning (like /init does) is not available yet
• Takes slightly longer than /init (around 3-5 minutes for the full wizard)

Best for

Projects where you need configs for more than one AI tool, teams where multiple people need to use the same config, anyone who wants to score and improve an existing file, or situations where you want a more thorough config than /init produces without writing everything from scratch.

Side-by-side comparison

Feature	Manual	Claude Code /init	Web form generators	ContextKit
Reads your actual codebase	No	Yes	No	No (wizard-based)
No installation required	Yes	No	Yes	Yes
Scores or validates output	No	No	No	Yes (0-10 analyzer)
Multi-tool export	No	No	No	Yes (4 formats)
Shareable configs	No	No	No	Yes
Covers all standard sections	If you know them	Partially	Partially	Yes (structured wizard)
Cost	Free	Free (included)	Free	Free
Time to working file	30-60 min	Under 1 min	5-10 min	3-5 min

Which approach should you use

Here's a practical guide based on common situations:

You just installed Claude Code and want something working now

Run /init. It takes under a minute, reads your actual project, and gives you something Claude Code can work with immediately. You can improve it later with the analyzer.

You're starting a new project from scratch

Use ContextKit's wizard. You don't have a codebase to scan yet, so /init won't help much. The wizard guides you through all the sections worth covering and produces a file you can commit alongside your first code.

You use Cursor, Codex, or Gemini CLI alongside Claude Code

Use ContextKit. It's the only option that generates all four config formats in one session, so you don't have to maintain separate files manually.

You already have a CLAUDE.md but it doesn't seem to help

Run it through the ContextKit analyzer. It'll tell you what's missing or too vague, which is faster than diagnosing the problem yourself.

Your project has an unusual or highly custom setup

Write manually, or use ContextKit as a starting point and heavily customize it. Generators work well for standard setups but can't account for everything.

Your whole team needs to use the same config

Use ContextKit's shareable config feature so everyone is working from the same file with a stable link. This is useful for onboarding new developers.

A note on output quality

Whichever approach you use, the first version of your CLAUDE.md is rarely the best version. The most effective files are ones that get updated as you learn what Claude actually needs to work well in your project.

Pay attention to recurring mistakes Claude makes — those usually point to missing or unclear sections in your config. Add them when you notice them, not all at once upfront. A CLAUDE.md that grows organically alongside your project tends to be more accurate than one written in a single session.

If you want a baseline to start from, generate one with ContextKit and run it through the analyzer before committing it to your repo.