CLAUDE.md me kya likhein? Copy-paste ready 7 templates aur Do Not rules

“CLAUDE.md me bas tech stack likh dena hai na?”

Shuru me maine bhi yahi socha tha. Astro, TypeScript, Tailwind — likh diya, ho gaya. Khush hokar maine Claude Code ko kaam diya, aur phir wahi galti teen baar dohrayi gayi. Har baar test skip. Jis config file ko haath nahi lagana tha, usi pe haath. “Fix kar diya!” bolta tha, lekin build pass hi nahi hota tha.

Sirf stack wala CLAUDE.md, ek naye joinee ko sirf itna batane jaisa hai ki “yahan Java ka kaam hota hai” aur use floor pe chhod dena. Use yeh pata chal jata hai ki kya cheezein hain, par kaam kaise karna hai uska ek bhi ishaara nahi milta.

Is article me main 7 CLAUDE.md templates rakh raha hoon jo main asli projects me waise hi use karta hoon — copy-paste ready. Yeh stack ka description nahi, “karne ka order” aur “kya nahi karna” pe poora focus karte hain.

मुख्य बातें

• CLAUDE.md me jo cheez sach me kaam karti hai woh tech stack nahi hai, balki do cheezein hain: Working Rules (kaam ka tareeka) aur Do Not (manaa kaam).
• Use ke hisaab se 7 templates ready hain: solo dev, content site, API, team, legacy, automation, monorepo. Apne repo ke sabse close ek template ko chuno aur paste kar do.
• Har template paste karne ke baad, apne project ke liye 3 line ka Do Not add karna zaroori hai. Yahi accidents rokta hai.
• “Jitna lamba likho utna achha” — yeh galatfehmi hai. CLAUDE.md manual nahi, ek operational file hai. Chhote behavior rules jeet’te hain.
• Agar Claude Code wahi galti teen baar repeat kare, to AI ko nahi, apne CLAUDE.md ke granularity ko shak ki nazar se dekho.

Yeh page maine Claude Code complete beginner guide aur CLAUDE.md likhne ki complete guide ke beech ke gap ko bharne wala ek “asli catalog” samajh kar banaya hai. Theory wahan padho, yahan se asli cheez utha kar le jao.

Achha CLAUDE.md jo chupke-chupke karta hai

Ek strong CLAUDE.md koi bahut hoshiyaar baat nahi likhta. Woh bas neeche ke teen “har baar hone wale accidents” ko chupke se khatam karta hai.

• edit ki jagah sahi hoti hai, lekin us project ki apni convention chhoot jaati hai
• fix to ho jata hai, par jo test ya verification chalani thi woh skip ho jaati hai
• apni zimmedaari ka daayra dhundhla hone se exploration zyada faail jaata hai aur time barbaad hota hai

In teeno ko rokne ke liye minimum jo cheezein chahiye, woh yeh hain.

Item	Role	Asar
Tech stack aur main commands	premise set karna	medium
Directory ka role	exploration range kam karna	medium
Project-specific rules	convention manvaana	bada
Working Rules (order)	verification ka miss rokna	bada
Do Not (manaa kaam)	accident rokna	sabse bada

Upar ke do bonus hain, asli asar neeche ke teen ka hai. Khaas kar Working Rules aur Do Not likhte hi Claude Code ekdum kisi alag insaan ki tarah calm ho jata hai. “Kaise aage badhna hai” aur “kya mat karna” — aakhir me yeh naye insaan ko di jaane wali manual hi to hai, na?

Yahan se aage asli templates hain. Code block ke andar ka content seedha apne CLAUDE.md me paste kar do.

1. Solo dev ki web app ke liye

Agar aap akele ek chhoti service chala rahe ho, to pehle yeh.

# Project Overview

Customer-facing Astro site with a small Node API.

## Tech Stack

- Frontend: Astro 5 + TypeScript
- Styling: Tailwind CSS
- Backend: Node.js 22
- Tests: Vitest

## Key Directories

- `site/src/pages/` route entrypoints
- `site/src/components/` reusable UI
- `site/src/content/` blog and docs content
- `scripts/` operational scripts

## Common Commands

- Build: `cd site && npm run build`
- Test: `npm run test`
- Search content: `rg "keyword" site/src/content`

## Working Rules

- Prefer minimal diffs over wide refactors
- Keep copy changes aligned with existing brand tone
- When editing UI, verify mobile width before calling the task done

