कमिट से पहले 3 मिनट की जाँच: Claude Code ने जो छुआ, उसे पुष्टि करके ही फाइनल करें

शुक्रवार की शाम थी। मैंने Claude Code से कहा, “बस लेख के बटन का टेक्स्ट ठीक कर दो।” काम लौटकर आया, मैंने git status चलाया — और बदली हुई फाइलें 18 निकलीं। टेक्स्ट भर बदलना था, पर वहाँ प्रोडक्ट लिंक की मैपिंग, रिलेटेड आर्टिकल का इंजेक्शन, और “साथ में ठीक कर दिया” वाली ट्रांसलेशन फाइलें तक कतार में लगी थीं।

अलग-अलग देखें तो हर बदलाव “मदद करने की नीयत से” किया गया था। पर अगर मैं वो सब वैसे ही कमिट कर देता, तो किसी और काम के बीच बिना सेव किए पड़े बदलाव भी इसमें घिसट जाते, और अगले दिन की deploy में बिना कारण की एरर ढूँढते-ढूँढते मेरा आधा दिन निकल जाता।

जितना समझदार AI होता है, उतना ही वह सौंपे गए दायरे से थोड़ा बाहर निकलकर काम कर जाता है। बुरी नीयत से नहीं। इसीलिए फाइनल करने से ठीक पहले एक पल रुककर “यहीं रोको, अब इंसान आँख से देखेगा” वाला ब्रेक ज़रूरी है।

मुख्य बातें

Claude Code भले ही दिए गए काम के प्रति वफादार हो, फिर भी जिस दायरे में हाथ डालता है वह चुपचाप फैलता रहता है। फाइनल से पहले की जाँच इसी “बाहर निकलने” को पकड़ने का काम है।
जाँच को 3 मिनट के तय क्रम में घुमाएँ: दायरा देखें → diff देखें → जाँच का प्रमाण लें → ज़रूरी फाइलें चुनकर स्टेज करें — ये चार कदम।
AI को सौंपें “बदलाव करना”; इंसान तय करे “इस बार के कमिट में कहाँ तक शामिल करना है”। इन दोनों को मत मिलाएँ।
एक कॉपी-पेस्ट करके चलने वाली जाँच स्क्रिप्ट नीचे रखी है। git status और diff का सार एक ही स्क्रीन पर दिखाकर चूक कम करती है।
सिर्फ़ build पास हो जाने से निश्चिंत मत हो जाइए। प्रकाशन के बाद का डिस्प्ले और ट्रांसलेशन का असली कंटेंट किसी दूसरी नज़र से देखना पड़ता है।

जाँच को “फाइनल से ठीक पहले” क्यों रखें

जाँच का सही समय न तो काम शुरू करने से पहले है, न बीच में — बल्कि कमिट करने से ठीक पहले सबसे ज़्यादा असरदार है। कारण सीधा है: AI ने असल में जिन फाइलों को छुआ, उनकी पूरी तस्वीर ठीक उसी क्षण पक्की होती है।

शुरू में चाहे जितना कह दें “बस यहीं छूना”, AI काम के बीच “साथ में यह भी ठीक कर देना बेहतर रहेगा” सोचकर हाथ डाल देता है। बीच में रोक दें तो काम अधूरा है, इसलिए समझ ही नहीं आता क्या देखें। सब खत्म होकर, फाइनल से एक कदम पहले — यहीं पहली बार “जो माँगा था” और “जो असल में बदला” को आमने-सामने रखा जा सकता है।

मैं अक्सर वहाँ फँसता हूँ जहाँ कमाई जुड़ी होती है। मसलन प्रोडक्ट पेज का लिंक एक अक्षर भी खिसक जाए, तो क्लिक करने वाला पाठक “पेज नहीं मिला” पर जा गिरता है। लेख की क्वालिटी चाहे जितनी अच्छी हो, अगर लिंक का गंतव्य मरा हुआ है तो बिक्री का मौका वहीं खत्म। इसलिए diff देखते समय मैं सबसे पहले यही जाँचता हूँ कि लिंक का गंतव्य बदला तो नहीं।

अगर आपने Claude Code का बुनियादी इस्तेमाल अभी पक्का नहीं किया है, तो पहले Claude Code शुरुआती गाइड से पूरी तस्वीर समझ लें — तभी इस जाँच क्रम का मतलब साफ़ होगा।

