Claude Code से सिर्फ एक फाइल बदलवाने का सेफ प्रॉम्प्ट कैसे लिखें

“इस ब्लॉग पोस्ट का इंट्रो थोड़ा बेहतर कर दो।”

मैंने यह शुक्रवार रात दस बजे टाइप किया था। मुझे बस एक फाइल के पहले तीन पैराग्राफ ठीक करवाने थे। पर अगली सुबह जब मैंने diff खोला, तो बारह फाइलें बदल चुकी थीं। सिर्फ पोस्ट का बॉडी नहीं—कॉमन लेआउट, टैग की लिस्ट, और न जाने क्यों पब्लिश सेटिंग वाली फाइल तक। चलता है या नहीं, यह जांचे बिना ही मैं सो गया था।

वापस ठीक करने में आधा घंटा लगा। गलती कहां थी? Claude Code कमजोर नहीं था। गलती यह थी कि मेरे निर्देश में “कहां तक हाथ लगाना है” एक शब्द भी तय नहीं था। तो उस होशियार AI ने बस यह समझा कि “इंट्रो बेहतर करना = आसपास की चीजें भी ठीक करना” और मदद के इरादे से सब कुछ छेड़ दिया।

इस लेख में मैं उसी रात की गलती से बना “सिर्फ एक फाइल को सेफ तरीके से बदलवाने वाला प्रॉम्प्ट” आपको ऐसे दूंगा कि सीधे कॉपी-पेस्ट कर सकें। दायरा छोटा रखो, काम के बाद AI से खुद जांच करवाओ, और अगर गलत हो तो वापस लौटा सको—बस इतना करने से आधी रात के हादसे लगभग खत्म हो गए।

मुख्य बातें

• AI को सौंपा काम बेकाबू तब होता है जब मॉडल खराब हो, ऐसा नहीं—बल्कि जब हाथ लगाने का दायरा लिखा ही न हो।
• प्रॉम्प्ट में ये पांच चीजें हमेशा डालें: “देखने वाली फाइलें”, “बदलने वाली फाइलें”, “जिन्हें नहीं छूना”, “जांच कमांड”, और “वापस लौटाने का तरीका”।
• सफलता की रिपोर्ट से पहले जांच कमांड जरूर चलवाएं, ताकि बाद में इंसान टेस्ट करने वाला न बन जाए।
• ब्लॉग एडिट, बग रिपोर्ट की सफाई, प्रोडक्ट टेक्स्ट बदलना—जहां रुकने की लाइन साफ हो, ऐसे छोटे काम से शुरू करें।
• दायरा छोटा करने से लेख या आउटपुट की वैल्यू नहीं गिरती; उल्टा पाठक उसे अपने माहौल में आसानी से ढाल पाता है।

“थोड़ा बेहतर कर दो” हादसा क्यों बनता है

“थोड़ा बेहतर कर दो” इस मांग में अंत की कोई लाइन नहीं होती।

कोई इंसान एडिटर हो, तो व्यस्त शुक्रवार रात ऐसा काम मिलने पर पूछेगा—“बस इंट्रो के तीन पैराग्राफ ही न?” पर AI बिना पूछे दौड़ पड़ सकता है। और चूंकि वह मदद करने में माहिर है, इसलिए “इंट्रो ठीक करना है तो टैग भी संवार दूं, रिलेटेड लिंक भी जोड़ दूं तो अच्छा रहेगा” सोचकर खुद ही दायरा फैला लेता है। बुरी नीयत बिल्कुल नहीं होती—यही सबसे झंझट की बात है।

यहां काम आता है यह सोच कि निर्देश के अंदर ही “रुकने की जगह” लिख दो। प्रॉम्प्ट को लंबा-चौड़ा बनाना जरूरी नहीं; बल्कि छोटा ही अच्छा। उसकी जगह, किन फाइलों को छू सकते हो और किन्हें नहीं—यह शुरू में ही साफ-साफ बांट दो। बस इतने से बेकाबू होना रुक जाता है।