## Do Not

- Do not rename routes unless required
- Do not delete analytics or SEO fields
- Do not claim deploy success without checking the public URL

Yahan sabse zyada asar stack description ka nahi, Working Rules aur Do Not ki aakhri lines ka hai. “Mobile width check karne se pehle task ko done mat bolo” aur “Public URL dekhne se pehle deploy success mat bolo”. Yeh do lines daalne se pehle, mere saath kai baar yeh accident hua ki PC screen pe theek dikhne wali UI mobile pe poori bahar nikal jaati thi. Jab success condition ko shabdon me baandh do, to yeh problem gayab ho jaati hai.

2. Articles, PDF aur product funnel wali content site ke liye

Yeh blog khud isi tarah ka hai, lekin jin sites pe revenue funnel hota hai, unke liye general dev template bahut kamzor pad jata hai.

# Project Overview

Multilingual Claude Code content site with free PDF lead magnet, Gumroad products, and consultation funnel.

## Business Goal

- Priority 1: free PDF registration
- Priority 2: Gumroad product clicks and purchases
- Priority 3: consultation inquiries

## Content Rules

- Every new article must include internal links
- Every article must include free PDF, product, and consultation CTA paths
- Use the same slug across all locales when publishing multilingual posts

## Verification Workflow

1. Build the site
2. Deploy the site
3. Open the public URL
4. Check mobile layout
5. Confirm CTA destination links

## Do Not

- Do not publish only one locale when the article requires all locales
- Do not treat build success as release success
- Do not prioritize pageviews over conversion path quality

Point hai Do Not ki aakhri line — “Pageviews se zyada conversion funnel ki quality ko priority do” — jise saaf likha gaya hai. Yeh na likho to Claude Code “padha jaane wala article” banane ki taraf jhuk jata hai aur aise pages bhar deta hai jahan asli CTA patla rehta hai. Business goal ko priority deke sabse upar rakhne bhar se output ki direction ekdum badal gayi.

3. Backend API ke liye

Jis API me consistency hi sab kuch hai, wahan “fix karne se pehle padho” aur “fix karne ke baad shabdon me batao” ko force karo.

# Project Overview

Internal TypeScript API for billing and account management.

## Tech Stack

- Node.js 22
- Fastify
- PostgreSQL + Prisma
- Zod
- Vitest

## Directory Map

- `src/routes/` HTTP handlers
- `src/services/` business logic
- `src/repositories/` DB access
- `src/lib/` shared utilities

## Required Workflow

1. Read the route or service first
2. Check for existing schema and tests
3. Make the smallest safe change
4. Run unit tests or type checks
5. Summarize risk in plain English

## Do Not

- Do not bypass Zod validation
- Do not edit migrations casually
- Do not touch billing logic without tests

Ismein mujhe sabse zyada pasand hai Summarize risk in plain English wali line — yaani “risk ko aam bhasha me summarize karo”. Yeh daalne se Claude Code sirf “fix kar diya” pe nahi rukta, balki khud bata deta hai: “yeh change billing logic ke boundary ke paas hai, isliye monthly batch pe asar pad sakta hai” — impact ka daayra apne aap likh deta hai. Review ka pehla kadam ekdum aasaan ho jata hai.

4. Team development ke liye

Team me asli pareshani productivity ki kami nahi, balki review karne me mushkil diff hota hai. Use pehle hi rok lo.

# Team Workflow

- Work on the current branch only
- Do not revert changes you did not make
- Call out uncertainty before making broad edits
- Prefer review-friendly patches over large rewrites

## Pull Request Expectations

- Mention user-facing behavior changes
- Mention test coverage gaps
- Flag security, permissions, and deploy risks first

## Approval Boundaries

- Ask before deploy commands
- Ask before editing CI, infra, or secrets-related files
- Ask before changing lockfiles unless required

Do not revert changes you did not make (jo change aapne nahi kiya use apne aap mat palto) — chhoti baat hai par bahut kaam karti hai. AI “saath me” paas wale code ko “saaf” karne ke chakkar me kisi aur ke jaan-boojh kar likhe code ko ulta deta hai. Approval boundaries ke baant-baant ko maine Approval / Sandbox settings guide me detail me likha hai, isliye team ke liye woh bhi saath me dekh lena.

5. Legacy code ke liye

