Claude Code से पुराने repo में पहली edit सुरक्षित बनाने का तरीका

अभी-अभी मुझे जो company repo मिला था, उसमें मैंने पहले ही दिन गड़बड़ कर दी।

मैंने Claude Code से बस इतना कहा, “पूरा code एक बार पढ़ लो और जो ठीक करने लायक लगे, कर दो।” आधे घंटे बाद 23 files बदल चुकी थीं। बदलाव खराब नहीं थे। लेकिन production का deploy config और payment से जुड़ी वो files, जिन्हें किसी को छूना नहीं था, वो भी “साथ-साथ” साफ़-सुथरी कर दी गई थीं। diff इतना बड़ा था कि कौन सा बदलाव असल में ज़रूरी था, मुझे खुद समझ नहीं आ रहा था। आख़िर में सब कुछ फेंककर दोबारा शुरू करना पड़ा।

समझदार AI से हादसा क्षमता की कमी से नहीं होता। असल बात यह थी कि “कहां तक छूना है” यह घुसने से पहले किसी ने तय ही नहीं किया था। आज हम उसी पहले दिन को ऐसा बनाएंगे जो वापस लौटाया जा सके, जांचा जा सके, और पूरा भी हो।

मुख्य बातें

• किसी और के code में पहली बार घुसने वाले दिन, सबसे पहले एक पेज पर लिखें: “कहां पढ़ना ठीक है, कहां छूना मना है, और काम के बाद कौन सी verification command चलानी है।”
• Claude Code को शुरू से बड़ा overhaul मत सौंपिए। वापस लौटाई जा सकने वाली एक छोटी edit (test के नाम ठीक करना, comment जोड़ना) से शुरू करें।
• “हो गया” की report से पहले हमेशा एक verification command चलाएं और उसका result सहेज लें।
• Delete, production DB, billing और force push को पहले दिन “इंसान से पूछो” पर fix कर दें; जो सुरक्षित साबित हो जाए, उसी को बाद में automate करें।
• diff फूलने लगे तो request का text बदलने से पहले “जिन files को छुआ जा सकता है, उनकी संख्या घटाएं।“

पहले दिन scope क्यों तय करें

नया repo एक ऐसा शहर है जिसका नक्शा नहीं है। कौन सी file दिल है और कौन सी छूते ही टूट जाएगी, शुरू में किसी को नहीं दिखता।

ऐसे में Claude Code से “पूरा देखकर ठीक कर दो” कहेंगे, तो AI मदद की नीयत से दूर-दूर तक हाथ डाल देगा। गलती AI की नहीं है। गलती उस इंसान की है जिसने scope नहीं दिया। पहली बार आए किसी नए कर्मचारी से “दुकान को अच्छा बना दो” कहें और वह counter की settings तक बदल दे, तो यह कहने वाले की गलती है, है न?

इसलिए सबसे पहला काम कोई चालाक prompt लिखना नहीं, बल्कि एक नक्शा बनाना है। कौन सी अलमारी पढ़ सकते हैं, कौन सा दराज खोलना मना है, और जाने से पहले कौन सा ताला जांचना है। बस ये तीन चीज़ें कागज़ पर लिख देने से पहले दिन के ज़्यादातर हादसे ख़त्म हो जाते हैं।

सबसे पहले तय करने वाली तीन सीमाएं

क्रम मायने रखता है। ऊपर से नीचे की ओर fix करते जाइए।

क्या तय करना है	उदाहरण	पहले क्यों तय करें
कहां पढ़ना ठीक है	src/, docs/, test files	सब कुछ पढ़ाएंगे तो बेमतलब बदलाव सुझाने लगता है
कहां छूना मना है	.env, billing, auth, DB migrations, production deploy config	यहां टूटा तो वापस नहीं आता
काम के बाद चलाने वाली verification	npm run build, एक test	हर बार “चलता है इसका सबूत” छोड़ने के लिए

इन तीनों को लिखा हुआ कागज़ (text भी चलेगा) मैं अपने work folder में ONBOARDING.md के रूप में रखता हूं। Claude Code को सबसे पहले यही file पढ़ाता हूं। नक्शा share करने के बाद ही शहर में घुमाना, यही क्रम है।

AI को क्या सौंपें और इंसान क्या तय करे

यहां दोनों मिल गए तो हादसा होता है। लकीर साफ़ खींचते हैं।

Claude Code को सौंपने लायक काम

• पूरे repo को एक नज़र में पढ़कर structure का सारांश बनाना
• “यह feature किस file में है” यह ढूंढना
• test के नाम ठीक करना, comment जोड़ना, types पूरे करना जैसे वापस लौटाने लायक छोटे सुधार का draft
• verification command चलाकर failure log पढ़ना और वजह का अंदाज़ा लगाना

इंसान को ज़रूर तय करने वाला काम

• छूने-मना इलाके में जाने वाला बदलाव allow करना है या नहीं
• file delete करना, production DB पर operation, billing process, force push
• बड़ा design बदलाव merge करना है या नहीं, इसका आख़िरी फ़ैसला
• diff सोच से ज़्यादा फैल जाए तो रोकना है या नहीं