प्रॉम्प्ट लिखने के तरीके में गहराई से उतरना हो, तो Claude Code की प्रॉम्प्ट डिज़ाइन साथ में पढ़ें—तब दिखेगा कि यहां जो “दायरा छोटा करना” है, वह बाकी तकनीकों से कैसे जुड़ता है।

प्रॉम्प्ट में जरूर डालने वाली पांच बातें

मैं आज जो प्रॉम्प्ट इस्तेमाल करता हूं, उसमें ये पांच चीजें हमेशा रहती हैं। इनका क्रम भी मायने रखता है।

बात	अंदर क्या	यह न हो तो क्या होता है
देखने वाली फाइलें	हालात समझने के लिए जिन्हें पढ़ना ठीक है	बेमतलब जगहें पढ़कर बेकार सुधार कर देता है
बदलने वाली फाइलें	असल में जिन्हें बदलना है, वो 1–2 फाइलें	बारह-फाइल वाला हादसा होता है
जिन्हें नहीं छूना	सेटिंग, जनरेट हुई फाइलें, सीक्रेट, पब्लिश सेटिंग	जो मिटानी नहीं चाहिए, उन्हें “संवारने” लगता है
जांच कमांड	बदलाव के बाद चलाने वाली एक जांच कमांड	टूटी हालत में ही “हो गया” रिपोर्ट कर देता है
लौटाने का तरीका	गलत होने पर मूल हालत में लौटने के कदम	रिकवरी में आधा घंटा लग जाता है

मुख्य बात यह है कि एडिट शुरू करने से पहले एक बार “योजना” लौटवाएं। सीधे बदलवाएं मत। “कौन-सी फाइल देखोगे, किसे बदलोगे, और अगर गलत हुआ तो क्या टूटेगा”—यह पहले बुलवाएं। यहां अगर बेकार योजना लौटे, तो उसी वक्त रोक सकते हैं। बदलने के बाद पता चलने से यह कहीं सस्ता पड़ता है।

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

सब कुछ AI को देने की जरूरत नहीं। मैं लाइन यहां खींचता हूं।

जो AI को सौंपा जा सकता है

• हालात समझने के लिए फाइलें पढ़ना
• बदलाव की योजना बनाकर शब्दों में रखना
• असल टेक्स्ट या कोड लिखना
• जांच कमांड चलाकर नतीजा रिपोर्ट करना

जो इंसान अपने पास रखे

• कौन-सी फाइल बदलाव का टारगेट होगी (दायरे का फैसला)
• पब्लिश या प्रोडक्शन में लाने का बटन दबाना
• सेटिंग फाइल या सीक्रेट को छूने का फैसला
• जांच फेल हो तो पब्लिश रोकने का फैसला

यह लाइन-बंदी उन लोगों के लिए सबसे जरूरी है जो पहली बार AI को काम सौंप रहे हैं। AI को क्या सौंपें और इंसान क्या तय करे—यह बंटवारा गैर-इंजीनियरों के लिए Claude Code में भी बुनियादी सोच के तौर पर आता है। शुरुआत में “पढ़ना-लिखना AI, मिटाना-पब्लिश करना इंसान” जितना मोटा बंटवारा भी काफी है।

कॉपी-पेस्ट के लिए तैयार प्रॉम्प्ट टेम्पलेट

इसे सीधे चिपकाकर, बस फाइल के नाम अपने माहौल के हिसाब से बदल दें। PowerShell हो या bash, टेक्स्ट को एक वेरिएबल में रखकर देख लेना ही काफी है।

brief=$(cat <<'EOF'
मकसद: सिर्फ एक जगह सेफ एडिट करना।
बदलने योग्य फाइल: site/src/content/blog/example.mdx
जिन्हें नहीं छूना: package वाली फाइलें, जनरेट हुई फाइलें, सीक्रेट, पब्लिश/डिप्लॉय सेटिंग।

एडिट शुरू करने से पहले, ये लौटाओ:
1. हालात समझने के लिए जो फाइलें देखोगे
2. असल में जो एक फाइल बदलोगे
3. वह बदलाव गलत हुआ तो क्या टूटेगा
4. बदलाव के बाद चलाने वाली जांच कमांड

एडिट खत्म करके, ये लौटाओ:
- diff का सार
- जांच कमांड का नतीजा
- मूल हालत में लौटाने के कदम
EOF
)

