Claude Code first repo audit checklist: पहली edit से पहले codebase map करें

मौजूदा repository में पहली Claude Code session edit से शुरू नहीं होनी चाहिए। पहले map बनना चाहिए। Claude Code तेज पढ़ता है, लेकिन speed तभी safe है जब entry points, protected areas, proof commands और business paths साफ हों।

search intent सीधा है: beginner real codebase में Claude Code इस्तेमाल करना चाहता है, पर control नहीं खोना चाहता। अभी feature बनाना goal नहीं है। 20 मिनट में scope, risk, verification और revenue CTA visible बनाना goal है।

संबंधित लेख: claude-code-getting-started-complete, claude-code-existing-codebase-map, claude-code-harness-lite-workflow.

पहले edit से पहले यह ढांचा क्यों जरूरी है

Claude Code तब सबसे अच्छा काम करता है जब task की boundary साफ हो। अच्छी boundary बताती है कि कौन से files पढ़ने हैं, कौन से edit हो सकते हैं, कौन से operations नहीं चलाने हैं, और work खत्म होने का proof क्या है। boundary न हो तो beginner prompt भी बड़ा rewrite बन सकता है और content change free PDF, Gumroad या consultation path तोड़ सकता है।

यह pattern revenue work में भी मदद करता है क्योंकि technical proof और reader proof को साथ रखता है। local build pass होने पर भी अगर page reader को गलत product पर भेज रहा है, तो काम पूरा नहीं है। scope, command, public URL और CTA record करने से अगली बार memory पर नहीं, evidence पर improvement होता है।

काम में इस्तेमाल होने वाला workflow

1. पहले केवल README, package.json और routing entry points पढ़ें
2. generated, billing, auth, migrations और .env को protected area लिखें
3. पहली editable surface को तीन files या कम रखें
4. patch से पहले एक proof command चुनें
5. content या landing page में free PDF, Gumroad और consultation links भी audit करें

स्थिति	सुरक्षित कदम	प्रमाण
Astro content site	article बनाने से पहले content collection, slug rule, heroImage और CTA pattern देखें। body और paid route दोनों audit में आते हैं।	build, diff, URL
React dashboard	छोटे layout defect में component, CSS और screenshot proof तक सीमित रहें। auth और billing protected रहें।	screenshot, test
API repository	route path और test command पहले पढ़ें। database migrations और secrets पहली task से बाहर रखें।	log, command, handoff

पहला pass छोटा रखें। audit का output बड़ा report नहीं, decision होना चाहिए। अगर 20 मिनट बाद भी decision unclear है, तो safe next step edit शुरू करना नहीं, बल्कि एक और file पढ़ना है।

कॉपी करने लायक prompt और code

पहली edit से पहले इस repository का audit करें। अभी edit न करें। entry files, protected areas, safe files, smallest proof command, public URL और CTA checks लौटाएं।

const audit = {
  repo: "customer-portal",
  intent: "first safe Claude Code session",
  scope: ["README.md", "package.json", "src/routes"],
  protected: [".env", "billing/", "migrations/"],
  proof: ["npm.cmd run build", "git diff --stat"],
};

export function readyForFirstEdit(report) {
  return report.scope.length > 0 &&
    report.protected.length > 0 &&
    report.proof.some((command) => command.includes("build"));
}

console.log(readyForFirstEdit(audit));

code जानबूझकर छोटा है। यह operating idea को checkable object में बदलता है: scope है, protected areas हैं और proof command जुड़ा है। आप इसे article publishing, app development, debugging या team handoff के लिए बदल सकते हैं।

तीन असली उदाहरण

Astro content site

article बनाने से पहले content collection, slug rule, heroImage और CTA pattern देखें। body और paid route दोनों audit में आते हैं।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

React dashboard

छोटे layout defect में component, CSS और screenshot proof तक सीमित रहें। auth और billing protected रहें।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

API repository

route path और test command पहले पढ़ें। database migrations और secrets पहली task से बाहर रखें।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

जिन गलतियों से बचना है

• शुरू में fix everything कहना audit और implementation मिला देता है।
• local build काफी नहीं है अगर public URL या CTA गलत page पर जा रहा है।
• protected areas लिखे बिना helpful edit भी incident बन सकती है।

दूसरी subtle failure localization drift है। English article सही product path समझा सकता है, लेकिन दूसरे locale में पुराना CTA रह सकता है। इसलिए public check में हर भाषा का h1, opening body और CTA language देखना चाहिए, केवल frontmatter lang नहीं।

reader को free PDF, Gumroad और consultation तक कैसे ले जाएं

अगर reader को अभी commands की आदत चाहिए, तो free cheatsheet से शुरू कराएं। setup, permissions, CLAUDE.md, hooks, MCP या CI/CD में रुकावट हो तो Setup Guide सही paid next step है। review, debugging और refactor prompts बार-बार लिखने पड़ते हों तो 50 Prompt Templates भेजें। team rollout, workflow design या revenue path चाहिए तो consultation पर भेजें। सारे विकल्प देखने के लिए products खोलें।

हर reader को तुरंत paid product पर न भेजें। beginners को पहले low-friction PDF चाहिए। जो prompts दोहराते हैं वे templates के करीब हैं। permissions, CLAUDE.md, hooks, MCP या CI/CD में अटके readers Setup Guide के करीब हैं। team और process सवाल consultation के करीब हैं।

publish से पहले और बाद में क्या जांचना है

इस लेख की verification केवल HTTP 200 नहीं है। h1, शुरुआत का body text, heroImage, internal links, Gumroad links और consultation path एक ही reader intent से जुड़े होने चाहिए।

multilingual publishing में Japanese, English, Chinese, Korean, Spanish, French, German, Portuguese, Hindi और Indonesian अलग-अलग verify करें। slug match हो सकता है पर body stale हो सकती है। mobile screenshot opening paragraph और CTA साथ दिखाता है, इसलिए गलती जल्दी मिलती है।

अगले नंबर जिन्हें देखना चाहिए

अगले metrics हैं PDF starts, Gumroad clicks, products visits, training visits, search source, country mix और article-to-CTA click rate। PV बढ़े लेकिन Gumroad click न बढ़े तो product match मजबूत करें। technical article से consultation visits बढ़ें तो reader को शायद workflow design चाहिए।