मेरा नियम सीधा है। “गलती हो भी जाए तो git से वापस आ जाए,” वह AI को सौंप दो। “जो वापस न आए,” उसका बटन इंसान दबाए। बस यह एक लकीर बनाए रखें, तो पहले दिन से बड़ा नुकसान नहीं होगा।

कॉपी-पेस्ट करने लायक prompt template

पहली edit में घुसने से पहले मैं यह भेजता हूं। सीधे लिखवाने के बजाय पहले plan मंगवाना ही चाल है।

यह एक existing repo है जिसे मैं पहली बार छू रहा हूं। नीचे के नियम मानिए।

【पढ़ना ठीक है】सिर्फ src/ और docs/ और test files
【मत छुएं】.env / auth / billing / DB migrations / production deploy config
【इस बार का goal】वापस लौटाने लायक एक छोटा सुधार सिर्फ एक (जैसे: test के नाम ठीक करना)
【verification】बदलाव के बाद हमेशा `npm run build` चलाएं और result paste करें

अभी code मत बदलिए।
पहले "कौन सी file कैसे ठीक करेंगे" का plan, और ऊपर के नियमों को
अपने शब्दों में दोबारा कहकर वापस भेजिए।

जो plan वापस आए, अगर वह हमारे constraints को सही से दोहरा रहा है, तो pass है। अगर scope बढ़ाने की कोशिश दिखे, तो वहीं रोक दें। plan अच्छा हो तो “तो उसी तरह करो, build तक चलाओ” कहकर आगे बढ़ें।

सीमाओं को code में रखें

कागज़ के नियम भूल जाते हैं। इसलिए मैं onboarding plan को machine के पढ़ने लायक रूप में भी रखता हूं। नीचे की script वैसे ही चलती है। अपने repo के हिसाब से अंदर का content बदलकर use करें।

#!/usr/bin/env bash
# existing repo के onboarding plan को एक JSON में समेटना
set -euo pipefail

cat > onboarding-plan.json <<'JSON'
{
  "goal": "existing repo में पहली edit सुरक्षित तरीके से पूरी करना",
  "readOnlyCommands": [
    "git status --short",
    "git ls-files | head -50",
    "grep -rn \"TODO\\|FIXME\" src | head -20"
  ],
  "protectedAreas": [".env", "billing", "auth", "db/migrations", "deploy/prod"],
  "firstTask": "वापस लौटाने लायक एक छोटा document या test सुधार",
  "proofCommand": "npm run build",
  "rollback": "git diff -- path/to/changed-file && git checkout -- path/to/changed-file"
}
JSON

echo "=== onboarding plan ==="
cat onboarding-plan.json

echo ""
echo "=== अभी का diff (खाली है तो कुछ नहीं बदला) ==="
git status --short

यह script दिखावटी नहीं है। इसकी असली कीमत यह है कि काम में घुसने से पहले “मना इलाके” और “सबूत वाली command” को एक file में fix कर देती है। बस protectedAreas को अपने repo के खतरनाक हिस्सों से बदल दीजिए, और पहले दिन का नक्शा तैयार है।

एक verification command भी तैयार रखें तो निश्चिंती रहती है। Node.js project के लिए, इस छोटी सी check से “कुछ टूटा तो नहीं” यह मशीनी तरीके से पता चल जाता है।

// check.mjs : बस build पास होता है या नहीं, यह जांचने वाली छोटी script
import { execSync } from "node:child_process";

try {
  // अपने project की verification command से बदल दें
  execSync("npm run build", { stdio: "inherit" });
  console.log("verification OK: build पास हुआ। diff review करें।");
} catch (e) {
  console.error("verification NG: build गिर गया। merge मत करें, वजह जांचें।");
  process.exit(1);
}

node check.mjs हरा हो तो diff review पर भेजें, लाल हो तो रोक दें। बस यह एक script होने से “चल तो रहा होगा” की धारणा पर merge करने वाला हादसा ख़त्म हो जाता है।

तीन असली हालात में इस्तेमाल

कोई मिलता-जुलता हाल हो, तो पूरा तरीका दोबारा मत बनाइए, बस नाम अपने हालात पर बदल दीजिए।

1. Content site का handover article data की जगह, image folder, build command, product page पहले पढ़ाकर समझा दें। पहली edit बस “एक टूटे link को ठीक करना” हो। build पास हो जाए तो review पर भेजें। body का बड़ा rewrite तब, जब सुरक्षित होना समझ आ जाए।

2. SaaS codebase auth, billing और DB migrations को मना इलाके में साफ़ लिखें। पहली task को “test का explanation आसान बनाना” जितना छोटा रखें और इंसान की approval के बाद ही आगे बढ़ें। यहां ढील दी तो payment logic में “मददगार सुधार” घुस जाता है और रोंगटे खड़े हो जाते हैं।

3. पुराना legacy repo “पूरे को modernize कर दो” यह कहना मना है। diff इतना बड़ा हो जाता है कि पढ़ा नहीं जाता। इसके बजाय function के नाम की typo ठीक करना या test के नाम साफ़ करना जैसे, build से जांचे जा सकने वाले छोटे कदम से शुरू करें। एक बार सफल हो जाए तो उसी ढांचे से अगला कदम लें।