3 मिनट में घूमने वाला जाँच का क्रम

रोज़ न निभा पाएँ तो कोई फ़ायदा नहीं, इसलिए तरीका सिर्फ़ 4 कदम में बाँधा है। यह कोई परफ़ेक्ट ऑडिट नहीं, एक हल्का सेफ़्टी डिवाइस है।

दायरा बोलकर कहें। इस बार माँग क्या थी, एक वाक्य में दोहराएँ — जैसे “लेख के बटन का टेक्स्ट ठीक करना”। यही आगे के फ़ैसलों का पैमाना बनेगा।
बदली फाइलों की सूची देखें। git status से देखें कि कौन-कौन सी फाइलें बदलीं। उस एक वाक्य के दायरे से बाहर की कोई फाइल दिखे, तो मन में उस पर एक चिप्पी (sticky note) चिपका दें।
चिप्पी वाली फाइलों का diff पढ़ें। सिर्फ़ दायरे से बाहर की फाइलों का कंटेंट देखें। मददगार बदलाव हो तो रखें, बेकार का हो तो इस बार बाहर निकालें — एक-एक करके तय करें।
सिर्फ़ ज़रूरी फाइलें चुनकर स्टेज करें। git add . से सब अंदर मत डालें। इस बार की माँग के लिए ज़रूरी फाइलें ही नाम लेकर जोड़ें।

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

AI को सौंपने का दायरा, और इंसान के फ़ैसले का दायरा

यह लकीर धुंधली रहे तो जाँच खुद दिखावा बनकर रह जाती है। मैं इसे इस तरह बाँटता हूँ।

क्या करना है	किसका काम	कारण
टेक्स्ट या कोड का सुधार करना	AI	मात्रा ज़्यादा है, मशीनी ढंग से निपट जाता है
सिंटैक्स एरर और साफ़ गलतियाँ ठीक करना	AI	नियम साफ़ हैं, ऑटोमेट करना आसान
बदलाव इस कमिट में शामिल करना है या नहीं	इंसान	माँग की मंशा सिर्फ़ इंसान जानता है
लिंक का गंतव्य और प्रकाशन-बाद का डिस्प्ले जाँचना	इंसान	build पास होने पर भी कंटेंट की गारंटी नहीं
डिलीट, प्रोडक्शन डेटा, बिलिंग से जुड़े काम	इंसान	जो वापस न हो सके, उसमें इंसान की मंज़ूरी अनिवार्य

अगर AI को “शामिल करना है या नहीं, यह भी तुम तय कर लो” तक सौंप दें, तो AI अपने किए हर सुधार को सहज ही पूरा शामिल करना चाहेगा। फ़ैसला अपने हाथ में रखें — दुर्घटनाएँ घटाने का यही सबसे बड़ा गुर है।

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

जब जाँच में AI से मदद लें, तो उससे “खुद को नंबर देने” मत कहिए — “तथ्य कतार में रखने” को कहिए। नीचे का टेम्पलेट जस-का-तस चिपकाकर इस्तेमाल कर सकते हैं।

अब मैं कमिट करने जा रहा हूँ। फाइनल से पहले, नीचे की बातें सिर्फ़ तथ्य के रूप में बताओ। फ़ैसला मैं करूँगा।

1. इस बार की माँग को एक वाक्य में सार रूप में लिखो
2. git status से बदली हुई फाइलें सूचीबद्ध करो (untracked भी शामिल)
3. उनमें से, जो माँग के एक वाक्य से बाहर लग रही हों, वे फाइलें और उसका कारण
4. लिंक या प्रकाशन-बाद के डिस्प्ले पर असर डालने वाला कोई बदलाव हो, तो वह हिस्सा

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

आख़िरी वाक्य ही असली जादू है। इसे न डालें तो AI “कोई खास समस्या नहीं, कमिट कर दीजिए” कहकर आराम से समेट देता है, और जाँच का मतलब ही मिट जाता है। प्रॉम्प्ट को बारीकी से कैसे गढ़ें, यह मैंने प्रॉम्प्ट इंजीनियरिंग एडवांस्ड में विस्तार से लिखा है।

