अध्याय 1 और 2 के बाद आपको यह पकड़ में आ गया होगा कि Claude Code है क्या और चलता कैसे है। इस अध्याय में हम बनाएँगे वह लय जिसे रोज़ एक ही ढाँचे में घुमाया जा सके ― खोज → प्लान → इम्प्लीमेंट → कमिट, ये चार ताल।
ढाँचे की ज़रूरत क्यों है, यह साफ़ है। जिस दिन काम नहीं बनता, उसकी वजह अक्सर यही होती है कि कोई ताल छूट गई। पढ़वाए बिना लिखवा दिया, जाँचने का ज़रिया दिए बिना सौंप दिया, बिना पड़ाव बनाए लगातार चलने दिया ― लक्षण अलग-अलग हों, लौटने की जगह वही है।
दिन का ढाँचा ― चार ताल पर घुमाइए
जुड़ी हुई फ़ाइलें पढ़वाइए, और मौजूदा हालत शब्दों में कहलवाइए। अभी लिखवाना नहीं।
तरीक़ा पहले निकलवाइए, और आप उसे सुधारिए। सुधार का सबसे सस्ता मौक़ा यही एक है।
लिखवाइए और वहीं-के-वहीं जाँच चलवाइए। अध्याय 1 वाला लूप पूरा घूमने दीजिए।
पास होते ही लौटने लायक़ एक निशान गाड़ दीजिए। अगली खोज यहीं से शुरू होगी।
एक चक्कर कितना बड़ा हो, इसका पैमाना है "बीच का हाल याद न रह पाए तो वह बहुत बड़ा है"। आधे दिन का एक चक्कर लगाने से, एक-एक घंटे के चार चक्कर लगभग हमेशा ज़्यादा टिकाऊ रहते हैं।
इसका मतलब यह नहीं कि हर बार चारों करने ही हैं। किसी टाइपो को ठीक करने के लिए प्लान नहीं चाहिए। तय यह करना है कि कौन-सी ताल छोड़ी जा सकती है, और शुरुआती सेटिंग है "चारों करना"।
शुरू करने से पहले, जाँचने का ज़रिया थमा दीजिए
चार तालों में घुसने से पहले एक काम बस एक ही बार करना है। Claude को पहले से वह ज़रिया थमा देना जिससे वह ख़ुद को ख़ुद जाँच सके।
अध्याय 1 में हमने देखा था कि भीतर जुटाना → करना → जाँचना का लूप चलता है। उसकी ताक़त STEP 3 के होने से है, क्योंकि टेस्ट पास होने तक वह ख़ुद सुधारता रह सकता है। इसे उलटकर देखें तो जाँचने का ज़रिया न हो तो लूप एक ही चक्कर में रुक जाता है ― लिख दिया, शायद सही है, बस। यह तो चैट वाले तरीक़े जैसा ही हुआ।
"टेस्ट पास करवा दो" कह देना काफ़ी है। फ़ेल का आउटपुट ही अगला इनपुट बन जाता है, और आपके देखे बिना भी लूप घूमता रहता है।
आप चलाते हैं, नतीजा बताते हैं, और फिर लिखवाते हैं। अड़चन आप ख़ुद बन जाते हैं। सौंपा है ऐसा बस लगता भर है।
जो थमाना है वह कोई बड़ी चीज़ नहीं। "यह कमांड चला लो तो पता चल जाएगा कि सही है या नहीं" ― बस इतनी एक लाइन काफ़ी है। और यह मुँह से कहने के बजाय फ़ाइल में लिख देना ज़्यादा पक्का है ― प्रोजेक्ट की जड़ में रखी CLAUDE.md दबाव के बाद भी डिस्क से दोबारा पढ़ी जाती है।
CLAUDE.md में लिख देने लायक़ चीज़ें (उदाहरण)
- बदलाव के बाद चलाने की कमांड: टेस्ट / टाइप चेक / लिंटर
- जब तक वे फ़ेल हैं, "हो गया" मत कहना
- जिन जगहों को नहीं छूना: जनरेट हुई चीज़ें, प्रोडक्शन सेटिंग वग़ैरह
ऐसा लिख देने पर, हर बार "टेस्ट चला लो" कहे बिना भी वह हर बदलाव के बाद ख़ुद जाँचने लगता है। बात यह नहीं कि आप कम निर्देश देते हैं, बात यह है कि निर्देश की ज़रूरत वाले मौक़े ही घट जाते हैं ― ढाँचे का फ़ायदा इसी तरह मिलता है (लिखने का तरीक़ा अध्याय 6 में)। अध्याय 1 ने जिन कामों को "ठीक नहीं बैठता" वाली तरफ़ रखा था, वे यहीं गिरते हैं, क्योंकि थमाने लायक़ जाँच का कोई ज़रिया ही नहीं होता।
खोज ― लिखवाने से पहले पढ़वाइए
पहली ताल। काम बस एक है ― जुड़ी हुई फ़ाइलें पढ़वाइए और यह समझाने को कहिए कि अभी हालत क्या है। अभी लिखवाना नहीं। इसे छोड़ देंगे तो Claude जो हिस्सा उसने पढ़ा ही नहीं, उसे अंदाज़े से भर देगा। देखने में सही-सा कोड लौटेगा, जो बाक़ी कोड के लिखने के ढंग से हल्का-सा अलग होगा, और यह फ़ासला आपको रिव्यू में या प्रोडक्शन में पता चलेगा।
ख़राब खोज: "ऑथेंटिकेशन ठीक कर दो"
→ एडिट तुरंत शुरू। किस बात को मानकर चला, यह दिखता ही नहीं
अच्छी खोज: "ऑथेंटिकेशन से जुड़ी फ़ाइलें ढूँढ़कर पढ़ो।
अभी लॉगिन कैसे संभाला जा रहा है, यह
जुड़ी हुई फ़ाइलों की सूची के साथ समझाओ।
अभी कुछ भी मत बदलना।"
→ मान्यताएँ स्क्रीन पर आ जाती हैं। ग़लत हों तो यहीं ठीक कर लीजिए
जो समझाइश लौटे, उसे पढ़िए। दख़ल देने की सबसे सस्ती जगह यही है। "वह फ़ाइल तो अब इस्तेमाल ही नहीं होती" ― इस एक वाक्य की क़ीमत, ग़लत इम्प्लीमेंटेशन को रिव्यू में पकड़ने की क़ीमत का कोई एक बटा तीस-चालीसवाँ हिस्सा है।
एक बात और, खोज की अपनी क़ीमत भी है। जो फ़ाइलें पढ़ी जाती हैं वे कॉन्टेक्स्ट में चढ़ जाती हैं, इसलिए खोज जितनी चौड़ी, आगे की गुंजाइश उतनी कम ― अध्याय 1 वाला "भर जाए तो सुस्त पड़ता है और शुरुआती हिस्सा भूलता है" यहीं से शुरू होता है। इसे थामने के तीन तरीक़े हैं।
- दायरा काटिए ― "फ़िलहाल सिर्फ़ ऑथेंटिकेशन वाला हिस्सा" कहकर सीमित कीजिए। पूरी तस्वीर चाहिए, पूरी फ़ाइलें नहीं
- बड़ी फ़ाइलें टुकड़ों में पढ़वाइए ― पूरी की पूरी पढ़वाएँगे तो एक ही झटके में जगह भर जाएगी। लाइनों की रेंज या फ़ंक्शन भर से काम चल जाता है
- ज़्यादा आउटपुट वाली छानबीन अलग कीजिए ― लॉग खंगालना या भारी सर्च सबएजेंट को दे दीजिए। उसका अपना कॉन्टेक्स्ट होता है और लौटता सिर्फ़ सारांश है, इसलिए मुख्य सेशन फूलता नहीं (अध्याय 6)
प्लान ― प्लान मोड कब काम आता है, कब बोझ है
दूसरी ताल। क्या-क्या और किस क्रम में बदलना है, यह लिखना शुरू करने से पहले निकलवाइए। Claude Code में इसी ताल के लिए एक प्लान मोड है, जो छानबीन करके प्लान सामने रखने पर रुक जाता है और जब तक आप मंज़ूरी न दें, लिखने की तरफ़ बढ़ता नहीं। इसे बदलने का तरीक़ा वर्ज़न के साथ बदलता रहता है, तो अपने वर्ज़न की हेल्प में देख लीजिए।
असल बात यह है कि परमिशन का गेट "हर एडिट पर" से हटकर "काम के दरवाज़े पर" चला जाता है। डिफ़ॉल्ट में हर टूल कॉल पर पुष्टि आती है, जबकि प्लान मोड उसे एक ही बार में समेटकर आगे ले आता है। और मंज़ूरी भी "इस एक लाइन" की नहीं, "इस काम की दिशा" की होती है।
कई फ़ाइलों में फैला काम / करने के दो या ज़्यादा तरीक़े हों / मौजूदा डिज़ाइन से मेल बिठाना ज़रूरी हो / ग़लती होने पर वापसी झंझट भरी हो / आपने ख़ुद भी अभी सबसे अच्छी चाल तय न की हो
करने को बस एक ही चीज़ हो / तरीक़ा पहले से तय हो / फ़ेल होने पर तुरंत वापस लौटा जा सके / प्लान पढ़ने में इम्प्लीमेंट करने से ज़्यादा वक़्त लगे
दाईं तरफ़ वाले को बेझिझक छोड़ दीजिए। प्लान मुफ़्त नहीं है ― उसे बनाने का वक़्त, पढ़ने का वक़्त और कॉन्टेक्स्ट, तीनों ख़र्च होते हैं। प्लान हाथ में आए तो देखने की चीज़ें बस तीन हैं। 1. मान्यताएँ सही हैं या नहीं (पहली ताल गड़बड़ हुई तो पूरा प्लान उसी के साथ गड़बड़ है)। 2. जाँच उसमें है या नहीं ("टेस्ट पास करवाना" नदारद हो तो जोड़ दीजिए)। 3. क़दम काफ़ी छोटे हैं या नहीं (जो प्लान सब कुछ एक ही चाल में कर डालता है, उसके फ़ेल होने पर आप वजह पकड़ ही नहीं पाएँगे)।
लंबा काम हो तो प्लान को फ़ाइल में उतार लीजिए। जो प्लान सिर्फ़ बातचीत के भीतर रहता है, सेशन लंबा होते ही सारांश में दब जाता है। PLAN.md जैसी किसी जगह लिखवा रखेंगे तो कॉन्टेक्स्ट समेट देने के बाद भी उसे दोबारा पढ़ा जा सकता है, और उठकर वापस आने पर वही फिर से शुरू करने का बिंदु बन जाता है।
इम्प्लीमेंट ― छोटे टुकड़ों में, चलाते-चलाते सुधारते हुए
तीसरी ताल। यहाँ आकर आख़िरकार लिखवाना है। नियम दो हैं।
पहला, हर एक चाल के बाद जाँच चलवाइए। पाँच बदलाव इकट्ठे करके फिर टेस्ट करेंगे तो फ़ेल होने पर "इनमें से कौन-सा ज़िम्मेदार है" छाँटने का एक अलग काम पैदा हो जाएगा। एक लिखा और एक पास करवाया, तो वजह पिछली एक ही चाल है। यह तरीक़ा Claude के लिए कम, आपके लिए ज़्यादा है।
दूसरा, फ़ेल का आउटपुट जस-का-तस थमा दीजिए। उसे समेटकर दोबारा कहने की ज़रूरत नहीं। STEP 3 है ही "आउटपुट पढ़ो और STEP 1 पर लौटो", इसलिए कच्चा आउटपुट ही वह इनपुट है जिसमें सबसे ज़्यादा जानकारी होती है। उसे चबाकर देंगे तो सुराग़ उलटे घट जाएँगे।
इम्प्लीमेंट करते वक़्त एक चक्कर (इसे छोटे-छोटे टुकड़ों में दोहराइए)
[EDIT] प्लान का ठीक एक आइटम बदलिए
↓
[RUN] टेस्ट / टाइप चेक चलाइए
↓
हरा → अगले आइटम पर (या कमिट)
लाल → आउटपुट पढ़िए, वापस [EDIT] पर
एक ही जगह लगातार तीन बार लाल: सुधार माँगना बंद कीजिए
→ हाथ रोकिए और छानबीन पर आइए (अध्याय 4)
आख़िरी लाइन तजुर्बे की बात है। वही नाकामी दोहराने लगे तो अक्सर यह इशारा "अब बस थोड़ा-सा और" का नहीं, "मान्यता ही ग़लत है" का होता है।
जब जाँच में वक़्त लगे ― लंबे बिल्ड या CI के पूरा होने का इंतज़ार ― तो सामने बैठे रहने के बजाय काम सौंपकर हट जाने का भी एक रास्ता है। Claude Code में किसी निर्देश को तय अंतराल पर दोहराने की एक व्यवस्था है, और अंतराल न बताएँ तो अगली बार कब देखने आना है यह Claude ख़ुद तय करता है, और काम पूरा मान लेने पर लूप रोक देता है। इसकी व्यवस्था और सीमाएँ /loop कमांड क्या है में हैं। ध्यान रहे कि सेशन बंद करते ही यह रुक जाता है।
कमिट ― पड़ाव आप ख़ुद तय कीजिए
चौथी ताल। टेस्ट पास हो जाएँ तो उसी वक़्त कमिट कीजिए। "किसी ठीक-ठाक पड़ाव तक पहुँच जाऊँ तब" नहीं ― जिस पल वह पास हुआ, वही ठीक-ठाक पड़ाव है।
- लौटने की जगह बन जाती है ― अगली चाल फ़ेल हो जाए तो भी आप उस जगह पर पक्के तौर पर लौट सकते हैं जहाँ सब हरा था
- डिफ़ पढ़ने लायक़ आकार का रहता है ― आधे दिन के बदलाव पढ़े नहीं जाते। और जो डिफ़ पढ़ा न जाए उसका रिव्यू असल में होता ही नहीं
- बातचीत काटी जा सकती है ― नतीजा भीतर सुरक्षित हो तो सेशन फेंक देने में डर नहीं लगता
कमिट मैसेज भी लिखवा सकते हैं, लेकिन डिफ़ देखे बिना मंज़ूरी मत दीजिए। "क्या बदला" नहीं, बल्कि "कहीं वह चीज़ तो नहीं घुस गई जिसे बदलने का इरादा ही नहीं था" ― यह देखना तय कर लें, तो नज़र फिसलेगी नहीं।
और ध्यान रहे, कमिट और पुश दो अलग फ़ैसले हैं। डिप्लॉय जैसे वापस लेने में मुश्किल काम कहाँ तक सौंपने हैं, यह अध्याय 5 में है।
सेशन को समेटना, और पीछे लौटना
चारों ताल कुछ चक्कर घुमाते ही आप उस समस्या से ज़रूर टकराएँगे कि कॉन्टेक्स्ट भरने लगा है। अध्याय 1 वाले दो लक्षण ― जवाब सुस्त पड़ना, शुरुआती हिस्सा भूलना ― दिखें तो समेटने का वक़्त आ गया। तरीक़े दो हैं, दबाना या नए सिरे से शुरू करना, और बँटवारा एक ही बात पर है।
आगे जो आना है वह "इसी का अगला हिस्सा" हो तो दबाइए ― पूरा किस्सा सारांश के रूप में आगे ले जाया जा सकता है, और अपने आप चलने वाले दबाव से फ़र्क़ यही है कि आप बता सकते हैं कि क्या बचाना है। आगे जो आना है वह "अलग मामला" हो तो नए सिरे से शुरू कीजिए ― जब सारांश की भी ज़रूरत नहीं, तो सारांश बनाने का ख़र्च भी नहीं चाहिए। बेमतलब का पुराना काम साथ न घिसटने से सटीकता भी बेहतर रहती है।
समय का भी एक ढाँचा है। घड़ी या प्रतिशत देखकर नहीं, काम के पड़ाव पर दबाइए ― जब एक चक्कर पूरा हो और आप अगले लंबे काम में घुसने वाले हों। बीच में दबा देंगे तो वे ब्योरे भी सारांश में दब जाएँगे जो आगे काम आने थे। इसका आधार क्या /compact नियम से दबाते रहना चाहिए में दिया गया है।
समेटने से पहले, जो चीज़ें खोनी नहीं चाहिए उन्हें फ़ाइल में निकाल लीजिए। प्रोजेक्ट की जड़ में रखी CLAUDE.md और अपने आप बनने वाली मेमोरी डिस्क से दोबारा पढ़ी जाती हैं, इसलिए कितनी भी बार समेटिए वे बची रहती हैं। लेकिन जो फ़ैसले सिर्फ़ बातचीत के भीतर हैं, वे सारांश में पतले पड़ जाते हैं।
एक और व्यवस्था है जो सौंपने के तरीक़े को ही बदल देती है। Claude Code हर प्रॉम्प्ट पर लौटने लायक़ एक बिंदु अपने आप बनाता चलता है, और गड़बड़ होने पर वहाँ तक पीछे लौटा जा सकता है। लौटाना किसे है, यह सिर्फ़ कोड, सिर्फ़ बातचीत, या दोनों में से चुना जा सकता है, और सबसे ज़्यादा काम आता है "कोड लौटा दो, बातचीत रहने दो" ― बदलाव ऐसे मिट जाते हैं जैसे हुए ही न हों, पर क्या ग़लत हुआ था यह याद रहते हुए आप बात दोबारा कह सकते हैं।
असर इसके इस्तेमाल की आसानी से नहीं, जोखिम उठाने के तरीक़े से पड़ता है। यह मानकर चलें कि लौटा नहीं सकते, तो एक-एक चाल पर पुष्टि करनी पड़ेगी और एजेंट इस्तेमाल करने का मतलब ही पतला पड़ जाएगा। लौटा सकते हैं यह पता हो, तो बड़ा काम सौंपा जा सकता है और आज़माओ, न बने तो फेंक दो एक विकल्प बन जाता है।
लेकिन लौटती सिर्फ़ वे फ़ाइलें हैं जिन्हें Claude ने एडिट टूल से बदला था। शेल कमांड से बनी या मिटी फ़ाइलें, आपके अपने एडिट, और डेटाबेस की हालत ― ये नहीं लौटतीं। यह Git की जगह नहीं ले सकता, और यह मानकर बना है कि आप पड़ावों पर कमिट भी करते रहेंगे। लकीर यूँ खींची जा सकती है ― जो काम फ़ाइल एडिट भर से पूरा हो जाता है उसे बड़े हिस्से में सौंप दीजिए। जो काम शेल के ज़रिए हालत बदलता है, उसे सौंपने से पहले कमिट कर लीजिए। ब्योरा चेकपॉइंट और पीछे लौटना में है।
रिव्यू करवाना ― लिखने वाले और पढ़ने वाले को अलग कीजिए
जिस कोड के टेस्ट पास हो गए, ज़रूरी नहीं कि वह अच्छा कोड भी हो। टेस्ट "कुछ टूटा नहीं है" की गारंटी तो देते हैं, पर "इसे इसी ढंग से लिखना ठीक था या नहीं" का जवाब नहीं देते।
नियम एक ही है। लिखने का संदर्भ और पढ़ने का संदर्भ अलग कीजिए। जिस बातचीत में अभी-अभी वह इम्प्लीमेंटेशन लिखा गया है, उसी में "रिव्यू करो" कहने पर वह अपने ही फ़ैसलों पर मुहर लगा देता है। जिस हालत में चुनाव की सारी वजहें सामने हों, वह कमियाँ खोजने के लिए ठीक नहीं है। ठोस रूप में तीन बातें।
- अलग सेशन में पढ़वाइए ― कमिट करके डिफ़ बनाइए, और किसी बिलकुल कोरी बातचीत को सिर्फ़ डिफ़ थमाइए। ऐसी आँखों से पढ़वाइए जो पिछला किस्सा जानती ही नहीं
- नज़रिया तय कीजिए ― "बेहतर कर दो" नहीं, बल्कि "सीमा की स्थितियाँ", "मौजूदा लिखने के ढंग से एकरूपता" ― ऐसी धुरी थमाइए। धुँधले अनुरोध से धुँधली ही टिप्पणियाँ निकलती हैं
- टिप्पणियों को आँख मूँदकर मत मानिए ― वे सही हैं या नहीं, यह असली चीज़ पर जाँचिए। सुधार करवाने से पहले, पहले पढ़िए
तीसरी बात इस अध्याय की बाक़ी बातों से जुड़ी है। रिव्यू "जाँच के ज़रिए से रहित काम" का सबसे बड़ा उदाहरण है, और सही-ग़लत अपने आप तय न होने की वजह से Claude पूरे आत्मविश्वास वाले लहजे में बेमतलब बातें भी कह देता है। उन्हें सीधे सुधार के निर्देश में बहा दिया, तो जो कोड सही था वह टूट जाएगा ― टिप्पणियों को उम्मीदवार मानिए और एक-एक करके फ़ैसला कीजिए। जब मन करे कि हर बार उन्हीं नज़रियों से घुमाया जाए, तो यह इशारा है कि इसे किसी व्यवस्था में उतार दिया जाए (अध्याय 6)।
कई सेशन एक साथ ― फ़ायदा कहाँ तक है
एक तरफ़ लंबा टेस्ट चल रहा हो और उतने में दूसरा काम आगे बढ़ा लिया जाए ― यह ख़याल अपने आप आता है। Claude Code में एक व्यवस्था है जिससे कई अलग-अलग सेशन पीछे चलाकर एक ही स्क्रीन से संभाले जा सकते हैं। कुल मिलाकर बात अलगाव की है ― बैकग्राउंड वाले सेशन कोई फ़ाइल एडिट करने से पहले अपनी ही अलग वर्किंग डायरेक्टरी में चले जाते हैं। यानी पढ़ना साझा, लिखना अलग, इसलिए एक ही फ़ाइल पर एक-दूसरे को मिटा देने वाला हादसा ढाँचे के स्तर पर होता ही नहीं। ब्योरा agent view और डिस्पैच में है।
जब काम एक-दूसरे से आज़ाद हों / बीच का हाल देखने की ज़रूरत न हो / नतीजा हाथ में आने के बाद फ़ैसला करना काफ़ी हो / एक तरफ़ लंबे इंतज़ार वाला काम हो
जब वे एक ही डिज़ाइन फ़ैसले पर टिके हों / बीच में दिशा दोबारा तय करनी पड़े / वापस न लिए जा सकने वाले काम शामिल हों / गिनती ही इतनी हो कि नतीजे जाँचे न जा सकें
दाईं तरफ़ की आख़िरी बात ही सबसे बड़ी अड़चन है। समांतर चलाने से रिव्यू की कुल मात्रा बढ़ जाती है। तीन काम फेंकेंगे तो तीन बार "सचमुच ऐसा ही है क्या" लौटकर आएगा, और जाँचने की मेहनत समांतर नहीं होती। कितने फेंके जा सकते हैं इसकी हद वही है जितनों के नतीजे आप जाँच सकते हैं। ख़र्च भी बढ़ता है ― बैकग्राउंड में है इसलिए सस्ता है, ऐसा कुछ नहीं (अध्याय 7)।
समांतर चलाना शुरू करने से पहले, परमिशन की सेटिंग दोबारा देख लीजिए। पीछे चलने वाले सेशन मौक़े पर चुनने के बजाय, सेटिंग्स से परमिशन उठा लेते हैं। जो लोग आम तौर पर ढीली सेटिंग रखते हैं, उनके यहाँ उतनी ही गिनती में "ढीली परमिशन वाले, और कोई न देखने वाला" सेशन पैदा हो जाते हैं। पहले अध्याय 5।
मामूली लगता है पर हादसे इसी में ज़्यादा होते हैं ― सफ़ाई। पीछे चलने वाले सेशन ने जो कार्यस्थल बनाया था, वह सेशन मिटाते ही उसके साथ ही मिट जाता है। "ख़त्म हो गया" और "ले लिया गया" अलग बातें हैं ― मिटाने से पहले कमिट कीजिए।
सारांश
- दिन की लय है खोज → प्लान → इम्प्लीमेंट → कमिट, ये चार ताल। गड़बड़ी की वजह अक्सर यही होती है कि कोई ताल छूट गई
- शुरू करने से पहले जाँचने का ज़रिया थमाइए। न हो तो जुटाना → करना → जाँचना वाला लूप एक ही चक्कर में रुक जाता है
- खोज में लिखवाने से पहले पढ़वाइए। पर जितना पढ़ा जाएगा उतनी गुंजाइश घटेगी, इसलिए दायरा काटिए
- प्लान वह व्यवस्था है जो परमिशन के गेट को काम के दरवाज़े पर समेट देती है। एक चाल में निपटने वाले काम के लिए यह बोझ है
- इम्प्लीमेंट में हर चाल पर जाँचिए, और तीन बार फ़ेल हो तो छानबीन पर आइए। कमिट उसी पल कीजिए जब वह पास हो
- समेटें या नए सिरे से शुरू करें, यह इस पर है कि "आगे वही काम है या अलग मामला"। समेटने से ठीक पहले फ़ाइल में लिख लीजिए
- पीछे लौटना सिर्फ़ फ़ाइल एडिट लौटाता है। शेल के ज़रिए हुए बदलाव नहीं लौटते, इसलिए कमिट भी साथ चलाइए
- रिव्यू को लिखने के संदर्भ से काट दीजिए, और टिप्पणियों को उम्मीदवार मानिए। समांतर की हद है जितनों को आप जाँच सकते हैं
ढाँचा बन जाने के बाद भी, अटकना हो तो अटकना होता ही है। अगले अध्याय में छानबीन का क्रम अपने पास रख लीजिए। अब अध्याय 4 "अटकन से निकलना" पर बढ़ें।