तुमच्या नियंत्रणातील Git रिपॉझिटरीमध्ये मोठा बदल करताना Superpowers, Claude Code वापरकर्त्याला मार्गदर्शन करू शकते: रचनेवर सहमती, कामांच्या योजनेला मंजुरी, चाचण्यांसह अंमलबजावणी, प्रत्येक कामाचे पुनरावलोकन आणि पूर्ण झालेली शाखा तपासणे. हा मार्गदर्शक 20 ऑक्टोबर 2026 रोजी तपासलेल्या अधिकृत Superpowers 7.0.0 पुस्तिकांवर आधारित आहे. BIG CHANGE ने दस्तऐवज वाचले; आम्ही प्लगइन बसवले नाही किंवा त्यातून प्रकल्प चालवला नाही.

मोठा बदल

  • काय बदलले: मंजूर रचना आणि अंमलबजावणी योजना कोडिंग एजंटना रिपॉझिटरी बदलण्याआधी ठरावीक काम व मर्यादा देतात.
  • हे महत्त्वाचे का: दस्तऐवजातील कामाच्या प्रवाहात प्रत्यक्ष दिसलेल्या अपयशी व यशस्वी चाचण्यांना एका परीक्षकाचे तपशीलवार अपेक्षा आणि गुणवत्तेबाबत स्वतंत्र निर्णय जोडले जातात; त्यानंतर संपूर्ण शाखेचे व्यापक पुनरावलोकन होते.
  • कशाकडे लक्ष द्यावे: मालक अजूनही संपूर्ण diff आणि ताजे स्वीकृती निकाल तपासतो आणि शाखेचे पुढे काय करायचे ठरवतो. एजंटचा कामाचा प्रवाह पूर्ण झाला तरी जाहीर केलेले निष्कर्ष बाकी राहू शकतात.

सुरुवात करण्यापूर्वी

तुमच्या मालकीच्या किंवा बदलण्याची परवानगी असलेल्या रिपॉझिटरीत एक अधिकृत, अनेक टप्प्यांचा कोड बदल निवडा. त्याचे पुनरावलोकन करता येणाऱ्या कामांत विभाजन आणि वर्तनाची चाचणी शक्य असावी. अपेक्षित वर्तन, परिणाम होणारा भाग, वगळलेली कामे, मूळ स्वीकृती आदेश आणि सुरुवातीचा commit लिहा. कामाआधी तो आदेश व संबंधित विद्यमान तपासण्या चालवा. सुरुवातीलाच चाचणी अयशस्वी होत असेल तर ते अपयश आत्ताच ओळखा; नंतरचा हिरवा किंवा लाल निकाल समजण्यासाठी ज्ञात सुरुवातीची स्थिती हवी.

तुमच्याकडे Git, प्रमाणीकरण केलेली Claude Code स्थापना, प्लगइन बसवण्याची व branch किंवा worktree बनवण्याची परवानगी आणि Claude Code व त्याच्या उप-एजंटसाठी पुरेशी प्लॅन किंवा API क्षमता हवी. स्रोत कोड प्रवेश आणि प्लगइन वापराबाबत संस्थेचे नियम तपासा. सक्रिय करण्याआधी प्लगइनची सामग्री, प्रत्यक्ष परवानग्या, पुरवठादाराच्या डेटा अटी आणि खर्च नियंत्रण पाहा. Anthropic चेतावणी देते की प्लगइन hooks आणि server processes, tool-call sandbox बाहेर तुमच्या वापरकर्ता अधिकारांनी चालू शकतात; नेहमीच्या tool permission prompts मध्ये असा सगळा कोड समाविष्ट नसतो. गुपिते, dependencies, बाहेरील writes, pushes आणि releases तुमच्या प्रत्यक्ष अधिकारांत ठेवा. Claude Code चे प्लगइन सुरक्षा दस्तऐवज ही सीमा स्पष्ट करतात.

खालील मार्ग अनेक कामांच्या बदलासाठी Superpowers चे subagent-driven-development कौशल्य वापरतो. पुस्तिकांमध्ये inline executing-plans मार्गही आहे आणि लहान कामासाठी साध्या रचना-सहमतीला परवानगी आहे. प्रत्येक प्रकल्पाला संपूर्ण क्रम लागेल असे गृहीत न धरता अंमलबजावणीपूर्वी मालकाबरोबर मार्ग निवडा.

1. प्लगइन बसवा आणि सक्रिय आवृत्ती तपासा

परस्परसंवादी Claude Code सत्रात अधिकृत marketplace आदेश टाका:

Text
/plugin install superpowers@claude-plugins-official

