तुलना
Deep Work Plan और विकल्प
अपनी स्थिति के लिए सही परत चुनें। हर विकल्प उसके अपने शब्दों में वर्णित है, हर तथ्य उसके आधिकारिक दस्तावेज़ तक जाता है, और पृष्ठ बताता है कि उसकी समीक्षा अंतिम बार कब हुई। यह एक नक्शा है, कोई क्रम नहीं।
इस पृष्ठ को कैसे पढ़ें
तीन मान हर क्षमता का वर्णन करते हैं। वे बताते हैं कि कोई क्षमता उपकरण में कहाँ रहती है, न कि उपकरण कितना अच्छा है।
- अंतर्निहित
- वैकल्पिक या एक्सटेंशन के माध्यम से
- दायरे से बाहर
अंतिम समीक्षा:
विकल्प, उनके अपने शब्दों में
स्पेक-ड्रिवन डेवलपमेंट उपकरण
-
स्पेक-ड्रिवन डेवलपमेंट उपकरण
GitHub Spec Kit
एक संविधान, एक विनिर्देश, एक योजना और एक कार्य-सूची के माध्यम से किसी फ़ीचर को निष्पादन योग्य विनिर्देश में बदलता है, उन slash कमांड्स से संचालित जो पचास से अधिक कोडिंग एजेंटों से जुड़ती हैं, और यह लागू करने से पहले जाँच सकता है कि सभी आर्टिफ़ैक्ट्स आपस में सुसंगत हैं।
वे टीमें जो अपने मौजूदा एजेंट के भीतर एक दोहराने योग्य specify, plan, tasks और implement वर्कफ़्लो चाहती हैं।
-
स्पेक-ड्रिवन डेवलपमेंट उपकरण
OpenSpec
हर बदलाव को डेल्टा स्पेक्स (added, modified, removed) और परिदृश्यों सहित RFC 2119 आवश्यकताओं वाले एक प्रस्ताव के रूप में पकड़ता है, फिर उन्हें जीवंत विनिर्देशों में संग्रहित करता है, साथ ही एक वैलिडेटर के साथ जो बदलाव स्वीकार करने से पहले प्रस्ताव की पूर्णता और परिदृश्य कवरेज जाँचता है।
मौजूदा सिस्टम पर काम करती वे टीमें जो चाहती हैं कि विनिर्देश एक-एक बदलाव के साथ बढ़ें।
-
स्पेक-ड्रिवन डेवलपमेंट उपकरण
Amazon Kiro
एक एजेंटिक IDE और CLI जिसके विनिर्देश EARS-शैली आवश्यकताओं से डिज़ाइन तक और फिर कार्यों तक बढ़ते हैं, साथ में स्टीयरिंग फ़ाइलें और वे hooks जो एडिटर इवेंट पर चलते हैं, और यह डिज़ाइन शुरू होने से पहले आवश्यकता संबंधी कमियाँ पकड़ने के लिए मौजूदा कोडबेस के लिए विनिर्देश बना सकता है।
वे डेवलपर्स जो AWS-समर्थित टूलिंग के साथ अपने एडिटर में बना स्पेक-ड्रिवन डेवलपमेंट चाहते हैं।
एजेंट वर्कफ़्लो फ़्रेमवर्क
-
एजेंट वर्कफ़्लो फ़्रेमवर्क
BMAD Method
विशेषज्ञ एजेंट भूमिकाओं (analysis, product, architecture, development, quality) का एक एजाइल फ़्रेमवर्क जो ब्रीफ़, आवश्यकताएँ, आर्किटेक्चर दस्तावेज़ और स्टोरी फ़ाइलें उत्पन्न करता है, साथ ही एक Definition of Done जिसमें हर स्टोरी को पूर्ण मानने से पहले किसी टीम-साथी या AI पीयर-रिव्यूअर द्वारा समीक्षित होना आवश्यक है।
वे टीमें जिन्हें भूमिका-आधारित औपचारिकताएँ पसंद हैं और एजेंट कार्य के लिए पूर्ण एजाइल जीवनचक्र चाहिए।
-
एजेंट वर्कफ़्लो फ़्रेमवर्क
Superpowers
स्किल्स की एक लाइब्रेरी और वर्कफ़्लो — ब्रेनस्टॉर्मिंग, छोटे टेस्ट-पहले चरणों में योजना बनाने, सब-एजेंटों से निष्पादन और पूर्णता से पहले समीक्षा के लिए, यहाँ की किसी भी अन्य विकल्प से अधिक कोडिंग-एजेंट होस्ट्स के साथ एकीकृत, साथ ही हर कार्य पर एक दो-चरणीय सब-एजेंट समीक्षा (पहले विनिर्देश-अनुपालन, फिर कोड गुणवत्ता)।
वे डेवलपर्स जो अपने कोडिंग एजेंट के भीतर अनुशासित टेस्ट-संचालित निष्पादन चाहते हैं।
-
एजेंट वर्कफ़्लो फ़्रेमवर्क
GSD Core
एक प्लानिंग सिस्टम — .planning डायरेक्टरी, आवश्यकता ids, चरण योजनाएँ, फ़्रेश-कॉन्टेक्स्ट निष्पादन और हर योजना से निकाले गए उपयोगकर्ता-अवलोकनीय डिलिवरेबल्स के विरुद्ध एक सत्यापन पास के साथ — जिसे कॉन्टेक्स्ट-रॉट से बचने के लिए बनाया गया है: रिसर्च, प्लानिंग और निष्पादन को डिस्पोज़ेबल सब-एजेंटों में चलाकर और कंटेंट-फ़िंगरप्रिंट जाँच से पुराने हो चुके सत्यापन को पकड़कर।
सोलो डेवलपर्स और छोटी टीमें जो कम औपचारिकता में कॉन्टेक्स्ट इंजीनियरिंग और सत्यापन चाहते हैं।
-
एजेंट वर्कफ़्लो फ़्रेमवर्क
Gentle-AI
उन कोडिंग एजेंटों को कॉन्फ़िगर करता है जिन्हें आप पहले से उपयोग करते हैं — सत्रों और मॉडलों के बीच रूटिंग करने वाली पर्सिस्टेंट मेमोरी, चुनी हुई स्किल्स, MCP सर्वर, पर्सोना और वैकल्पिक Spec-Driven Development या Receipt-Driven Development के साथ। इसका कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से आपकी ग्लोबल एजेंट सेटिंग्स में लिखा जाता है; वर्कस्पेस-स्कोप्ड इंस्टॉल वैकल्पिक है।
वे डेवलपर्स जो एक ऐसा कॉन्फ़िगर्ड एजेंट इकोसिस्टम चाहते हैं जो सत्रों में काम याद रखे और माँगे जाने पर साक्ष्य प्रस्तुत कर सके।
AI-native SDLC
-
AI-native SDLC
Claude's AI-native SDLC
Plan और Design से लेकर Build, Test, Deploy और Maintain तक का छह-चरणीय लूप, जिसमें हर चरण पर मानव अनुमोदन आवश्यक है, चरणों के बीच रिपॉज़िटरी में कमिट किए गए स्थायी आर्टिफ़ैक्ट हैं, डिप्लॉय से पहले एक समर्पित सिक्योरिटी-टैग की गई समीक्षा है, और सतत evals हैं जो अग्रणी व अनुगामी डिलीवरी संकेतक प्रकाशित करते हैं।
वे टीमें जो Claude Code के एंड-टू-एंड सॉफ़्टवेयर डिलीवरी प्लेबुक और उसके प्रोडक्शन फ़ीडबैक लूप का मूल्यांकन कर रही हैं।
वेंडर-नेटिव प्लान मोड
-
वेंडर-नेटिव प्लान मोड
वेंडर-नेटिव प्लान मोड
Claude Code, Codex, Cursor और Gemini CLI प्लान मोड, निर्देश फ़ाइलें और ऐसी स्किल्स शिप करते हैं जो खुले, वेंडर-निरपेक्ष AGENTS.md और Agent Skills मानकों पर आधारित हैं, हालाँकि सटीक प्लान-मोड व्यवहार अब भी वेंडर, क्लाइंट और वर्शन पर निर्भर करता है। विशेष रूप से Agent Skills शुरुआत में केवल एक संक्षिप्त सारांश लोड करती हैं और पूरे निर्देश सक्रियण पर लोड होते हैं, जिससे अप्रयुक्त क्षमता कॉन्टेक्स्ट से बाहर रहती है।
वे सभी जो बिना कोई पद्धति अपनाए किसी एक एजेंट के भीतर योजना बनाना चाहते हैं।
Deep Work Plan क्या लाता है
-
टूल-निरपेक्ष और रिपॉज़िटरी-नेटिव
हार्नेस और योजना आपकी रिपॉज़िटरी में फ़ाइलें हैं, जिन्हें AGENTS.md और Agent Skills मानकों का पालन करने वाला कोई भी एजेंट पढ़ता है। एजेंट बदलने पर योजना नहीं खोती।
-
हर कार्य ने जो छुआ उसमें से चुना गया सत्यापन
हर कार्य अपनी छुई सतह घोषित करता है और बदले गए व्यवहार तथा उसके उपभोक्ताओं की जाँचें चलाता है, और जब प्रभाव सीमाबद्ध न किया जा सके तो पूरे सूट तक विस्तारित करता है। शून्य चुनी गई जाँचें कभी पास नहीं हैं।
-
सुरक्षा-जाँच के साथ एक Final Review
योजना संचित बदलाव-समुच्चय की सुरक्षा समीक्षा — जिसमें diff की अनिवार्य स्थानीय समीक्षा शामिल है — और अंतिम स्थिति के सत्यापन के साथ बंद होती है। गंभीर निष्कर्ष पूर्णता को अवरुद्ध करते हैं।
-
सत्रों और एजेंटों से बच निकलने वाली स्थिति
README चेकबॉक्सेस, कार्य लॉग, एक सीमाबद्ध कार्यशील इंडेक्स और एक मशीन-पठनीय state फ़ाइल हर सीमा पर लिखी जाती हैं, इसलिए कोई दूसरा सत्र या एजेंट डिस्क से जारी रखता है। बाधित योजना-निर्माण भी पुनर्प्राप्त योग्य है।
-
रिपॉज़िटरी के लिए स्वयं एक अनुरूपता परीक्षक
एक रीड-ओनली स्क्रिप्ट हार्नेस और हर योजना को विनिर्देश के विरुद्ध सत्यापित करती है, दोनों योजना जीवनचक्र समझती है और CI-अनुकूल कोड के साथ बाहर निकलती है।
-
इंस्ट्रक्शन लोड मापा और प्रकाशित
एक कमिट स्क्रिप्ट हर flow के लिए दो माप प्रकाशित करती है — सत्र की शुरुआत में लोड होने वाला प्रवेश बंडल, और flow के वास्तविक ट्रिगर सक्रिय होने पर एंड-टू-एंड पाथ — साथ ही हर माप क्या शामिल नहीं करता, ताकि प्रवेश आँकड़ा अकेले कभी किसी रन की कुल लागत के रूप में न पढ़ा जाए। परिणाम — वृद्धियों सहित — bytes के रूप में प्रकाशित होते हैं, कभी टोकन या लागत प्रतिशत के रूप में नहीं।
ईमानदार सीमाएँ
Deep Work Plan में जीवंत या डेल्टा विनिर्देश तंत्र नहीं है; OpenSpec और ऐसे उपकरण वहाँ मज़बूत हैं। पद्धति का कोई स्वतंत्र बेंचमार्क अभी तक मौजूद नहीं है; पहले पक्ष की ओर से नए एजेंटों के साथ एक मूल्यांकन जमी हुई प्रोटोकॉल के तहत चल चुका है — छोटे पैमाने पर: एक कार्यभार, प्रति कॉन्फ़िगरेशन दो फ़ीचर, एक मशीन — और उसके परिणाम दोनों दिशाओं में प्रकाशित हैं: harness वाले ट्री पर एजेंट दोनों कार्यों में कम बाइट्स पढ़ते थे और वर्तमान संस्करण के सत्र पिछले मेजर संस्करण से कम, harness-रिपोर्टेड मॉडल इनपुट और आउटपुट खर्च करते थे, जबकि प्रति कार्यभार शुद्ध टोकन दिशा मिश्रित थी और घड़ी-समय की कोई बढ़त दावा नहीं की जाती। इंस्ट्रक्शन-लोड लेजर लोड किए गए bytes मापता है, टोकन, लागत या परिणाम नहीं, और इसका प्रवेश-बंडल आँकड़ा इस बात की सीमा नहीं है कि कोई रन क्या पढ़ता है। DWP जानबूझकर रिपॉज़िटरी तक सीमित है: यह न तो कोई क्रॉस-प्रोजेक्ट मेमोरी सिस्टम है, न भूमिका-आधारित एजेंट फ़्रेमवर्क, न ही कोई IDE — इसलिए यह इन क्षेत्रों में प्रतिस्पर्धा नहीं करता; जब काम की यही ज़रूरत हो तो इसे उस क्षेत्र को कवर करने वाले किसी उपकरण के साथ जोड़ें।
इसे सटीक बनाए रखने में मदद करें
इसे सटीक बनाए रखने में मदद करें
इस पृष्ठ की समीक्षा दिखाई गई तिथि को की गई है और अनुरोध पर सुधार की जाती है। यदि आपके उपकरण का विवरण पुराना या अधूरा है, तो एक issue खोलें और हम उसे ठीक कर देंगे।