Purane code ke modification me “saaf-suthrapan” se zyada “na todna” hi sahi hota hai.

# Legacy Repo Notes

- This codebase has inconsistent patterns
- Prefer compatibility over elegance
- Preserve behavior unless the task explicitly allows change

## Investigation First

1. Explain current behavior
2. Locate the smallest responsible file set
3. Identify risks before editing

## Do Not

- Do not rename public methods casually
- Do not introduce new frameworks
- Do not rewrite files only to match modern style

Prefer compatibility over elegance (sundarta se zyada compatibility ko priority do). Legacy projects me aksar yahi sabse important ban jata hai. Chhod do to Claude Code neyak niyat se bolta hai “main isse modern style me rewrite kar deta hoon” — par legacy me wahi accident ka darwaza hai. Do not rewrite files only to match modern style ko Do Not me daal kar us neyak niyat pe dhakkan laga do.

6. Automation aur operations scripts ke liye

Email bhejna, deploy, external API write — side effects wale scripts ko chhuana ho, to pehla candidate yeh hai.

# Automation Rules

- Dry-run whenever the script supports it
- Log intended side effects before executing
- Prefer idempotent operations
- Keep secrets out of logs and generated files

## Required Checks

- Confirm environment variables used
- Confirm target environment
- Confirm output path or destination service

## Do Not

- Do not send emails, deploy, or publish without explicit approval
- Do not delete generated assets unless cleanup is requested

Log intended side effects before executing (execute karne se pehle, kya gadbad karne ja rahe ho woh likh do) — yahi safety valve hai. “Ab main production me 120 emails bhejne ja raha hoon” pehle hi declare karwa do, to insaan “ruko” bol sakta hai. Dry-run whenever the script supports it ke saath set me, jo operation ulta nahi sakta us pe hamesha ek cushion lag jaata hai.

7. Monorepo ke liye

Agar ek hi jagah multiple apps aur shared packages rehte hain, to “kaunsa package zimmedaar hai” pehle likh do.

# Monorepo Map

- `apps/web/` customer app
- `apps/admin/` internal admin tool
- `packages/ui/` shared UI
- `packages/config/` lint and tsconfig presets

## Ownership Rules

- Web UI work should stay inside `apps/web/` unless the task clearly needs a shared component change
- Shared package edits require checking downstream usage
- Avoid version or config churn unless necessary

## Verification

- Run the narrowest relevant build or test command first
- Describe cross-package impact before editing shared code

Ownership Rules likhne bhar se cross-cutting edit ke accidents kaafi kam ho jaate hain. apps/web/ ka chhota fix hona tha, par pata hi nahi chala kab packages/ui/ ke shared component me haath chala gaya aur apps/admin/ tak ko leke toot gaya — yeh monorepo ka typical accident hai. Zimmedaari ka daayra pehle declare karwa kar, shared code chhuane se pehle “downstream impact bata do” ek line daal do.

Kaunsa template chunein

7 ek saath dekh kar confuse ho jaate hain, isliye selection ko ek-ek line me rakh deta hoon.

• UI ya product central ho → solo dev template
• articles, PDF, Gumroad funnel ho → content site template
• consistency hi sab kuch ho → API template
• coordination cost zyada ho → team ya monorepo template
• accident cost zyada ho → legacy ya automation template

Saare 7 ko mix karne ki zaroorat nahi. Ulta mix karne se lamba ho jata hai aur asar gir jata hai. Ek ko base banao, aur sirf woh rules add karo jo aapke project me behavior badalte hain. Yahi sahi raasta hai.

CLAUDE.md me hone wali 4 common galtiyan

Jo landmines maine asli me dabaye, woh waise hi share kar raha hoon.

Galti 1. Company wiki ki tarah lamba likhna. “Description jitna lamba utna achha” — yeh poori tarah galatfehmi nikli. CLAUDE.md manual nahi, operational file hai. Lambe background explanation se chhote behavior rules kai guna zyada kaam karte hain. Yeh padhne wala insaan nahi, AI hai — yeh baat hum aksar bhool jaate hain.

Galti 2. Sirf commands likhna, workflow na likhna. Sirf npm run test likhne se, billing chhuo to test zaroor chalao kahin zyada strong hota hai. Command sirf “existence” batata hai. Workflow “kab use karna hai” tak batata hai.