हर उदाहरण में एक “रुकने की जगह” है। रुकने की जगह होने से ही काम अंतहीन रूप से फैलता नहीं।

failure के उदाहरण और उनका इलाज

ईमानदारी से लिखता हूं। पहली कुछ बार मैंने सब में गड़बड़ की।

मना इलाका लिखे बिना कह दिया → review न हो सकने जितना बड़ा diff बन गया और सब फेंकना पड़ा। इलाज सीधा है: request का text refine करने से पहले “पढ़ने लायक files घटाएं।” scope जितना संकरा, AI के बहकने की चौड़ाई उतनी कम।

सारे बदलाव ख़त्म होने के बाद build किया → कौन सी edit से टूटा, यह पता ही नहीं चला। अब मैं एक file ठीक करते ही verification चला देता हूं। टूटने का पल record में रहता है, इसलिए वजह तुरंत मिल जाती है।

जांच को सिर्फ अपनी आंखों पर छोड़ दिया → व्यस्त दिन में हमेशा कुछ छूट जाता है। शब्दशः “जो मशीन से पता चल सकता है,” वह मशीन को सौंप दीजिए। build पास हुआ या नहीं, test का result, टूटा link। इंसान की आंख सिर्फ उन design फ़ैसलों के लिए, जिन्हें मशीन नहीं पकड़ सकती। इससे आधी रात की review बहुत घट गई।

failure को article में छोड़ना इसलिए ज़रूरी है, क्योंकि सिर्फ success की कहानियों से reader अपनी ख़तरनाक हालत नहीं पहचान पाता। कौन सी request ज़्यादा फैली, कौन सी verification छूट गई, यह छोटा सा लिख रखें, तो अगली बार आप वही गड्ढा नहीं लांघेंगे।

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

Q. पहली edit के लिए क्या चुनें? A. “गलती हो भी जाए तो git checkout से वापस आ जाए” वही चुनें। test के नाम ठीक करना, comment जोड़ना, typo सुधारना सुरक्षित हैं। नया feature या config बदलाव पहले दिन के लिए ठीक नहीं।

Q. मना इलाका कितना बारीक लिखूं? A. सिर्फ “जहां टूटे तो वापस न आए” वही काफ़ी है। .env, auth, billing, production deploy config, DB migrations। शुरू में ये पांच पकड़ लें, तो बड़े हादसे लगभग रुक जाते हैं।

Q. Claude Code से plan वापस मंगवाने की मेहनत बचाई जा सकती है? A. न बचाने की सलाह दूंगा। plan दोबारा कहलवाने की एक मेहनत से scope की गड़बड़ी edit से पहले पकड़ में आ जाती है। code लिखे जाने के बाद पता चलने से यह कहीं सस्ता है।

Q. verification command में सिर्फ build काफ़ी है? A. पहले दिन build एक ही काफ़ी है। आदत हो जाए तो एक related test जोड़ें। शुरू से ही सारे test चलाने जाएंगे तो भारी पड़ता है और टिकता नहीं। छोटे से शुरू करें, success log जमने के बाद बढ़ाएं।

Q. team में लाते समय क्या ध्यान रखें? A. ONBOARDING.md जैसी shared file में सीमाएं लिखें और सब एक ही नक्शा use करें। हर इंसान का मना इलाका अलग-अलग हो, तो review का मापदंड भी डगमगाता है।

संबंधित लेख

सोच की नींव के लिए Claude Code एंजीनियर के अलावा लोग कैसे इस्तेमाल करें और Claude Code पहला कदम गाइड काम आएंगे। project के नियम याद कराने का तरीका CLAUDE.md best practices में है, और ज़्यादा गहरी instruction देने का तरीका prompt design का अभ्यास में समेटा है। permissions की बारीकियां Anthropic की official documentation में भी देख लें।

मैंने असल में आज़माकर क्या पाया

शुरुआत वाले “23 files के हादसे” के बाद मैंने onboarding का क्रम बदल दिया। चालाक prompt ढूंढना छोड़कर, पहले onboarding-plan.json से मना इलाका और verification command fix कर देता हूं। बस इतने से payment या production config में हाथ डलने वाले हादसे शून्य हो गए।

जिस दिन पहली edit को “test के नाम ठीक करना” तक सीमित रखा, diff 8 lines में सिमट गया और build एक ही बार में पास हो गया। review में दो मिनट भी नहीं लगते। उलटे, जिस दूसरे दिन scope तय किए बिना कहा, उस दिन फिर diff फूल गया और सब फेंकना पड़ा। फ़र्क model की समझदारी का नहीं था, फ़र्क इसका था कि घुसने से पहले नक्शा बनाया था या नहीं।

किसी और के code को सुरक्षित छूने का यह ढांचा अपनी team के असल उदाहरणों पर पक्का करना हो, तो काम के हिसाब से onboarding की रूपरेखा हम training और consultation में साथ मिलकर बनाते हैं। फ़िलहाल आज ही, अपने repo के पांच मना इलाके लिखने से शुरुआत कीजिए।