echo "$brief"

यह टेक्स्ट कोई चमकदार चीज नहीं है। इसकी वैल्यू यह है कि काम शुरू करने से पहले सीमाएं शब्दों में दर्ज हो जाती हैं। फाइल के नाम, न छूने वाली चीजें, और जांच कमांड को अपनी रिपॉजिटरी के हिसाब से बदलकर Claude Code को दें। अच्छी योजना लौटे, तो वही पाबंदियां एक बार फिर बुलवाकर ही काम शुरू करवाएं।

अगर यही पाबंदियां CLAUDE.md में लिख दें, तो हर बार चिपकाए बिना अपने आप लागू होती रहेंगी। तरीका CLAUDE.md की बेस्ट प्रैक्टिस में समेटा है।

काम खत्म होने पर जांच करवाने वाली छोटी स्क्रिप्ट

“हो गया” पर यकीन मत करो। यह दूसरा खंभा है।

एडिट खत्म होने के बाद, मशीनी तरीके से जांचो कि बदली हुई फाइलें सचमुच सिर्फ एक हैं या नहीं। नीचे की स्क्रिप्ट बस इतना करती है—बिना कमिट हुई बदली फाइलों की गिनती करती है, और अगर अंदाज़े से ज्यादा हों तो रुक जाती है। हिंदी कमेंट के साथ यह सीधे चलती है।

#!/usr/bin/env bash
# जांचो कि बदली फाइल सिर्फ एक है या नहीं। ज्यादा हों तो रुक जाओ।
set -e

# अपेक्षित बदली फाइलों की संख्या (एक फाइल एडिट है तो 1)
expected=1

# बिना कमिट हुई बदली फाइलों की गिनती
changed=$(git status --porcelain | grep -c .)

echo "बदली हुई फाइलें: $changed (अपेक्षित: $expected)"

if [ "$changed" -gt "$expected" ]; then
  echo "अंदाज़े से ज्यादा फाइलें बदली हैं। diff जांचें।"
  git status --porcelain
  exit 1
fi

echo "दायरे के मुताबिक है।"

इस स्क्रिप्ट को प्रॉम्प्ट की “जांच कमांड” में डाल दें, तो AI इसे खुद चलाकर नतीजा रिपोर्ट करने लगता है। अगर बारह फाइलें बदली हों, तो रिपोर्ट के वक्त ही लाल अक्षर दिख जाते हैं। सुबह उठकर मुझे पता चले—ऐसा नहीं, बल्कि वहीं मौके पर रुक जाता है। यही काम करता है।

जांच और रोज़ की तैयारी को और ऑटोमेट करना हो, तो Claude Code की प्रोडक्टिविटी तकनीकें में दूसरे पैटर्न भी समेटे हैं।

ऐसे मौकों पर यह काम करता है (तीन)

ये सब ऐसे काम हैं जहां “रुकने की जगह” साफ है। उल्टा कहूं तो—जहां रुकने की जगह न दिखे, वह काम अभी AI को पूरा सौंपने की जगह नहीं, यह संकेत है।

1. ब्लॉग इंट्रो की रीराइट शुरू में ही लिखो कि बदलना है सिर्फ एक फाइल का इंट्रो। साथ में टारगेट पाठक और जांच कमांड भी जोड़ो। इससे हाथ पूरे बॉडी या लेआउट तक नहीं पहुंचता। मेरा बारह-फाइल हादसा बस इसी एक लाइन से रुक जाता।

2. बग रिपोर्ट की सफाई सिर्फ लॉग फाइल और एक टेम्पलेट दिखाओ, और लिखो कि “बेमतलब कोड की सफाई मना है”। रिपोर्ट संवारते-संवारते अगर रीफैक्टरिंग हो जाए, तो रिव्यू एकदम भारी हो जाता है। दिखाने का दायरा छोटा करो, तो आउटपुट भी छोटा रहता है।