स्थापनेपूर्वी Claude Code प्लगइन तपशील पटल उघडते. सामग्री तपासा व परवानगी असलेला scope निवडा. Local scope या रिपॉझिटरीत तुमच्यासाठी ते सक्रिय करतो; project scope सहकाऱ्यांच्या रिपॉझिटरी सेटिंग्जवर परिणाम करतो. स्थापना सारांश आणि Errors टॅब वाचा. सत्रातील सक्रिय करण्याच्या सूचना पाळा किंवा पुन्हा सुरू करा; नंतर Installed टॅब पाहा आणि shell मध्ये claude plugin list चालवा. दिसणारे Version, Scope आणि Status नोंदवा आणि सक्रिय सत्रात Superpowers कौशल्ये उपलब्ध असल्याची खात्री करा. marketplace आदेश या मार्गदर्शकाच्या संशोधनातील commit निश्चित करत नाही. स्थापित आवृत्ती किंवा कौशल्याचा मजकूर 7.0.0 पेक्षा वेगळा असेल तर पुढे जाण्याआधी त्या आवृत्तीनुसार प्रक्रिया तपासा. अयशस्वी किंवा निष्क्रिय स्थापनेवर थांबा; कार्यप्रवाह लोड झाल्याचा तो पुरावा नाही. Claude Code चा स्थापना मार्गदर्शक या तपासण्या सांगतो.

2. आधी रचना, मग योजना मंजूर करा

Claude Code ला खरा बदल, स्वीकृती निकष, सुरुवातीचा निकाल आणि निषिद्ध संपादने सांगा. हेतू, रचनेचे पर्याय व मर्यादा ठरवण्यासाठी Superpowers ची brainstorming प्रक्रिया वापरा. या अनेक टप्प्यांच्या बदलासाठी लिखित रचना आणि builder-check निष्कर्ष पाहा, मालकाच्या निर्णयाचे प्रश्न सोडवा आणि संपूर्ण वर्णन मंजूर करा. काय वर्तन बनवायचे ते मंजुरीत स्पष्ट असावे; एजंट बोलत राहतो म्हणून मंजुरी मिळाली असे समजू नये. रचना पुस्तिका लहान कामासाठी हलकी सहमती किंवा स्पष्ट opt-out मान्य करते, त्यामुळे मोठ्या कामासाठी हा पूर्ण मार्ग जाणीवपूर्वक निवडला आहे.

त्यानंतर writing-plans प्रक्रियेला त्या रचनेचे कामांत रूपांतर करायला सांगा. योजनेतील फाइल मर्यादा, interfaces, एकूण बंधने, चाचणी आदेश व Review Focus तपासा. प्रत्येक काम तपासण्याइतके लहान असावे आणि त्याची चाचणी ठरलेले वर्तन मोजणारी असावी. कोड बदलाआधी योजना आणि उप-एजंटच्या अंमलबजावणी पद्धतीला मंजुरी द्या. नियोजन पुस्तिका हस्तांतरण ठरवते. योग्य दिसणाऱ्या योजनेला dependencies वाढवण्याची किंवा असंबंधित फाइल बदलण्याची परवानगी मानू नका.

अंमलबजावणीच्या वेळी using-git-worktrees योग्य विद्यमान workspace तपासते किंवा आवश्यक संमतीने स्वतंत्र workspace बनवते. खरा branch, base commit आणि स्वच्छ मूळ स्थिती नोंदवा. उपलब्ध असल्यास Claude Code चे मूळ worktree समर्थन वापरा. workspace मध्ये असंबंधित संपादने असल्यास पुढे जाण्याआधी त्यांची मालकी स्पष्ट करा. worktree पुस्तिका तपासणी आणि निर्मितीचा मार्ग सांगते.

3. प्रत्येक चाचणी आणि कामाचे पुनरावलोकन पाहा

मंजूर योजनेसह subagent-driven-development स्वतंत्रपणे तपासता येणाऱ्या कामांसाठी वापरा. सध्याची पुस्तिका एका कामाला अंमलबजावणी करणारा देते, नंतर अंमलबजावणी व तिचा diff एका काम-परीक्षकाकडे पाठवते. तो दोन निर्णय देतो: काम ठरलेल्या अपेक्षांशी जुळते का आणि अंमलबजावणीची गुणवत्ता स्वीकारण्याजोगी आहे का. हे एका पुनरावलोकनातील दोन निर्णय आहेत, अनुक्रमे काम करणारे दोन परीक्षक एजंट नाहीत. एकाच प्रकारची लहान कामे पुस्तिकेच्या नियमांनुसार गटात करता येतात. कामाचा प्रवाह आणि परीक्षकाच्या सूचना हा क्रम ठरवतात.