कॉपी करके चलने वाली जाँच स्क्रिप्ट

हर बार git status और git diff अलग-अलग टाइप करना झंझट है, इसलिए बदलाव की पूरी तस्वीर एक स्क्रीन पर दिखाने वाली स्क्रिप्ट यहाँ रखी है। PowerShell और bash, दोनों दे रहा हूँ। काम बस इतना है — “बदली फाइलों की सूची” और “हर फाइल में जुड़ी/हटी लाइनें” साथ-साथ दिखाना।

PowerShell वाला (Windows)।

# precommit-check.ps1
# कमिट से पहले, बदली फाइलें और बदलाव की मात्रा एक स्क्रीन पर देखें

Write-Host "=== इस बार छुई फाइलें ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== फाइलवार बदलाव (जुड़ी / हटी) ===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== जाँच की चेकलिस्ट ===" -ForegroundColor Yellow
@(
  "माँग को एक वाक्य में कह सकता हूँ",
  "दायरे से बाहर की फाइल नहीं मिली है",
  "लिंक का गंतव्य और प्रकाशन-बाद का डिस्प्ले देख लिया",
  "इस बार ज़रूरी फाइलें ही स्टेज करूँगा"
) | ForEach-Object { Write-Host "  [ ] $_" }

bash वाला (macOS / Linux / Git Bash)।

#!/usr/bin/env bash
# precommit-check.sh
# कमिट से पहले, बदली फाइलें और बदलाव की मात्रा एक स्क्रीन पर देखें

echo "=== इस बार छुई फाइलें ==="
git status --short

echo ""
echo "=== फाइलवार बदलाव (जुड़ी / हटी) ==="
git diff --stat HEAD

echo ""
echo "=== जाँच की चेकलिस्ट ==="
for item in \
  "माँग को एक वाक्य में कह सकता हूँ" \
  "दायरे से बाहर की फाइल नहीं मिली है" \
  "लिंक का गंतव्य और प्रकाशन-बाद का डिस्प्ले देख लिया" \
  "इस बार ज़रूरी फाइलें ही स्टेज करूँगा"; do
  echo "  [ ] $item"
done

चलाना बस इतना है।

bash precommit-check.sh

यह स्क्रिप्ट अपने आप कुछ तय नहीं करती। “फ़ैसला इंसान करेगा” वाली नींव न टूटे, इसलिए जानबूझकर इसे “सिर्फ़ कतार में दिखाने वाली” रखा है। चेकलिस्ट के चारों आइटम भर जाएँ, तब सिर्फ़ ज़रूरी फाइलें git add फाइल-नाम से जोड़कर कमिट करें।

असल काम में काम आने वाले 3 मौके

1. लेख या सामग्री के प्रकाशन से पहले। कई भाषाओं के लेख एक साथ प्रकाशित करते समय, ट्रांसलेशन फाइलें कभी अंग्रेज़ी में ही रह जाती हैं। build पास हो जाता है, पर कंटेंट अनुवादित नहीं होता। diff में बस फाइल का नाम देखकर संतुष्ट मत होइए — प्रकाशन-बाद के पेज पर बॉडी की भाषा तक जाँचिए।

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

3. टीम में लागू करते समय। Claude Code कहाँ तक अपने आप बढ़ा और कहाँ इंसान से पूछा, इसका रिकॉर्ड रखें। मंज़ूरी के नियम (जो अपने आप होने दें, जो हमेशा इंसान से पूछें) धुंधले रहें तो हर सदस्य के यहाँ दुर्घटना अलग ढंग से होती है और हालात बेकाबू हो जाते हैं।

आम गड्ढे और उन्हें ठीक करने का तरीका

गड्ढा 1: git add . से सब अंदर डाल देना। किसी और काम के बिना सेव किए बदलाव तक घिसट आते हैं। ठीक करना सीधा है — . मत इस्तेमाल कीजिए, फाइल का नाम लेकर स्टेज करने की आदत डालिए। झंझट लगे तो भी, यही सबसे तेज़ बीमा है।