Galti 3. Do Not section hi na hona. Yeh sabse zyada nuksan wali baat hai. .env ko mat chhuo, public URL check kiye bina deploy success mat bolo, force push mat karo. Ek hi line ek poori raat ka accident bacha leti hai. Do Not section sajaawat nahi, insurance hai.

Galti 4. Update na karna. Agar Claude Code wahi galti teen baar repeat kare, to aksar AI ki galti nahi, CLAUDE.md ki taraf se granularity kam hai. Tab daantne ke bajaye ek line ka rule add karo. CLAUDE.md likh kar khatam nahi hoti, woh paalne-badhane wali file hai.

अक्सर पूछे जाने वाले सवाल

Q. CLAUDE.md ko project me kahan rakhein? A. Repo ke root me CLAUDE.md naam se rakh do, Claude Code khud-ba-khud use load kar leta hai. Monorepo me har package ke neeche bhi rakh sakte ho, aur jo paas hota hai use priority milti hai. Asli me rakhna aur woh kaam kar raha hai ya nahi check karna — bas yeh do commands.

# Project ke root me bas rakh do. Claude Code start hote hi khud load karega
cat > CLAUDE.md <<'EOF'
# Project
(upar wala template waise hi paste karo)
EOF

# Kaam kar raha hai ya nahi check: rules wapas poochho
claude -p "is project ke CLAUDE.md me jo Do Not hain unme se 3 batao"

Detail me placement rules ke liye official Claude Code documentation dekh lo.

Q. Hindi ya Hinglish me likhne se theek se kaam karta hai? A. Karta hai. Main Do Not aur workflow kabhi-kabhi local bhasha me bhi likhta hoon. Lekin template khud English me rakho to overseas members aur samples ke saath align karna aasaan rehta hai, isliye is article me maine English base rakha hai. Matlab samajh aa jaye to dono me koi dikkat nahi.

Q. Lamba CLAUDE.md aur chhota CLAUDE.md, kaunsa behtar? A. Chhota wala. Andaaza yeh ki ek screen me aa jaye. Lamba hone lage to yeh signal hai ki use alag document me nikal do. CLAUDE.md me sirf “behavior badalne wale rules” rehne do.

Q. Template paste karne ke baad sabse pehle kya add karein? A. Apne project ke liye 3 line ka Do Not. “Jo file chhoona nuksandeh hai”, “jo operation hua to dikkat hai”, “jo jhooth bola to dikkat hai (jaise: check kiye bina success report)” — har ek ko ek line. Yahi sabse zyada return dene wala addition hai.

Q. CLAUDE.md aur permissions (permission settings) me kya farak hai? A. CLAUDE.md “request/policy” hai, permissions ek “force wali allow-list” hai. Do Not ko sach me manvaana ho to dono ko saath use karo. Permission ka baant-baant Claude Code complete beginner guide me bhi cover kiya hai.

Maine asli me try karke kya paaya

Jab CLAUDE.md me sirf tech stack likha tha, tab main Claude Code ke har output pe ghabraata tha — “is baar dhang se test chalayega kya?”

Working Rules aur Do Not add karne ke baad, woh ghabrahat lagbhag gayab ho gayi. Khaas kar “public URL dekhne se pehle deploy success mat bolo” wali ek line ka asar saaf numbers me dikhta hai. Pehle “deploy ho gaya” ke baad asli me 404 — yeh mahine me kai baar hota tha, par add karne ke baad zero ho gaya.

Conclusion simple hai. CLAUDE.md AI ko hoshiyaar banane wali file nahi, AI se accident na karwane wali file hai. Stack add karne se zyada, 3 line ka Do Not add karna feel me 10 guna zyada kaam karta hai. Pehle apne repo ke sabse close ek template paste karo, aur sirf 3 line ka Do Not add karke dekho.

CLAUDE.md ki design philosophy ko aur gehrai me samajhna ho to CLAUDE.md likhne ki complete guide dekho, aur AI ko kaam safely saunpne wale poore “scaffold” ki baat ke liye AI ko “sab kuch kar dena” bolna accident ki jad hai padho. Template collection aur config examples ek jagah haath me rakhna ho to free Claude Code Quick Reference Cheatsheet aur hooks-permissions tak ghusi hui The Complete Claude Code Setup & Configuration Guide kaam aati hain. Saara teaching material ek baar dekhna ho to teaching materials list se, aur team standardization tak saath me set karna ho to consultation pe aao. Registration ke baad thank-you page pe milte hain.