आधी चाचणी लिहिणे योग्य असलेल्या प्रत्येक वर्तनासाठी प्रत्यक्ष दिसणारे red-green चक्र मागा: वर्तनाची चाचणी जोडा, चालवा आणि अपेक्षित अपयश पाहा; किमान अंमलबजावणी करा, पुन्हा चालवून यश पाहा; मग तपासण्या यशस्वी ठेवून refactor करा. import error किंवा बिघडलेला test harness हा अपेक्षित red निकाल नाही. प्रत्येक कामाचा आदेश, output आणि संबंधित commit किंवा diff ठेवा. test-driven-development पुस्तिका मानवी सहमती लागणारे अपवाद सांगते; हा मार्गदर्शक नेहमीच्या test-first मार्गाला योग्य काम गृहीत धरतो.

परीक्षकाचे दोन्ही निर्णय आणि खरा diff वाचा. काम स्वीकारण्याआधी “diff वरून तपासता येत नाही” असा प्रत्येक मुद्दा योजना आणि रिपॉझिटरी पाहून सोडवा. दुरुस्त्या व त्यांचे मर्यादित पुनरावलोकन तपासा; यशाचा नवा दावा ताज्या चाचणीचा निकाल नाही. 7.0.0 कार्यप्रवाहात दुरुस्ती चक्राला मर्यादा आहे आणि लिखित निर्णय देऊन निष्कर्ष पुढे ठेवता येतात. ते नंतरच्या पुनरावलोकनासाठी जतन करा. काम complete दिसले तरी त्याचे पुनरावलोकन समस्यामुक्त असेलच असे नाही.

कामे संपल्यावर संपूर्ण शाखेचे स्वतंत्र पुनरावलोकन तपासा. ते कामांमधील परस्पर परिणाम आणि एका diff वरून काम-परीक्षकाला न सोडवता आलेले पुढे ठेवलेले निष्कर्ष पाहू शकते. उघड्या मुद्द्यामागचा पुरावा व निर्णय मागा. प्लगइनचा तात्पुरता workspace साफ करण्यापूर्वी रचना, योजना, चाचणी output, पुनरावलोकन अहवाल आणि पूर्ण diff ठेवा. अपेक्षित कौशल्य सुरू न झाल्यास सक्रिय प्लगइनचा status व version आणि दस्तऐवजांतील निदान मार्ग तपासा; प्लगइन बसले म्हणून प्रवाह सक्तीने लागू झाला असे समजू नका.

4. शाखा तपासा आणि तिचे पुढे काय करायचे ठरवा

अंतिम कोडवर मूळ स्वीकृती आदेश आणि प्रकल्पाचा संपूर्ण test suite पुन्हा चालवा. ताजे output, पूर्ण branch चा diff आणि उरलेले सर्व निष्कर्ष तपासा. Superpowers ची पडताळणी पुस्तिका काम पूर्ण झाल्याच्या दाव्याआधी सध्याच्या स्थितीचा पुरावा मागते. suite अपयशी ठरल्यास नेमके अपयश शोधून दुरुस्त करा किंवा branch पुनरावलोकनासाठी ठेवा; अयशस्वी suite वर दस्तऐवजातला branch-finish menu येत नाही.

नाव असलेल्या branch वर finishing-a-development-branch local merge, push करून pull request बनवणे किंवा branch तशीच ठेवणे हे पर्याय देते. detached HEAD मध्ये pull-request आणि keep पर्याय असतात. Discard फक्त मालकाची स्पष्ट विनंती आणि टाइप केलेल्या पुष्टीनंतर होते; तो नेहमीचा चौथा पर्याय नाही. शाखा पूर्ण करण्याची पुस्तिका हे पर्याय सांगते. निर्णयाआधी मालकाला तपासण्या, diff आणि उरलेले निष्कर्ष दाखवा. merge, push, deletion किंवा release साठी त्या कृतीचे योग्य अधिकार लागतात.

उपयोगी परिणाम म्हणजे मूळ गरजेशी जोडलेली पुनरावलोकनयोग्य branch: मंजूर रचना व योजना, प्रत्यक्ष दिसलेले चाचणी निकाल, कामाच्या पुनरावलोकनाचे दोन्ही निर्णय, संपूर्ण branch चे पुनरावलोकन, पूर्ण diff आणि नवा स्वीकृती निकाल. स्थापना, प्रवेश, बजेट किंवा तपासणीमुळे काम थांबले तर पडताळलेली सामग्री ठेवा आणि शेवटचा पूर्ण टप्पा सांगा. दस्तऐवज प्रक्रिया सांगतात; या मार्गदर्शकात न चालवलेल्या बदलाला कमी वेळ, कमी खर्च किंवा कमी दोष होते हे ते सिद्ध करत नाहीत.

स्रोत आणि पुढील वाचन

एका मान्य तपासणीपुरत्या मर्यादित दुरुस्तीसाठी BIG CHANGE चा रिपॉझिटरीतील एक अयशस्वी तपासणी पडताळण्याचा मार्गदर्शक पाहा. इथली प्रक्रिया आधी सुरू होते, अनेक कामांच्या बदलाची रचना आणि योजना यांपासून.