Claude Code के लिए CLAUDE.md starter template: existing codebase rules

CLAUDE.md हर session की repeated briefing कम करता है

Existing codebase में Claude Code चलाते समय problem अक्सर model की capability नहीं होती। Problem यह होती है कि project के local rules हर बार फिर से बताने पड़ते हैं: package manager कौन सा है, app folder कहां है, generated files कौन सी हैं, कौन से commands risky हैं, और done का मतलब क्या है।

CLAUDE.md इसी context को persistent instruction की तरह रखता है। Official Claude Code memory docs बताते हैं कि यह file session start पर load होती है। लेकिन यह hard enforcement नहीं है। Commands या paths सच में block करने हों तो settings, permissions, hooks, CI और repo rules चाहिए। Secrets और deployments के लिए security docs भी पढ़ें।

यहां harness का मतलब agent के लिए practical safety scaffold है। पहले दिन बड़ा handbook मत बनाइए। छोटी file बनाइए जो next repeated mistake रोक सके। Related patterns के लिए CLAUDE.md templates और Claude Code permissions guide देखें।

Copy-paste CLAUDE.md template

पहली version में project snapshot, commands, boundaries, quality rules और definition of done रखें।

# CLAUDE.md

## Project snapshot
- Product: content site and paid template store
- Stack: Astro, TypeScript, MDX, npm
- Main app: site/
- Source articles: site/src/content/blog*/
- Owner voice: practical, evidence-based, no hype

## Commands
- Install dependencies: cd site && npm install
- Start local dev server: cd site && npm run dev
- Build check: cd site && npm run build
- Search fast: rg "keyword" site/src
- Inspect git state: git status --short

## Working rules
- Read existing files before editing.
- Keep changes scoped to the requested slug or feature.
- Do not edit .env, dist, generated reports, or unrelated locale files.
- Preserve pubDate, category, tags, author, lang, and heroImage unless they are broken.
- Ask before destructive git operations, production deploys, or secret rotation.

## Article quality
- Japanese canonical articles should be 4000-6000 characters excluding code.
- Include at least three real use cases.
- Include concrete pitfalls and how to avoid them.
- Include runnable code or config examples, not pseudocode.
- Check official docs when the topic may have changed.

## Definition of done
- The requested files are edited.
- Code fences and JSON/YAML examples are valid.
- Links to internal pages and official docs are present.
- Verification commands have run or skipped checks are explained.
- Remaining risks are stated in the final message.

इसे repo root मेंCLAUDE.mdके रूप में रखें। Personal notes के लिएCLAUDE.local.mdबेहतर है। अगर repo में पहले सेAGENTS.mdहै, तो rules duplicate न करें; छोटाCLAUDE.mdबनाकर common file import करें और Claude Code specific rules जोड़ें।

Dangerous actions को settings में रखें

CLAUDE.mdमें “push मत करना” लिखना helpful है, पर यह block नहीं करता। Critical boundary settings, CI, branch protection या deployment approval में होनी चाहिए।

{
  "permissions": {
    "allow": [
      "Read",
      "Edit(site/src/content/blog/**)",
      "Bash(rg:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(node:*)"
    ],
    "deny": [
      "Bash(git reset:*)",
      "Bash(git checkout --:*)",
      "Bash(git push:*)",
      "Bash(npm publish:*)",
      "Edit(.env*)",
      "Edit(reports/**)"
    ]
  }
}

Personal guardrail के लिए.claude/settings.local.jsonऔर shared default के लिए.claude/settings.jsonuse करें। Real repo में copy करने से पहले official settings docs से latest schema check करें। CLAUDE.md intent और context देता है; settings execution boundary देती हैं।

3 practical use cases

Use case	CLAUDE.md में क्या लिखें	Benefit
Localized article maintenance	target slug, locale list, frontmatter preserve rules, body length, CTA, verification	missing languages, English leftovers, broken CTAs और stale dates कम होते हैं
Small SaaS bug fix	editable folders, test command, DB approval rule, logging expectation	scope creep और risky migration घटते हैं
Team code review	severity, file, line, impact, reproduction, test gap	review actionable बनता है

Localized content में file मौजूद होना काफी नहीं है। Body wrong language में रह सकती है। Locale directories, internal link paths और description limit लिखने से Claude Code group को सही तरह पढ़ता है।

SaaS bug fix में scope सबसे important है। छोटा UI bug billing, auth या migration तक नहीं जाना चाहिए। “पहले files पढ़ो, smallest surface patch करो, matching test run करो, DB change से पहले पूछो” जैसी line ज्यादा useful है।

Team review में output format तय करें। severity, path, line, user impact, reproduction और missing test मांगें। Scripted review के लिए official CLI reference देखें।

Common pitfalls

पहला pitfall है file को बहुत लंबा बना देना। 300 line policy context खाती है और कम follow होती है। Frequent rules ही रखें। Path-specific बात अलग rule या docs में डालें।

दूसरा pitfall है secrets लिखना। API keys, customer names, private dashboard URLs और unpublished revenue numbersCLAUDE.mdमें न डालें। सिर्फ handling rule लिखें: secrets env vars में हैं, print नहीं होंगे, sensitive files open करने से पहले पूछना है।

तीसरा pitfall है stale commands। Yarn से npm, Jest से Vitest या Next.js से Astro migration के बाद file update नहीं हुई तो Claude Code confidently wrong command चलाएगा। Tooling बदलते हीCLAUDE.mdupdate करें।

चौथा pitfall है verification receipt न मांगना। Final answer में commands, result, changed files, checked links और remaining risks होने चाहिए। यही छोटे publishing mistakes पकड़ता है।

Small rollout sequence

पहले इस template से 30 line file बनाएं। फिर तीन low-risk tasks पर use करें: content edit, UI copy change, code review। जो actual mistake repeat होती है, सिर्फ वही rule add करें। Hard boundary को settings, CI, branch protection या deploy approval में move करें।

Revenue site में CTA भी quality है। Products, checkout, training और consultation form broken नहीं होने चाहिए। इसलिए done criteria में CTA check रखें। Individual builders ClaudeCodeLab products से templates और checklists ले सकते हैं। Teams को permissions, review gates, training और repo-specificCLAUDE.mdचाहिए तो Claude Code training and consultation practical next step है।