14 दिस॰ 2025·7 मिनट
Claude Code टास्क स्कोपिंग: अस्पष्ट अनुरोधों से कमिट्स तक
Claude Code टास्क स्कोपिंग सीखें ताकि अव्यवस्थित फीचर अनुरोधों को स्पष्ट स्वीकृति मानदंड, एक न्यूनतम UI/API योजना और कुछ छोटे कमिट्स में बदला जा सके।
Claude Code टास्क स्कोपिंग सीखें ताकि अव्यवस्थित फीचर अनुरोधों को स्पष्ट स्वीकृति मानदंड, एक न्यूनतम UI/API योजना और कुछ छोटे कमिट्स में बदला जा सके।
एक अस्पष्ट अनुरोध मासूम लग सकता है: “बेहतर सर्च जोड़ो”, “ऑनबोर्डिंग को सहज बनाओ”, “यूज़र्स को नोटिफिकेशन चाहिए।” वास्तविक टीमों में यह अक्सर एक-लाइन की चैट, तीरों के साथ एक स्क्रीनशॉट, या आधा-याद किया हुआ कस्टमर कॉल के रूप में आता है। हर कोई सहमत होता है, पर हर किसी के दिमाग में कुछ अलग होता है।
लागत बाद में दिखती है। जब स्कोप अस्पष्ट होता है, तो लोग अनुमान पर काम बनाते हैं। पहला डेमो एक और राउंड ऑफ़ क्लैरिफिकेशन बन जाता है: “यह वही नहीं था जो मैंने माना।” काम दोबारा किया जाता है, और बदलाव धीरे-धीरे बढ़ता चला जाता है। डिज़ाइन के छोटे बदलाव कोड परिवर्तन ट्रिगर करते हैं, जो और अधिक टेस्टिंग को बुलाते हैं। रिव्यू धीमे पड़ जाते हैं क्योंकि एक धुँधला परिवर्तन सत्यापित करना मुश्किल होता है। अगर कोई यह परिभाषित नहीं कर सकता कि “सही” क्या दिखता है, तो समीक्षक व्यवहार पर बहस करते हुए गुणवत्ता की जाँच करने के बजाय बहस में फँस जाते हैं।
आप आम तौर पर एक अस्पष्ट टास्क को जल्दी पहचान सकते हैं:
एक अच्छी तरह स्कोप्ड टास्क टीम को एक अंतिम लक्ष्य देता है: स्पष्ट स्वीकृति मानदंड, एक न्यूनतम UI और API योजना, और स्पष्ट सीमाएँ कि क्या शामिल नहीं है। यही फर्क है “सर्च सुधारें” और एक छोटे बदलाव के बीच जिसे बनाना और रिव्यू करना आसान हो।
एक व्यावहारिक आदत: “Definition of done” को “nice-to-have” से अलग रखें। “Done” उन अल्पसूची जाँचों की एक छोटी सूची है जिन्हें आप चला कर सत्यापित कर सकते हैं (उदा.: “Search शीर्षक द्वारा परिणाम लौटाए, खाली होने पर ‘No results’ दिखे, और क्वेरी URL में बनी रहे”)। “Nice-to-have” वे चीज़ें हैं जो बाद में हो सकती हैं (साइनोनिम्स, रैंकिंग ट्वीक, हाइलाइटिंग, analytics)। पहले से इन्हें लेबल करना आकस्मिक स्कोप वृद्धि को रोकता है।
अस्पष्ट अनुरोध अक्सर सुझाए गए फिक्स के रूप में आते हैं: “एक बटन जोड़ो”, “नया फ्लो बदलो”, “एक अलग मॉडल उपयोग करो।” रुकें और सुझाव को पहले एक परिणाम में अनुवादित करें।
एक सरल फॉर्मेट मदद करता है: “As a [user], I want to [do something], so I can [reach a goal].” इसे सादा रखें। अगर आप इसे एक साँस में नहीं कह सकते, तो यह अभी भी बहुत धुँधला है।
इसके बाद लिखें कि पूरा होने पर उपयोगकर्ता के लिए क्या बदलता है। दृश्य व्यवहार पर फोकस रखें, इम्प्लीमेंटेशन विवरण पर नहीं। उदाहरण: “फॉर्म सबमिट करने के बाद, मुझे एक कन्फर्मेशन दिखता है और मैं नई रिकॉर्ड को सूची में ढूँढ सकता हूँ।” यह एक स्पष्ट फिनिश लाइन बनाता है और “एक और छोटा ट्वीक” के बीच घुसपैठ को मुश्किल बनाता है।
यह भी लिखें कि क्या वही रहेगा। नॉन-गोल आपकी स्कोप की रक्षा करते हैं। अगर अनुरोध “ऑनबोर्डिंग सुधारें” है, तो एक नॉन-गोल हो सकता है “कोई डैशबोर्ड रीडिज़ाइन नहीं” या “कोई प्राइसिंग-टियर लॉजिक परिवर्तन नहीं।”
अंत में, पहले एक प्राथमिक पाथ चुनें: वेब-एंड-टू-एंड स्लाइस जो साबित करे कि फीचर काम करता है।
उदाहरण: “हर जगह snapshots जोड़ने” के बजाय लिखें: “As a project owner, I can restore the latest snapshot of my app, so I can undo a bad change.” नॉन-गोल: “कोई bulk restore नहीं, कोई UI redesign नहीं।”
एक अस्पष्ट अनुरोध अक्सर मेहनत की कमी नहीं, बल्कि निर्णयों की कमी होती है।
शुरू करें उन प्रतिबंधों से जो चुपके से स्कोप बदलते हैं। डेडलाइन मायने रखती है, पर साथ ही एक्सेस रूल्स और कंप्लायंस जरूरतें भी। अगर आप प्लेटफ़ॉर्म पर बना रहे हैं जिसमें टियर और रोल्स हैं, तो जल्दी तय करें किसे फीचर मिलेगा और किस प्लान पर।
फिर एक ठोस उदाहरण माँगें। एक स्क्रीनशॉट, प्रतियोगी का व्यवहार, या पिछला टिकट यह दिखा देता है कि “बेहतर” का आशय क्या है। अगर अनुरोधकर्ता के पास कुछ नहीं है, तो उनसे पूछें कि आख़िरी बार दर्द कब महसूस हुआ: वे किस स्क्रीन पर थे, क्या क्लिक किया और क्या उम्मीद थी?
एज केस वही जगह है जहाँ स्कोप बढ़ता है, इसलिए बड़े मामलों का जल्दी नाम लें: खाली डेटा, वैलिडेशन त्रुटियाँ, धीमा/फेल नेटवर्क कॉल, और “undo” का वास्तव में क्या मतलब है।
अंत में तय करें कि आप सफलता कैसे सत्यापित करेंगे। बिना टेस्टेबल परिणाम के, टास्क रायों में बदल जाता है।
ये पाँच सवाल अक्सर अधिकांश अस्पष्टता दूर कर देते हैं:
उदाहरण: “Add custom domains for clients” तब अधिक स्पष्ट हो जाता है जब आप तय कर लें कि यह किस टियर का है, कौन इसे सेट कर सकता है, होस्टिंग लोकेशन कंप्लायंस के लिए मायने रखता है या नहीं, invalid DNS पर कौन सी त्रुटि दिखेगी, और “done” का मतलब क्या है (डोमेन verified, HTTPS active, और सुरक्षित rollback योजना)।
गंदे अनुरोध लक्ष्य, अनुमान और आधा-याद एज केस मिलाते हैं। काम यह है कि उसे ऐसे कथनों में बदलना जो कोई भी आपकी दिमाग पढ़े बिना टेस्ट कर सके। वही मानदंड डिज़ाइन, कोडिंग, रिव्यू और QA को निर्देशित करने चाहिए।
एक सरल पैटर्न इसे साफ रखता है। आप Given/When/Then का प्रयोग कर सकते हैं, या छोटे बुलेट्स जो वही अर्थ रखते हैं।
प्रत्येक मानदंड को एक ऐसे टेस्ट के रूप में लिखें जिसे कोई चला सके:
अब इसे लागू करें। मान लीजिए नोट कहता है: “Snapshots को आसान बनाओ। मैं रोलबैक करना चाहता हूँ अगर आख़िरी बदलाव बिगाड़ दे।” इसे टेस्टेबल स्टेटमेंट्स में बदलें:
अगर QA इन चेक्स को चला सके और समीक्षक UI और लॉग्स में इन्हें सत्यापित कर सकें, तो आप UI और API कार्य की योजना बना कर उसे छोटे कमिट्स में विभाजित कर सकते हैं।
एक न्यूनतम UI प्लान एक वादा है: सबसे छोटा दृश्य परिवर्तन जो साबित करे कि फीचर काम करता है।
शुरू करें यह नामित करके कि कौन-कौन सी स्क्रीन बदलेगी और 10 सेकंड में उपयोगकर्ता क्या नोटिस करेगा। अगर अनुरोध कहता है “इसे आसान बनाओ” या “साफ़ करें”, तो उसे एक सुस्पष्ट परिवर्तन में बदलें जिसे आप इंगित कर सकें।
इसे एक छोटे नक्शे के रूप में लिखें, redesign के बजाय। उदाहरण: “Orders पृष्ठ: टेबल के ऊपर एक filter bar जोड़ें”, या “Settings: Notifications के अंतर्गत एक नया toggle जोड़ें।” यदि आप स्क्रीन और सटीक एलिमेंट का नाम नहीं बता सकते, तो स्कोप अभी भी अस्पष्ट है।
अधिकतर UI बदलावों को कुछ प्रत्याशित अवस्थाएँ चाहिए। केवल वही लिखें जो लागू हों:
UI कॉपी भी स्कोप का हिस्सा है। उन लेबल्स और संदेशों को कैप्चर करें जिन्हें अनुमोदित करना ज़रूरी है: बटन टेक्स्ट, फ़ील्ड लेबल, हेल्पर टेक्स्ट, और त्रुटि संदेश। अगर शब्दावली अभी खुली है, तो उसे placeholder के रूप में चिन्हित करें और नोट करें कि कौन पुष्टि करेगा।
जो भी उपयोग करने के लिए आवश्यक नहीं है (responsive polish, advanced sorting, animations, नए आइकन) उसे “not now” सूची में रखें।
एक स्कोप्ड टास्क के लिए UI, बैकएंड और डेटा के बीच एक छोटा, स्पष्ट कॉन्ट्रैक्ट चाहिए। लक्ष्य पूरा सिस्टम डिजाइन करना नहीं, बल्कि उन न्यूनतम रिक्वेस्ट्स और फ़ील्ड्स को परिभाषित करना है जो फीचर को साबित करें।
शुरू करें यह सूची बनाकर कि आपको कौन सा डेटा चाहिए और यह कहाँ से आता है: मौजूदा फ़ील्ड जो आप पढ़ सकते हैं, नए फ़ील्ड जिन्हें आपको सहेजना होगा, और मूल्य जो आप compute कर सकते हैं। अगर आप हर फ़ील्ड का स्रोत नहीं बता सकते, तो आपके पास अभी योजना नहीं है।
API सरफेस छोटा रखें। कई फीचरों के लिए एक read और एक write काफी होते हैं:
GET /items/{id} स्क्रीन render करने के लिए आवश्यक स्थिति लौटाता हैPOST /items/{id}/update केवल वही स्वीकार करता है जिसे उपयोगकर्ता बदल सकता है और अपडेटेड स्थिति लौटाता हैइनपुट और आउटपुट को साधारण ऑब्जेक्ट्स की तरह लिखें, न कि पैराग्राफ्स की तरह। आवश्यक बनाम वैकल्पिक फ़ील्ड शामिल करें, और सामान्य त्रुटियों पर क्या होता है (not found, validation failed)।
डेटाबेस छेड़ने से पहले एक त्वरित auth पास करें। तय करें कौन पढ़ सके और कौन लिख सके, और नियम एक वाक्य में लिखें (उदा.: “किसी भी साइन-इन उपयोगकर्ता पढ़ सकता है, केवल admins लिख सकते हैं”)। इसे छोड़ने से अक्सर रीवर्क होता है।
अंत में, तय करें क्या स्टोर करना है और क्या compute किया जा सकता है। एक सरल नियम: तथ्य स्टोर करें, व्यूज़ compute करें।
Claude Code सबसे अच्छा तब काम करता है जब आप उसे एक स्पष्ट लक्ष्य और एक तंग बॉक्स दें। गंदे अनुरोध और कोई भी प्रतिबंध (डेडलाइन, प्रभावित उपयोगकर्ता, डेटा नियम) पेस्ट करके शुरू करें। फिर स्कोप्ड आउटपुट माँगें जिसमें शामिल हो:
जवाब आने के बाद, उसे एक समीक्षक की तरह पढ़ें। अगर आप “improve performance” या “make it cleaner” जैसे वाक्य देखें, तो मापनीय शब्द माँगें।
Request: “Add a way to pause a subscription.”
एक स्कोप्ड वर्शन कह सकता है: “User 1 से 3 महीनों के लिए pause कर सकता है; अगला बिलिंग डेट अपडेट होता है; admin pause स्टेटस देख सकता है,” और out of scope: “कोई proration परिवर्तन नहीं।”
वहां से, कमिट प्लान व्यावहारिक बन जाता है: एक कमिट DB और API शपेश के लिए, एक UI कंट्रोल्स के लिए, एक वैलिडेशन और एरर स्टेट्स के लिए, और एक end-to-end टेस्ट के लिए।
बड़े बदलाव बग्स छिपाते हैं। छोटे कमिट्स रिव्यूज़ तेज बनाते हैं, रॉलबैक सुरक्षित करते हैं, और आपको नोटिस करने में मदद करते हैं जब आप स्वीकृति मानदंड से भटक रहे हों।
एक उपयोगी नियम: हर कमिट को एक नया व्यवहार अनलॉक करना चाहिए, और उसे प्रमाणित करने का एक त्वरित तरीका शामिल होना चाहिए।
एक सामान्य अनुक्रम ऐसा दिखता है:
हर कमिट को केंद्रित रखें। “While I’m here” रिफैक्टर्स से बचें। ऐप को end-to-end काम करते हुए रखें, भले UI बेसिक ही क्यों न हो। माईग्रेशन्स, व्यवहार और UI को एक ही कमिट में बैच में न रखें जब तक मजबूर वजह न हो।
एक स्टेकहोल्डर कहता है: “क्या हम Export reports जोड़ सकते हैं?” इसमें बहुत सी चुनौतियाँ छिपी होती हैं: कौन सा रिपोर्ट, कौनसा फ़ॉर्मेट, कौन एक्सपोर्ट कर सकता है, और डिलीवरी कैसे होगी।
सिर्फ़ उन सवालों को पूछें जो डिजाइन बदलते हैं:
मान लीजिए उत्तर हैं: “Sales Summary report, केवल CSV, manager role, डायरेक्ट डाउनलोड, पिछले 90 दिनों तक मैक्स।” अब v1 स्वीकृति मानदंड ठोस बन जाते हैं: मैनेजर्स Sales Summary पेज पर Export पर क्लिक कर सकते हैं; CSV ऑन-स्क्रीन टेबल कॉलम से मेल खाता है; एक्सपोर्ट करंट फ़िल्टर्स का पालन करता है; 90 दिनों से अधिक पर एक स्पष्ट त्रुटि दिखती है; 50k रो तक 30 सेकंड में डाउनलोड पूरा होता है।
न्यूनतम UI प्लान: टेबल एक्शंस के पास एक Export बटन, जेनरेट करते समय एक लोडिंग स्टेट, और एक त्रुटि संदेश जो उपयोगकर्ता को सुधार का तरीका बताये (जैसे “90 दिन या कम चुनें”)।
न्यूनतम API प्लान: एक endpoint जो फिल्टर्स लेता है और जनरेट किया गया CSV फ़ाइल रिस्पॉन्स के रूप में लौटाता है, टेबल जैसी ही क्वेरी को पुन: उपयोग करते हुए और 90-दिन नियम सर्वर-साइड लागू करते हुए।
फिर इसे कुछ तंग कमिट्स में भेजें: पहले फिक्स्ड हैप्पी-पाथ के लिए endpoint, फिर UI वायरिंग, फिर वैलिडेशन और यूज़र-फेसिंग त्रुटियाँ, फिर टेस्ट और डॉक्यूमेंटेशन।
“add team roles” जैसे अनुरोध अक्सर इंसान जोड़ने, संपादित करने, और मौजूदा उपयोगकर्ताओं के साथ क्या होता है, के नियम छिपाते हैं। अगर आप अनुमान लगा रहे हैं, तो वह मान्यता लिख दें और उसे सवाल या स्पष्ट नियम में बदल दें।
जब एक ही टास्क में “काम कराओ” और “खूबसूरत बनाओ” दोनों शामिल होते हैं, टीम दिन गँवा देती है। पहला टास्क व्यवहार और डेटा पर केन्द्रित रखें। स्टाइलिंग, एनिमेशन और स्पेसिंग को फ़ॉलो-अप टास्क में रखें जब तक वे उपयोग के लिए ज़रूरी न हों।
एज केस महत्वपूर्ण हैं, पर सभी को तुरंत हल करने की जरूरत नहीं। वे जिन्हें भरोसा तोड़ने का खतरा हो (double submits, conflicting edits) उन्हीं को संभालें और बाकी को स्पष्ट नोट्स के साथ टाल दें।
अगर आप उन्हें लिखते नहीं हैं, तो आप उन्हें भूल जाएंगे। अपने स्वीकृति मानदंड में कम से कम एक unhappy path और एक permission नियम शामिल करें।
“Fast” या “intuitive” जैसे शब्दों से बचें जब तक आप उन पर संख्या या ठोस चेक न जोड़ें। उन्हें ऐसे शब्दों से बदलें जिन्हें आप रिव्यू में प्रमाणित कर सकें।
टास्क को पिन करें ताकि एक साथी बिना माइंड-रीडिंग के रिव्यू और टेस्ट कर सके:
उदाहरण: “Add saved searches” बन जाता है “Users एक फ़िल्टर सेव कर सकते हैं और बाद में उसे फिर से लागू कर सकते हैं,” नॉन-गोल्स जैसे “कोई sharing नहीं” और “कोई sorting परिवर्तन नहीं।”
एक बार जब आपके पास स्कोप्ड टास्क हो, तो इसे संरक्षित करें। कोडिंग से पहले, उनसे एक त्वरित सैनीटी रिव्यू कराएं जिनसे आपने परिवर्तन माँगा था:
फिर मानदंड को उस जगह स्टोर करें जहाँ काम हो रहा है: टिकट में, PR विवरण में, और जहाँ आपकी टीम वास्तव में देखती है वहाँ।
अगर आप Koder.ai (koder.ai) में बना रहे हैं, तो पहले योजना लॉक करना मददगार होता है और फिर उससे कोड जनरेट करें। Planning Mode इस वर्कफ़्लो के लिए उपयुक्त है, और snapshots और rollback प्रयोगों को सुरक्षित रख सकते हैं जब आपको किसी तरीके को आज़माना और वापस लेना पड़े।
जब निर्माण के दौरान नए आइडियाज़ आते हैं, तो स्कोप को स्थिर रखें: उन्हें फ़ॉलो-अप सूची में लिखें, यदि वे स्वीकृति मानदंड बदलते हैं तो रि-स्कोप के लिए रुकें, और कमिट्स को एक-एक मानदंड से बाँधे रखें।
एक वाक्य में परिणाम लिखकर शुरू करें (जब यह पूरा हो, उपयोगकर्ता क्या कर पाएगा), फिर 3–7 स्वीकृति मानदंड जोड़ें जिन्हें परीक्षणकर्ता सत्यापित कर सके।
यदि आप बिना बहस किए “सही” व्यवहार का वर्णन नहीं कर पा रहे हैं, तो कार्य अभी भी अस्पष्ट है।
तेज़ तरीका यह है:
फिर अपेक्षित व्यवहार का एक ठोस उदाहरण जोड़ें। अगर आप उदाहरण नहीं दे सकते, तो आख़िरी बार जब समस्या आई थी उसे दोहराएँ: उपयोगकर्ता किस स्क्रीन पर था, किसपर क्लिक किया और क्या उम्मीद थी।
पहले एक छोटा "Definition of done" लिखें (वे चेक जो पास होने चाहिए), फिर अलग से "Nice-to-have" सूची बनाएं。
डिफ़ॉल्ट नियम: अगर वह फीचर end-to-end काम साबित करने के लिए ज़रूरी नहीं है, तो वह nice-to-have में रखा जाए।
उन कुछ सवालों को पूछें जो स्कोप बदलते हैं:
ये निर्णय अक्सर छिपी-अनिश्चितताओं को बाहर ला देते हैं।
इन्हें व1 में स्कोप आइटम की तरह संभालें, न कि आश्चर्यजनक मामलों के तौर पर। v1 में वे कवरेज दें जो भरोसा तोड़ सकते हैं:
बाकी चीज़ें स्पष्ट रूप से out-of-scope के रूप में टाल दी जा सकती हैं।
किसी भी व्यक्ति द्वारा चलाए जा सकने वाले टेस्टेबल स्टेटमेंट्स का उपयोग करें:
कम से कम एक फ़ेलियर केस और एक अनुमति नियम शामिल करें। अगर कोई क्राइटेरियन टेस्ट नहीं किया जा सकता, तो उसे तब तक पुनर्लिखें जब तक वह टेस्टेबल न हो।
सटीक स्क्रीन और प्रति स्क्रीन एक ही दृश्य परिवर्तन नामित करें।
साथ ही आवश्यक UI अवस्थाएँ लिखें:
कॉपी (बटन टेक्स्ट, त्रुटियाँ) को भी स्कोप में रखें, भले वह placeholder ही क्यों न हो।
कॉन्ट्रैक्ट छोटा रखें: v1 के लिए अक्सर एक read और एक write पर्याप्त होते हैं।
परिभाषित करें:
फैक्ट्स को स्टोर करें; व्यूज़ को संभव हो तो कंप्यूट करें।
एक बॉक्स्ड डिलिवरेबल माँगें:
फिर किसी भी अस्पष्ट शब्दों जैसे “make it cleaner” को मापनीय शब्दों में बदलने के लिए पुनःप्रॉम्प्ट करें।
डिफ़ॉल्ट अनुक्रम:
नियम: एक कमिट = एक नया उपयोगकर्ता-दृश्य व्यवहार + उसे साबित करने का त्वरित तरीका। “While I’m here” रिफैक्टर्स फीचर कमिट्स में न जोड़ें।