Superpowers वर्कफ़्लो Skill कैसे चुनें: आवश्यकताएँ, स्वीकृति और Skill लेखन

सबसे पहले अपेक्षित परिणाम के आधार पर चयन करें।

तीनों प्रविष्टियाँ obra/superpowers की हैं और एक ही रिपॉज़िटरी के Star दिखाती हैं। Star से इनके बीच चुनाव नहीं किया जा सकता; ट्रिगर शर्तें और परिणाम अधिक उपयोगी अंतर हैं।

हमारा दृष्टिकोण यह है कि सबसे पहले कार्य में मौजूद कमियों की पहचान की जाए: जब आवश्यकताओं में अभी भी महत्वपूर्ण अस्पष्टताएं हों, तो हमें उद्देश्य को स्पष्ट करना होगा; जब डिलीवरी की तैयारी कर रहे हों, तो हमें साक्ष्य को सत्यापित करना होगा; जब एजेंटों द्वारा पुन: उपयोग के लिए अनुभव को क्षमताओं में लिखने की तैयारी कर रहे हों, तो हमें यह जांचना होगा कि क्या निर्देश वास्तव में व्यवहार को बदलते हैं।

आवश्यकताएँ अभी अस्पष्ट हैं: brainstorming जाँचें

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

सबसे पहले जाँच करने का एक अच्छा संकेत यह है कि आप जिस उत्पाद को बनाना चाहते हैं उसका वर्णन तो कर सकते हैं, लेकिन अभी तक उसके उपयोगकर्ताओं, सफलता के मानदंडों या कार्यक्षेत्र को स्पष्ट नहीं कर सकते। एक संक्षिप्त समझ लॉग से शुरुआत करें, जिसमें प्रत्येक बिंदु को अपनी आवश्यकताओं और संभावित उम्मीदवारों से जुड़ी धारणाओं के आधार पर जांचें।

यदि कार्य में पहले से ही स्पष्ट इनपुट, आउटपुट और स्वीकृति मानदंड दिए गए हैं, तो देखें कि क्या यह मौजूदा जानकारी का उपयोग करता है और क्या नई चर्चाएँ वास्तविक अस्पष्टताओं को दूर करती हैं। "अधिक प्रश्न पूछना" को गुणवत्ता मानक के रूप में उपयोग न करें।

brainstorming: निश्चित commit की मूल फ़ाइल ↗

डिलीवरी से पहले: verification-before-completion जाँचें

मूल निर्देश में काम पूरा होने का दावा करने से पहले सत्यापन विधि चुनना, जाँच चलाना और पूरा आउटपुट पढ़ना आवश्यक है। यह डिलीवरी का निर्णय नियंत्रित करता है; किसी खास प्रोजेक्ट का टेस्ट टूल नहीं देता।

परीक्षण करते समय, सबसे पहले उन निष्कर्षों की सूची बनाएं जिन्हें आप सिद्ध करना चाहते हैं, फिर उनसे संबंधित जाँचें लिखें। उदाहरण के लिए, "आउटपुट CSV में चार निर्दिष्ट कॉलम हैं" की जाँच कॉलम नामों की जाँच करके की जा सकती है; "पूरे सिस्टम में कोई समस्या नहीं है" को आमतौर पर एक आंशिक जाँच से सिद्ध नहीं किया जा सकता है।

एक कोड जाँच सफल होना अपने आप कार्यक्षमता, डिप्लॉयमेंट और वास्तविक उपयोगकर्ता प्रक्रिया सही साबित नहीं करता। निष्कर्ष और प्रमाण का स्पष्ट संबंध चाहिए; जिन क्षेत्रों की जाँच नहीं हुई, उन्हें सीमाओं में दर्ज रखें।

verification-before-completion: निश्चित commit की मूल फ़ाइल ↗

अपनी Skill बनाए रखना: writing-skills जाँचें

मूल पाठ में कौशल निर्माण और संपादन, तथा प्रक्रिया विवरणों के सत्यापन को परिदृश्य परीक्षण से जोड़ने पर चर्चा की गई है, जिसमें विवरण के बिना व्यवहार का अवलोकन और संशोधन के बाद के परिवर्तनों का अवलोकन शामिल है। यहाँ मुख्य ध्यान पुनः प्रयोज्य एजेंट क्षमताओं पर है।

यह प्रक्रिया तब उपयोगी होती है जब एक ही प्रकार का कार्य बार-बार दोहराया जाता है और मौजूदा विनिर्देशों के बावजूद कुछ स्पष्ट विचलन उत्पन्न होते हैं। विशिष्ट विचलनों और स्वीकृति विधियों को पहले से लिखकर रखना, बड़ी संख्या में नियमों का विस्तार करने की तुलना में सत्यापन को आसान बनाता है।

परिदृश्य जाँच में समय और संचालन लागत बढ़ती है, और क्लाइंट के समर्थित निष्पादन तरीके अलग हो सकते हैं। एक बार के कार्य में पहले देखें कि नई Skill बनाए रखना वास्तव में आवश्यक है या नहीं। प्रारूप की वैधता और व्यवहार की प्रभावशीलता अलग-अलग जाँचें।

writing-skills: निश्चित commit की मूल फ़ाइल ↗

Agent Skills: आधिकारिक प्रारूप विनिर्देश ↗

उदाहरण परिदृश्य: इनपुट सत्यापन त्रुटि को ठीक करना

यह साइट के संपादकों द्वारा बनाया गया चयन उदाहरण है, तीनों Skill के उपयोग की रिपोर्ट नहीं। मान लें कि समस्या दोहराने वाला इनपुट, अपेक्षित त्रुटि संदेश और रिग्रेशन जाँच कमांड स्पष्ट हैं और अब तय दायरे का सुधार करना है।

इस स्थिति में डिलीवरी से पहले प्रमाण जाँचना सीधी आवश्यकता है। समस्या दोहराने की शर्त या गलत व्यवहार अस्पष्ट हो तो आवश्यकताएँ स्पष्ट करने की प्रक्रिया जोड़ें। यदि टीम समान सुधार में बार-बार कोई जाँच छोड़ती है और उसे पुनः उपयोग योग्य Skill के रूप में बनाए रखना चाहती है, तो Skill लिखने की प्रक्रिया पर विचार करें।

यह चयन चरणों और परिणामों के आधार पर किया जाता है, न कि प्रत्येक कार्य के लिए रिपॉजिटरी के भीतर सभी वर्कफ़्लो का एक साथ उपयोग करने के आधार पर। कई विकल्पों को मर्ज करते समय, उनके ट्रिगरिंग शर्तों, अनुमोदन चरणों और परिचालन क्षेत्रों में भी टकराव की जाँच की जानी चाहिए।

रिकॉर्ड तालिका से अपनी परिस्थिति में उपयुक्तता जाँचें

समान इनपुट और स्वीकृति मानदंडों से विकल्पों की तुलना करें तथा क्लाइंट, रिपॉज़िटरी कमिट और उपयोग किए गए फ़ाइल पथ को दर्ज करें। वास्तविक परीक्षण पूरा होने तक सार्वजनिक स्रोतों के निष्कर्षों का उपयोग केवल विकल्प चुनने के लिए करें।

CODEZ: सामान्य कौशल चयन मार्गदर्शिका ↗

CODEZ: वर्गीकरण समीक्षा आधार ↗