3. प्रोडक्ट पेज के टेक्स्ट का टेस्ट पूरे पेज को नए सिरे से बनाने के बजाय, बस “एक कैचकॉपी का सुझाव” और “बदलाव के बाद की झलक की जांच” मांगो। दायरा एक सुझाव पर बंधा है, इसलिए A/B टेस्ट के वक्त भी तुलना आसान रहती है।

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

Q. हर बार यह लंबा प्रॉम्प्ट चिपकाना झंझट नहीं? बार-बार लगने वाली पाबंदियां CLAUDE.md में लिख दें, तो हर बार चिपकाए बिना लागू होती हैं। फिर बस “इस बार जो फाइल छूनी है, उसका नाम” चिपकाना भर रह जाता है।

Q. दायरा छोटा करने से AI की खूबी मर नहीं जाएगी? उल्टा हुआ। दायरा छोटा हो, तो AI बिना भटके गहराई से ठीक करता है। चौड़े निर्देश बस “कहां से शुरू करें” में उलझाते हैं।

Q. जांच कमांड में क्या डालूं? शुरू में सिर्फ “बदली फाइलों की गिनती की जांच” काफी है। आदत पड़ने पर—बिल्ड पास होता है या नहीं, टेस्ट गिरते तो नहीं, टूटे लिंक तो नहीं—एक-एक कमांड जोड़ते जाएं।

Q. फिर भी अनचाही फाइल बदल जाए तो? लौटाने का तरीका प्रॉम्प्ट में लिखा हो, तो बस उन्हीं कदमों से वापस लौटा लें। git restore . जैसी लौटाने वाली कमांड शुरू से ही निर्देश में डाल देना तरकीब है।

Q. कहां से शुरू करूं? ऐसा एक छोटा काम चुनें जो गलत होने पर भी लौटाया जा सके। ड्राफ्ट पोस्ट का सुधार, या टेक्स्ट बदलना—ये ठीक रहते हैं। बुनियादी इस्तेमाल में हिचक हो, तो Claude Code शुरुआती गाइड से शुरू करना ज़मीन तैयार कर देता है।

मैंने इसे असल में आज़माया, नतीजा यह रहा

उस बारह-फाइल हादसे के बाद, मैंने प्रॉम्प्ट को हमेशा “बदलने वाली फाइल”, “न छूने वाली चीजें”, और “जांच कमांड” के साथ लिखना शुरू कर दिया।

जांच स्क्रिप्ट को “जांच कमांड” में डालने के बाद, अनचाही फाइलें घुसने वाले मामले वहीं मौके पर रुकने लगे। सच में, पिछले हफ्ते भी जब मैंने प्रोडक्ट पेज का टेक्स्ट ठीक करवाया, तो AI कॉमन कंपोनेंट तक हाथ बढ़ाने लगा था—पर बदली फाइलों की संख्या 2 होते ही स्क्रिप्ट ने लाल निशान दिखाकर रोक दिया। सुबह उठकर diff देखकर पीला पड़ जाना—वह अब नहीं होता।

एक और चीज़ मैंने जांची—दायरा छोटा करने से आउटपुट की गुणवत्ता नहीं गिरती। उल्टा, जिस दिन “बस इंट्रो के तीन पैराग्राफ” की पाबंदी लगाई, उसी दिन ज्यादा सटीक सुधार लौटा। होशियार AI को चौड़ा सौंपने के बजाय, छोटा मांगकर खुद जांच करवाना। घूमकर जाने जैसा लगता है, पर मेरे लिए यही सबसे तेज़ रास्ता है—फिलहाल यही मेरा निष्कर्ष है।

कंपनी के काम में AI को एडिट या ऑपरेशन सौंपने का ढांचा खड़ा करना हो, तो ट्रेनिंग और परामर्श में ठोस कदमों से लेकर साथ मिलकर बना सकते हैं। पहले अपने हाथ में, सिर्फ एक फाइल वाला प्रॉम्प्ट एक बार आज़माकर देखिए।

संदर्भ के लिए, यहां इस्तेमाल हुए टूल की आधिकारिक जानकारी Claude Code की आधिकारिक डॉक्युमेंटेशन में है।