गड्ढा 2: build पास हो गया, इसलिए निश्चिंत हो जाना। build सिर्फ़ सिंटैक्स देखता है — लिंक का गंतव्य सही है या नहीं, ट्रांसलेशन कंटेंट तक अनुवादित है या नहीं, यह नहीं देखता। ठीक करने का तरीका — प्रकाशन-बाद का पेज सचमुच खोलकर हेडिंग, बॉडी और लिंक के गंतव्य को आँख से जाँचिए। मशीन का पास होना और इंसान का पास होना — दोनों अलग चीज़ें हैं।

गड्ढा 3: AI से “कोई दिक्कत तो नहीं?” पूछकर खत्म कर देना। पूछने पर AI “सब ठीक है” कहने की ओर झुकता है। ठीक करने का तरीका — ऊपर वाले प्रॉम्प्ट टेम्पलेट की तरह कहिए “फ़ैसला मत लिखो, सिर्फ़ तथ्य कतार में रखो”। फ़ैसले का कर्ता वापस इंसान को बना दें, तभी जाँच काम करने लगती है।

जाँच को आदत बनाने के और तरीके मैंने Claude Code प्रोडक्टिविटी टिप्स में लिखे हैं। git के --stat जैसे आधिकारिक व्यवहार Git आधिकारिक डॉक्युमेंट में देखे जा सकते हैं।

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

Q. हर बार जाँच में 3 मिनट लगाने की फ़ुर्सत नहीं है। A. जिस दिन बदलाव छोटा हो, 1 मिनट में निपट जाता है। 3 मिनट तब लगते हैं जब दायरे से बाहर की फाइलें ज़्यादा हों — और वही तो वह दिन है जब जाँच असल में ज़रूरी है। समय की लंबाई को ख़तरे का बैरोमीटर समझिए।

Q. क्या AI को स्टेज तक नहीं सौंप सकते? A. जो काम छोटा है और सुरक्षित होना पता है, उसमें सौंप सकते हैं। पर “कौन-सी फाइलें शामिल करनी हैं” का आख़िरी फ़ैसला इंसान के पास रखने की सलाह दूँगा। यही जगह दुर्घटना का दरवाज़ा बनती है।

Q. कमिट मैसेज में क्या लिखूँ? A. दो बातें — “क्या बदला” और “किससे जाँचा”। जैसे “बटन का टेक्स्ट सुधारा, प्रकाशन-बाद पेज पर लिंक का गंतव्य जाँचा”। बाद में देखने पर एक नज़र में पता चल जाता है कि जाँच हुई थी या नहीं।

Q. दायरे से बाहर की फाइल असल में सुधारने लायक बदलाव निकली तो? A. फिर भी इस बार बाहर निकालिए। बस अलग कमिट में बाँट दीजिए — मिटा नहीं रहे। एक कमिट में एक मंशा — इसे निभाएँ तो बाद में पीछा करना आसान रहता है।

असल में आज़माने के बाद का नतीजा

शुरुआत वाली 18-फाइल वाली घटना के बाद, मैंने ये 4 कदम हर फाइनल से पहले डालना शुरू कर दिया। आज़माए तीन पैटर्न — लेख प्रकाशन, फाइल का दोबारा लिखना, और सेटिंग बदलना।

सबसे ज़्यादा असर “माँग को एक वाक्य में दोहराने” वाले पहले कदम का हुआ। यह बस ज़ुबान पर लाते ही, दायरे से बाहर की फाइलें अपने आप नज़र में कूदकर आने लगती हैं। जाँच स्क्रिप्ट चलाने के बाद git add . टाइप करना छोड़कर, फाइल का नाम लेकर स्टेज करने लगा — तो किसी और काम को घिसटा लेने वाली दुर्घटना शून्य हो गई।

और जो हैरान करने वाली बात रही — AI से पूछने का अंदाज़ “कोई दिक्कत तो नहीं?” से बदलकर “सिर्फ़ तथ्य कतार में रखो” करने का असर। वही AI अचानक एक काम का जाँच-साथी बन गया। ज़्यादा समझदार AI ढूँढने के बजाय, जाँच का कर्ता वापस इंसान को बना देना — मेरे लिए यही सबसे मामूली और सबसे असरदार एक कदम साबित हुआ।

अनुमति डिज़ाइन और प्रकाशन-पूर्व जाँच को पूरी टीम के काम-काज में उतारना हो, तो ट्रेनिंग और परामर्श में हम मिलकर ठोस डिज़ाइन बनाते हैं।