17 दिस॰ 2025·8 मिनट
Prompt-to-PR वर्कफ़्लो Claude Code के साथ: छोटे diffs
Claude Code के साथ लोकल Prompt-to-PR वर्कफ़्लो: छोटे प्रॉम्प्ट लिखें, छोटे diffs भेजें, चेक चलाएँ, फेल्योर पर फिर से प्रॉम्प्ट करें और मर्ज-तैयार PRs तक पहुँचें।
Claude Code के साथ लोकल Prompt-to-PR वर्कफ़्लो: छोटे प्रॉम्प्ट लिखें, छोटे diffs भेजें, चेक चलाएँ, फेल्योर पर फिर से प्रॉम्प्ट करें और मर्ज-तैयार PRs तक पहुँचें।
बड़े एक-शॉट प्रॉम्प्ट अक्सर बड़े, गंदे बदलाव देते हैं: दर्जनों फाइलें छुई जाती हैं, असंबंधित रिफैक्टर्स होते हैं और वह कोड जो आपने समझने का समय नहीं पाया। भले ही आउटपुट तकनीकी रूप से सही हो, समीक्षा जोखिम भरी लगती है क्योंकि यह बताना मुश्किल होता है कि क्या बदला और क्यों।
छोटे diffs इसे ठीक कर देते हैं। जब हर बदलाव सीमित और फ़ोकस्ड होता है, आप उसे मिनटों में पढ़ सकते हैं, गलतियाँ जल्दी पकड़ सकते हैं और उन चीज़ों को तोड़ने से बच सकते हैं जिन्हें आप छूना नहीं चाहते। समीक्षा करने वाले छोटे PRs पर ज़्यादा भरोसा करते हैं, इसलिए मर्ज तेज़ी से और कम बैक-एंड-फ़ोर्थ कमेंट्स के साथ होते हैं।
Prompt-to-PR एक सरल लूप है:
यह ताल विफलताओं को आख़िरी क्षण के सप्राइज़ के बजाय तेज़ फ़ीडबैक में बदल देती है। अगर आप Claude Code से किसी वैलिडेशन नियम को एडजस्ट करने के लिए कहते हैं, तो इसे उसी एक नियम तक सीमित रखें। अगर कोई टेस्ट फेल होता है, तो फेलिंग आउटपुट पेस्ट करें और वही सबसे छोटा फ़िक्स माँगें जो टेस्ट पास कराए, न कि पूरे मॉड्यूल का री-राइट।
एक बात नहीं बदलती: अंतिम कोड के लिए आप ज़िम्मेदार हैं। मॉडल को एक लोकल पेयर प्रोग्रामर मानें जो तेज़ टाइप करता है, ऑटोपायलट नहीं। आप तय करते हैं क्या जाना है, क्या रहना है, और कब PR खोलना सुरक्षित है।
साफ़ बेसलाइन से शुरू करें। अगर आपकी ब्रांच पीछे है या टेस्ट पहले से फेल कर रहे हैं, तो हर सुझाव अटकल बन जाता है। लेटेस्ट चेंजेस पुल करें, अपनी टीम की पसंद के अनुसार rebase या merge करें, और कुछ भी माँगने से पहले मौजूदा स्थिति हेल्दी हो यह सुनिश्चित करें।
"लोकल पेयर प्रोग्रामर" सेटअप का मतलब है कि Claude Code आपकी रिपो में फाइलें एडिट करता है जबकि आप लक्ष्य, निगरानी और हर diff पर नियंत्रण बनाए रखते हैं। मॉडल आपका कोडबेस तब तक नहीं जानता जब तक आप उसे नहीं दिखाते, इसलिए फाइलें, प्रतिबंध और अपेक्षित व्यवहार स्पष्ट रूप से बताएं।
पहले प्रॉम्प्ट से पहले तय करें कि चेक कहाँ चलेंगे। अगर आप लोकल में टेस्ट चला सकते हैं, तो आपको मिनटों में फ़ीडबैक मिलेगा, जो इटरेशन्स को छोटा रखता है। अगर कुछ चेक केवल CI में चलते हैं (कुछ lint नियम, लंबी सूट्स, build स्टेप्स), तो तय करें कि आप कब CI पर निर्भर होंगे ताकि हर छोटे बदलाव के बाद आपको प्रतीक्षा न करनी पड़े।
एक सरल प्री-फ़्लाइट:
काम करते समय एक छोटा स्क्रैचपैड खुला रखें। उन प्रतिबंधों को लिखें जैसे "कोई API बदलाव नहीं," "व्यवहार backward compatible रखें," "केवल X मॉड्यूल छूएँ," और जो निर्णय आप लेते हैं। जब कोई टेस्ट फेल हो, तो ठीक फ़ेल्योर मैसेज भी वहाँ पेस्ट कर दें। वह स्क्रैचपैड आपके अगले प्रॉम्प्ट के लिए सबसे अच्छा इनपुट बन जाता है और सेशन को भटकने से रोकता है।
छोटे diffs जानबूझकर संकीर्ण प्रॉम्प्ट से शुरू होते हैं। मर्ज-योग्य कोड का सबसे तेज़ रास्ता एक ऐसा बदलाव है जिसे आप एक मिनट में रिव्यू कर सकें, न कि एक ऐसा रिफैक्टर जिसे समझने में एक घंटा लगे।
एक अच्छा प्रॉम्प्ट एक ही लक्ष्य, कोडबेस का एक क्षेत्र, और एक अपेक्षित नतीजा नामित करता है। अगर आप यह नहीं बता सकते कि बदलाव कहाँ आना चाहिए (एक फ़ाइल, फोल्डर, या मॉड्यूल), मॉडल अनुमान लगाएगा और diff फैल सकता है।
एक प्रॉम्प्ट का स्वरूप जो बदलावों को टाइट रखता है:
सीमाएँ गुप्त हथियार हैं। "लॉगिन बग ठीक करें" के बजाय बताएं क्या स्थिर रहना चाहिए: "API shape न बदलें," "पब्लिक फंक्शंस का नाम न बदलें," "केवल फ़ॉर्मैटिंग-एडिट्स न करें," "नई dependencies से बचें।" इससे आपका पेयर प्रोग्रामर कहीं चालाकी नहीं करेगा।
जब बदलाव अभी भी अस्पष्ट लगे, तो कोड मांगने से पहले एक योजना माँगें। एक छोटी योजना काम को स्टेप्स में बांधती है और आपको छोटे पहले कदम को मंज़ूर करने का मौका देती है।
Goal: Fix the null crash when rendering the profile header.
Location: src/components/ProfileHeader.tsx only.
Constraints: Do not change styling, props, or any exported types.
Expected outcome: If user.name is missing, show "Anonymous" and no crash.
Diff constraint: Minimal diff. No refactors. No unrelated formatting.
If unclear: First reply with a 3-step plan, then wait for approval.
अगर आप टीम पर काम कर रहे हैं, तो review प्रतिबंध भी जोड़ें: "~30 लाइनों से कम बदलें" या "यदि बहुत ज़रूरी न हो तो एक फाइल ही छुएँ।" यह diff को स्कैन करना आसान बनाता है और जब कुछ फेल होता है तो फॉलो-अप प्रॉम्प्ट्स और तेज़ होते हैं।
हर लूप को एक छोटे, टेस्टेबल बदलाव पर केन्द्रित रखें। अगर आप एक वाक्य में लक्ष्य बता सकते हैं और अनुमान लगा सकते हैं कि कौन-सी फाइलें बदलेंगी, तो यह सही आकार है।
अच्छे यूनिट्स में शामिल हैं: एक पाथ में एक बग ठीक करना (repro और गार्ड के साथ), एक व्यवहार के लिए एक टेस्ट समायोजित करना, व्यवहार-प्रवर्तक रिफैक्टर (rename, extract function, duplicate हटाना), या एक त्रुटि संदेश या वैलिडेशन नियम बेहतर करना।
हर लूप के लिए समय सीमित करें। 10–20 मिनट आम तौर पर पर्याप्त होते हैं एक स्पष्ट प्रॉम्प्ट लिखने, diff लागू करने और एक त्वरित चेक चलाने के लिए। अगर आप 20 मिनट के बाद भी खोज में हैं, तो यूनिट को छोटा करें या सिर्फ़ इन्वेस्टिगेशन मोड (नोट्स, लॉगिंग, failing test) में बदलें और वहीं रोक दें।
शुरू करने से पहले "डन" परिभाषित करें:
जब स्कोप बढ़ने लगे तो जल्दी रुकें। यदि आप खुद को कहते हुए पाएँ "इतना करते हुए," तो आपने अगले इटरेशन को खोज लिया है। उसे फॉलो-अप के रूप में कैप्चर करें, वर्तमान छोटे diff को commit करें, और आगे बढ़ें।
टेस्ट या बिल्ड चलाने से पहले diff को एक रिव्यूअर की तरह पढ़ें। यहीं वर्कफ़्लो साफ़ रहता है या धीरे-धीरे उस स्थिति में चला जाता है जहां आप सोचते हैं "यह फ़ाइल क्यों छुई गई?"।
शुरू करने के लिए Claude Code से पूछें कि उसने साधारण भाषा में क्या बदला: छुई हुई फाइलें, व्यवहार में बदलाव, और क्या नहीं बदला। अगर वह बदलाव को स्पष्ट रूप से समझा नहीं सकता, तो संभवतः diff बहुत ज़्यादा कर रहा है।
फिर खुद समीक्षा करें। पहले स्किम करें स्कोप के लिए, फिर इरादा समझने के लिए पढ़ें। आप ड्रिफ्ट ढूँढ रहे हैं: unrelated फॉर्मैटिंग, अतिरिक्त रिफैक्टर्स, सिम्बल्स का नाम बदलना, या अनुरोधित न होने वाले बदलाव।
एक त्वरित प्री-चेक:
अगर diff अपेक्षित से बड़ा है, तो इसे परखकर हल करने की कोशिश मत करें। रोल बैक करें और छोटे कदम के लिए फिर से प्रॉम्प्ट करें। उदाहरण: "सिर्फ़ फेलिंग टेस्ट जोड़ो जो बग को पुनरुत्पादित करे। कोई रिफैक्टर नहीं।" छोटे diffs विफलताओं को आसान बनाते हैं और अगले प्रॉम्प्ट को सटीक रखते हैं।
छोटे diffs तभी लाभदायक होते हैं जब आप उन्हें तुरंत सत्यापित करें। लक्ष्य एक तंग लूप है: थोड़ा बदलो, थोड़ा चेक करो, संदर्भ ताज़ा होने पर गलतियाँ पकड़ लो।
सबसे तेज़ चेक से शुरू करें जो बता सके "यह टूटा हुआ है।" अगर आपने फॉर्मैटिंग या इम्पोर्ट बदले हैं, तो पहले lint या formatting चलाएँ। अगर आप ने बिज़नेस लॉजिक छेड़ा है, तो उस फ़ाइल या पैकेज को कवर करने वाले सबसे छोटे यूनिट टेस्ट चलाएँ। अगर आपने प्रकार या build config एडिट किया है, तो एक त्वरित compile चलाएँ।
एक व्यावहारिक क्रम:
जब कुछ फेल हो, तो कुछ भी ठीक करने से पहले दो चीज़ें कैप्चर करें: आपने कौन-सा कमांड चलाया और पूरा त्रुटि आउटपुट (जैसा है वैसा कॉपी करें)। वह रिकॉर्ड अगले प्रॉम्प्ट को सटीक बना देता है और "यह अभी भी फेल है" के चक्र को रोकता है।
स्कोप को टाइट रखें। अगर lint फेल और टेस्ट भी फेल, पहले lint ठीक करें, पुनः चलाएँ, फिर टेस्ट ठीक करें। एक ही पास में "त्वरित साफ़-सफाई" और क्रैश फ़िक्स मत मिलाइए।
जब चेक फेल हों, तो फेल्योर आउटपुट को अपने अगले प्रॉम्प्ट की तरह ट्रीट करें। सबसे तेज़ लूप है: त्रुटि पेस्ट करें, डायग्नोसिस पाएं, सबसे छोटा फिक्स लागू करें, फिर से चलाएँ।
फेल्योर को शब्दशः पेस्ट करें, जिसमें कमांड और पूरा स्टैक ट्रेस शामिल हो। सबसे पहले सबसे संभावित कारण माँगें, न कि विकल्पों की सूची। Claude Code तब बेहतर करता है जब यह सटीक लाइन नंबरों और संदेशों पर ऐंकर कर सके बजाय अनुमान के।
एक वाक्य जोड़ें कि आपने पहले क्या कोशिश की ताकि वह आपको चकमक में न भेजे। उन प्रतिबंधों को दोहराएँ जो मायने रखते हैं ("public APIs न बदलें," "बस क्रैश ठीक करें"), फिर सबसे छोटा पैच माँगें जो चेक पास कराए।
एक अच्छा फेल्योर प्रॉम्प्ट शामिल करता है:
अगर प्रस्तावित फिक्स व्यवहार बदलता है, तो ऐसा टेस्ट माँगें जो नए व्यवहार को प्रमाणित करे। अगर कोई हैंडलर अब 400 लौटाता है बजाय 500 के, तो एक फ़ोकस्ड टेस्ट माँगें जो पुराने कोड पर फेल हो और फिक्स पर पास हो। यह काम ईमानदार रखता है और PR पर भरोसा बढ़ाता है।
रुकें जब चेक हरे हों और diff अभी भी एक ही विचार जैसा लगे। अगर मॉडल अनवांटेड कोड सुधारने लगे, तो फिर से प्रॉम्प्ट करें: "सिर्फ़ फेलिंग टेस्ट को एड्रेस करो। कोई क्लीनअप नहीं।"
एक PR तब सबसे तेज़ी से मर्ज होता है जब यह स्पष्ट हो कि क्या बदला, क्यों बदला, और कैसे इसे साबित करें। इस वर्कफ़्लो के साथ, PR को एक छोटी कहानी की तरह पढ़ना चाहिए: छोटे कदम, स्पष्ट कारण।
कमिट्स को आपकी इटरेशन्स के अनुरूप रखें। अगर आपने एक व्यवहार परिवर्तन माँगा, उसे एक कमिट में रखें। फिर अगर आपने एक फेलिंग टेस्ट ठीक किया, वह अगला कमिट हो। रिव्यूअर रास्ता फ़ॉलो कर सकते हैं और भरोसा कर सकेंगे कि आपने अतिरिक्त बदलाव नहीं छिपाए।
कमिट मैसेज्स इरादे के लिए लिखें, नहीं फ़ाइल नामों के लिए। "Fix login redirect when session expires" बेहतर है बनाम "Update auth middleware." जब संदेश यूजर-फेसिंग परिणाम नाम देता है, तो रिव्यूअर कम समय अनुमान लगाते हैं।
रिफैक्टर्स को व्यवहार परिवर्तनों के साथ मिलाने से बचें। अगर आप वेरिएबल्स का नाम बदलना या हेल्पर्स को मूव करना चाहते हैं, तो अलग करें (या अभी छोड़ दें)। शोर समीक्षा धीमा कर देता है।
PR विवरण संक्षिप्त और ठोस रखें:
उदाहरण: एक बिलिंग पेज क्रैश null customer रिकॉर्ड की वजह से। कमिट 1 में गार्ड और स्पष्ट एरर स्टेट जोड़ा गया। कमिट 2 में null केस के लिए टेस्ट जोड़ा गया। PR विवरण कहता है: "Open Billing, load a customer with no profile, confirm the page shows the new empty state." यही वर्जन का PR रिव्यूअर तेज़ी से अप्रूव कर देते हैं।
यह ताल तब टूटती है जब स्कोप चुपचाप बढ़ता है। एक प्रॉम्प्ट जो "इस फेलिंग टेस्ट को ठीक करें" से शुरू होता है, "मॉड्यूल भर में एरर हैंडलिंग सुधारो" में बदल सकता है, और अचानक आप एक बड़े diff की समीक्षा कर रहे हैं जिसकी जड़ स्पष्ट नहीं। इसे टाइट रखें: एक लक्ष्य, एक बदलाव सेट, एक चेक सेट।
एक और धीमापन यह है कि अच्छे दिखने वाले रिफैक्टर्स को स्वीकार कर लेना सिर्फ इसलिए कि वे सुंदर लगते हैं। नाम बदलना, फाइल मूव करना और स्टाइल बदलाव रिव्यू में शोर पैदा करते हैं और असली व्यवहार परिवर्तन को पकड़ना मुश्किल कर देते हैं।
सामान्य जाल:
एक ठोस उदाहरण: एक टेस्ट फेल होता है "expected 400, got 500." अगर आप केवल स्टैक ट्रेस की आख़िरी पंक्ति पेस्ट करते हैं, तो अक्सर आपको सामान्य try/catch सुझाव मिलते हैं। अगर आप पूरा टेस्ट आउटपुट पेस्ट करते हैं, तो असली मसला दिख सकता है: एक गायब वैलिडेशन ब्रांच। इससे एक छोटा, फ़ोकस्ड diff मिलता है।
कमिट करने से पहले, diff को रिव्यूअर की तरह पढ़ें। पूछें: क्या हर लाइन अनुरोध की सेवा करती है, और क्या मैं इसे एक वाक्य में समझा सकता हूँ? अगर नहीं, तो अतिरिक्त बदलाव revert करें और नारे प्रॉम्प्ट के साथ फिर से मांगें।
एक यूज़र रिपोर्ट करता है: "Settings पेज कभी-कभी सेव करने के बाद डिफ़ॉल्ट पर लौट जाता है।" आप main खींचते हैं, टेस्ट चलाते हैं, और एक फ़ेलियर देखते हैं। या कोई टेस्ट नहीं है, केवल एक साफ़ repro।
इसे एक लूप की तरह ट्रीट करें: एक छोटा अनुरोध, एक छोटा diff, फिर चेक।
सबसे पहले, Claude Code को सबसे छोटा उपयोगी संदर्भ दें: फेलिंग टेस्ट आउटपुट (या पुनरुत्पादन के कदम), आप जिस फ़ाइल पथ को संदेह करते हैं, और लक्ष्य ("reset ठीक करें लेकिन अन्य व्यवहार वही रखें")। निदान और एक न्यूनतम पैच माँगें, न कि रिफैक्टर।
फिर छोटे लूप्स में काम करें:
रिव्यू का बाद चेक चलाएँ।
अगर चेक पास हो जाएँ पर आप रिग्रेशन से चिंतित हों, तो कवरेज जोड़ें।
अंत में एक छोटा PR विवरण दें: बग क्या था, क्यों हुआ, और क्या बदला। एक रिव्यूअर नोट जोड़ें जैसे "सिर्फ़ X फ़ाइल छूती है" या "reset केस के लिए एक टेस्ट जोड़ा गया" ताकि रिव्यू सुरक्षित लगे।
PR खोलने से ठीक पहले एक आख़िरी पास करें ताकि काम समीक्षा में आसान और मर्ज के लिए सुरक्षित हो।
एक त्वरित उदाहरण: अगर आपने लॉगिन बग ठीक किया पर साथ ही 20 फाइलों का फॉर्मैटिंग कर दिया, तो फॉर्मैटिंग commit वापस ले लें। आपके रिव्यूअर को लॉगिन फिक्स पर फोकस करना चाहिए, यह सोचकर नहीं कि और क्या बदल गया।
अगर कोई आइटम फेल हो, तो एक और छोटा लूप करें: एक छोटा diff बनाएं, चेक फिर से चलाएँ, और PR नोट अपडेट करें। वह आख़िरी लूप अक्सर घंटों के बैक-एंड-फ़ोर्थ बचा देता है।
नियमितता एक अच्छे से विश्वसनीय वर्कफ़्लो बनाती है। एक डिफ़ॉल्ट लूप चुनें और हर बार वैसा ही चलाएँ। एक हफ्ते के बाद आप नोट करेंगे कि आपके प्रॉम्प्ट छोटे होते जा रहे हैं और आपके diffs समीक्षा में आसान।
एक सरल रूटीन:
एक व्यक्तिगत प्रॉम्प्ट टेम्पलेट आपको अनुशासित रखता है: "केवल आवश्यक बदलाव करो। अधिकतम 2 फाइलें छुओ। सार्वजनिक व्यवहार वही रखें जब तक मैं न कहूँ। चलाने के लिए कमांड बताओ और सफलता कैसी दिखेगी।"
अगर आप Koder.ai में बिल्ड कर रहे हैं, आप उसी लूप का उपयोग उसकी चैट इंटरफ़ेस में कर सकते हैं। Planning mode सबसे छोटा मर्जेबल स्लाइस निर्धारित करने के लिए अच्छा है (इनपुट, आउटपुट, और स्वीकृति चेक), और snapshots व rollback आपको एक्सपेरिमेंट्स से जल्दी वापस आने में मदद करते हैं।
एक बार बदलाव स्थिर हो जाने पर, स्रोत कोड एक्सपोर्ट करें ताकि आप अपने सामान्य लोकल टूलिंग, CI और सहकर्मी समीक्षा में चला सकें। वास्तविक दुनिया में मान्य करने के लिए डिप्लॉय करें, जैसे किसी फ्लो को end-to-end चेक करना।
लूप को अपना डिफ़ॉल्ट बनाइए। छोटे प्रॉम्प्ट, छोटे diffs, बार-बार चेक, और तेज़ सुधार मिलकर ऐसे PR बनाते हैं जो सबसे अच्छे तरीके से बोरिंग लगते हैं।
डिफ़ॉल्ट: एक छोटा, समीक्षा योग्य परिवर्तन लक्ष्य बनाएं जिसे आप एक वाक्य में समझा सकें।
एक अच्छा नियम यह है: आप अनुमान लगा सकते हैं कि कौन-से file(s) बदलेंगे, और आप इसे एक तेज़ चेक (एक लक्षित टेस्ट, lint, या त्वरित रन) से वैलिडेट कर सकते हैं। अगर आप नहीं कर पाते, तो कार्य अभी भी बड़ा है—इसे अलग-अलग लूप्स में बांट दें जैसे “repro test जोड़ें” और “बग ठीक करें।”
हाँ—जब लक्ष्य धुंधला हो, तो पहले एक संक्षिप्त योजना माँगें।
एक सरल गेट का उपयोग करें:
इससे मॉडल अनुमान लगाकर अतिरिक्त फाइलों को छूने से रोका जाता है।
अपने प्रॉम्प्ट में ये बुनियादी बातें शामिल करें:
तुरंत रुकें और दायरे को छोटा करें।
व्यावहारिक कदम:
X फ़ाइल को छूएँ। कोई रिफैक्टर नहीं। कोई unrelated फॉर्मैटिंग नहीं।”एक फैलते हुए diff को "टेस्ट करके सुलझाने" की कोशिश अक्सर छोटे पुनःकिए गए काम से ज़्यादा समय ले जाती है।
पहले diff पढ़ें, फिर चेक चलाएँ.
सरल क्रम:
यह लूप को टाइट रखता है और फेल्योर को समझना आसान बनाता है।
फेल्योर को शब्दशः पेस्ट करें और सबसे छोटा फिक्स माँगें.
शामिल करें:
"यह अभी भी फेल हो रहा है" बिना विवरण के भेजने से बचें—सटीक आउटपुट एक ठोस पैच सक्षम करता है।
मॉडल को तेज़ टाइपिंग करने वाला पार्टनर समझें, ऑटो-पायलट नहीं।
आप जिम्मेदार हैं:
एक अच्छी आदत है कि एक plain-language सार माँगा जाए: क्या बदला, क्या नहीं बदला, और क्यों।
डिफ़ॉल्ट तौर पर अलग रखें।
रिफैक्टर्स को व्यवहार परिवर्तन के साथ मिलाने से शोर बढ़ता है और इरादा सत्यापित करना कठिन हो जाता है।
संक्षिप्त और ठोस रखें:
अगर आपका PR “एक विचार, एक चेक द्वारा प्रमाणित” जैसा दिखता है, तो उसे तेज़ी से मर्ज किया जाता है।
Koder.ai वही अनुशासन कुछ सहायक फीचर्स के साथ सपोर्ट करता है:
इसे छोटे और reversible इटरेशन्स के लिए उपयोग करें, फिर अपने सामान्य रिव्यू प्रोसेस से मर्ज करें।
यह संरचना स्वाभाविक रूप से दायरा सीमित करती है और समीक्षा तेज़ बनाती है।