Claude Md Generator

CLAUDE.md Generator

Read the codebase. Write a CLAUDE.md that tells Claude exactly what it needs: no more, no less.

Critical rule: A good CLAUDE.md is under 100 lines. It contains only information Claude cannot derive from reading the code itself. Do not auto-write the file: always show the draft and wait for user approval first.

Code snippet rule: Never include inline code examples in CLAUDE.md. Instead use file.ts:42 references. Code in CLAUDE.md wastes tokens and goes stale.

Step 1: Detect Mode

Determine which of three modes to run:

create: No CLAUDE.md exists. Write one from scratch. update: A CLAUDE.md exists. Improve it without discarding custom content. audit: Score all CLAUDE.md files in the project A-F and output a quality report. If the user says "audit", "check", "review", or "grade" my CLAUDE.md, run audit mode.

# Discover ALL CLAUDE.md locations
find . -name "CLAUDE.md" -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null
ls ~/.claude/CLAUDE.md 2>/dev/null && echo "Global CLAUDE.md found"
ls .claude.local.md 2>/dev/null && echo ".claude.local.md found"

If multiple CLAUDE.md files are found: list them. Ask: "Found CLAUDE.md in [locations]. Should I update all of them or just [root]?"

Step 2: Audit Mode (skip to Step 3 if create/update)

For each CLAUDE.md found, score it A-F using this rubric:

Score: 90-100 = A, 70-89 = B, 50-69 = C, 30-49 = D, 0-29 = F

Present as a table:

## CLAUDE.md Audit Report

| File | Score | Grade | Top Issues |
|------|-------|-------|-----------|
| ./CLAUDE.md | 72 | B | Missing gotchas section, test command outdated |
| ./packages/api/CLAUDE.md | 45 | D | No commands, 340 lines (too long), stale arch notes |

**Overall: B (72/100)**

Issues found:
- ./packages/api/CLAUDE.md: 340 lines: well over the 100-line target
- ./packages/api/CLAUDE.md: Test command references `jest` but package.json uses `vitest`
- ./CLAUDE.md: No Gotchas section: most valuable section is missing

After the report, ask: "Want me to fix any of these? (all / just root / specify)"

If user says yes, continue to Step 3 for each file they want fixed.

Step 3: Scan Project Structure

# Project type and package manager
ls package.json yarn.lock pnpm-lock.yaml bun.lockb requirements.txt pyproject.toml Cargo.toml go.mod 2>/dev/null

# Top-level directory structure
find . -maxdepth 2 -type d \
  | grep -v node_modules | grep -v .git | grep -v __pycache__ \
  | grep -v ".next" | grep -v dist | grep -v build | sort

Step 4: Extract Build and Test Commands

# npm/yarn/pnpm/bun scripts
cat package.json 2>/dev/null \
  | python3 -c "
import sys, json
d = json.load(sys.stdin)
for name, cmd in d.get('scripts', {}).items():
    print(f'{name}: {cmd}')
"

# Python, Go, Rust Makefiles
cat Makefile 2>/dev/null | grep -E "^[a-z].*:" | head -20

# Go
cat go.mod 2>/dev/null | head -5

# Rust
cat Cargo.toml 2>/dev/null | grep -E "^\[" | head -10

Identify the exact commands for: build, test (all), test (single file/name), dev server, lint/typecheck. Note any env vars required to run them.

Step 5: Find Code Style and Gotchas

# Import aliases (most commonly missed)
python3 -c "
import json, sys
try:
    d = json.load(open('tsconfig.json'))
    paths = d.get('compilerOptions', {}).get('paths', {})
    if paths: print('Import aliases:', json.dumps(paths, indent=2))
except: pass
" 2>/dev/null

# Environment variables required
cat .env.example 2>/dev/null | grep -v "^#" | grep -v "^$" | head -20

# Auto-generated files (must not be edited)
find . -path "*/node_modules" -prune -o -name "*.ts" -print \
  | xargs grep -l "DO NOT EDIT\|@generated\|Generated by" 2>/dev/null | head -5

# Test setup requirements
cat jest.config.js jest.config.ts vitest.config.ts 2>/dev/null | head -30

# Database/migration setup
ls migrations/ prisma/ drizzle/ db/ 2>/dev/null

What counts as a Gotcha (include these, skip everything else):

• Files that are auto-generated (must not edit)
• Env vars required BEFORE tests run
• Non-default import alias mappings
• Test commands that require a running service
• Known intentional quirks (workarounds, not bugs)

Step 6: Generate CLAUDE.md Draft with Gemini

Compile all findings and generate the draft:

cat > /tmp/claude-md-request.json << 'ENDJSON'
{
  "system_instruction": {
    "parts": [{
      "text": "Write a CLAUDE.md file for a software project. Rules: (1) Under 100 lines total. (2) Only include what Claude cannot derive from reading the code. (3) No inline code examples: use file.ts:42 references instead. (4) Sections: Commands, Code Style (only non-defaults), Testing (only if setup needed), Gotchas (required: what trips people up). Skip any section that has nothing non-obvious to say. (5) All commands in code blocks. (6) Preferred order: short Project Overview (1-2 sentences, only if non-obvious), Commands, Architecture (only non-obvious structure), Code Style, Testing, Gotchas. (7) Do not use em dashes. (8) Output only the CLAUDE.md content, no commentary."
    }]
  },
  "contents": [{
    "parts": [{
      "text": "PROJECT_ANALYSIS_HERE"
    }]
  }],
  "generationConfig": {
    "temperature": 0.3,
    "maxOutputTokens": 2048
  }
}
ENDJSON

curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d @/tmp/claude-md-request.json \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"

Replace PROJECT_ANALYSIS_HERE with findings from Steps 3-5.

For large projects (50+ files): Add a @path pointer at the bottom of CLAUDE.md instead of inline detail:

## Extended Reference
See @docs/ai-context/architecture.md for full module map.
See @docs/ai-context/testing.md for integration test setup details.

Write the referenced files to docs/ai-context/ with the detail that would not fit in 100 lines.

Step 7: Self-QA

Before presenting the draft, check:

• Under 100 lines (count: echo "$CONTENT" | wc -l)
• No inline code examples (only file.ts:42 references or shell commands)
• All commands in code blocks and runnable as-is
• Gotchas section present with at least one real entry
• No section that says only things obvious from the files
• No em dashes
• No marketing words or filler phrases ("This project uses React to...")
• Import aliases documented if they exist
• Auto-generated files marked "do not edit" if they exist

If any check fails, revise before presenting.

Step 8: Present Draft and Wait for Approval

Never write the file without user approval.

Present the draft in a code block:

## Draft CLAUDE.md ([N] lines)

[full draft content here]

---
Write this to CLAUDE.md? (yes / edit first / cancel)

If user says yes: write the file, then confirm: "CLAUDE.md written ([N] lines). Sections: [list of ## headers]."

If user says edit first: apply their edits, re-show the draft.

If user says cancel: stop.

What NOT to Include

• Language/framework version ("This is a TypeScript project")
• How the framework works (Claude already knows React, FastAPI, etc.)
• List of all dependencies
• Style rules the linter already enforces (indent size, quote style)
• Content that duplicates README.md
• Inline code examples or multi-line snippets
• Anything that would be identical for any project using the same stack