पहले Explore करें

/opsx:explore आपका सोचने का साथी है। जब आपके पास कोई समस्या हो लेकिन अभी कोई योजना नहीं, तो इसे इस्तेमाल करें। यह आपके कोडबेस का पता लगाता है, आपके साथ विकल्पों का मूल्यांकन करता है, और यह स्पष्ट करता है कि आप वास्तव में क्या चाहते हैं — सब कुछ इससे पहले कि कोई भी आर्टिफैक्ट या कोड की एक भी लाइन बनाई जाए। जब तस्वीर स्पष्ट हो जाती है, तो यह /opsx:propose को हस्तांतरित कर देता है।

अगर आप इन दस्तावेज़ों से एक आदत अपनाते हैं, तो यही अपनाएं: जब आप पक्के न हों, तो propose करने से पहले explore करें।

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

कब explore करें

Explore उम्मीद से ज़्यादा बार सही पहला कदम होता है। जब इनमें से कोई भी सत्य हो, तो इसका उपयोग करें:

• आपको समस्या पता है लेकिन हल नहीं। ("पेज धीमे लगते हैं।" "Auth एक बर्बाद है।" "हमें बार-बार डुप्लिकेट ऑर्डर मिलते हैं।")
• आप विभिन्न दृष्टिकोणों के बीच चुन रहे हैं और चाहते हैं कि आपके वास्तविक कोड के विरुद्ध ट्रेडऑफ़ स्पष्ट हों।
• आप किसी कोडबेस में नए हैं और बदलाव करने से पहले समझना चाहते हैं कि कोई चीज़ कैसे काम करती है।
• आवश्यकताएँ धुंधली हैं और आप commit करने से पहले उन्हें स्पष्ट करना चाहते हैं。
• आपको शक है कि काम दिखने से बड़ा या छोटा है और आप इसे ईमानदारी से scope करना चाहते हैं।

Explore तभी छोड़ें जब आपको पहले से ही पक्का पता हो कि आप क्या चाहते हैं और कैसे। उस स्थिति में सीधे /opsx:propose पर जाएँ।

यह क्या करता है (और क्या नहीं)

Explore एक बातचीत है, जनरेटर नहीं।

यह करता है:

• आपके कोडबेस को पढ़ता और खोजता है ताकि वास्तविक प्रश्नों के उत्तर दे सके।
• विकल्पों की तुलना करता है और प्रत्येक के ट्रेडऑफ़ बताता है।
• डिजाइन को स्पष्ट बनाने के लिए डायग्राम बनाता है।
• एक अस्पष्ट विचार को एक विशिष्ट, निर्माण योग्य scope में संकुचित करने में मदद करता है।
• जब आप तैयार हों तो /opsx:propose में संक्रमण करता है।

यह नहीं करता:

• कोई change फोल्डर नहीं बनाता।
• कोई आर्टिफैक्ट नहीं लिखता (कोई proposal, specs, design या tasks नहीं)।
• कोड नहीं लिखता या संशोधित नहीं करता।

यही मकसद है। Explore करने में आपको कुछ खर्च नहीं होता और आप किसी भी चीज़ के प्रति commit नहीं होते। आप तीन बेकार रास्ते explore कर सकते हैं, प्रत्येक से कुछ सीख सकते हैं, और तब propose कर सकते हैं जो रास्ता बचा।

यह पहले से इंस्टॉल है

अच्छी खबर: /opsx:explore डिफ़ॉल्ट core प्रोफ़ाइल में शामिल है, ठीक propose, apply, update, sync, और archive के साथ-साथ। आपको कुछ भी enable करने की ज़रूरत नहीं है। अगर OpenSpec आपके प्रोजेक्ट में सेट अप है, तो explore आपके AI चैट में तैयार है। (सभी /opsx:* कमांडों की तरह, आप इसे अपने सहायक के चैट में टाइप करते हैं, टर्मिनल में नहीं। देखें How Commands Work।)

एक पूरा उदाहरण

देखिए कि एक अस्पष्ट चिंता कैसे एक तीक्ष्ण, निर्माण योग्य बदलाव में बदलती है।

You: /opsx:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /opsx:propose add-order-idempotency-key

AI:  Created openspec/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

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

propose को हस्तांतरित करना

Explore किसी भी चीज़ में archive नहीं करता। जब आप तैयार हों, तो आप बस एक change शुरू करते हैं, और AI आपके संवाद से आर्टिफैक्ट्स में संदर्भ ले जाता है。

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

आप इसे साधारण भाषा में कह सकते हैं ("चलो इसे एक change में बदलते हैं") या सीधे /opsx:propose <name> चला सकते हैं। दोनों तरह से, आपकी exploration proposal की नींव बन जाती है, बेकार बातचीत नहीं।

अगर आप विस्तारित कमांड सेट का उपयोग करते हैं, तो explore /opsx:new में हस्तांतरित कर सकता है, चरण-दर-चरण आर्टिफैक्ट निर्माण के लिए। देखें Workflows।

अच्छी exploration के लिए सुझाव

• हल नहीं, समस्या लाइए। "लॉगिन धीमे लगते हैं" AI को जाँच करने का स्थान देता है। "Redis cache जोड़ो" आपको एक उत्तर के प्रति पहले से commit कर देता है जिसे आपने अभी तक परीक्षण नहीं किया।
• ट्रेडऑफ़ ज़ोर से पूछिए। "प्रत्येक विकल्प के नुकसान क्या हैं?" आपको अधिक ईमानदार तुलना देता है।
• पहले पढ़ने दो। सबसे अच्छी explorations AI के आपके कोड को वास्तव में देखने से शुरू होती हैं, अनुमान लगाने से नहीं। मदद के लिए उसे संबंधित क्षेत्र की ओर इशारा करें।
• बैल करना ठीक है। अगर exploration से पता चले कि विचार लायक नहीं है, तो वह जीत है। आपने इसे सस्ते में सीखा।
• बदलाव के बीच फिर explore करें। /opsx:apply के दौरान फंसे? आप वापस जाकर एक उप-समस्या explore कर सकते हैं, फिर वापस आ सकते हैं।

ईमानदार ट्रेडऑफ़

आप क्या पाते हैं: explore सबसे सस्ते संभव समय पर गलत मोड़ पकड़ता है, इससे पहले कि कोई आर्टिफैक्ट मौजूद हो। यह विशेष रूप से अपरिचित कोड में शक्तिशाली है, जहाँ AI की कोड पढ़ने और सारांशित करने की क्षमता आपको एक दोपहर की खोज से बचाती है।

इसकी कीमत क्या है: थोड़ा धैर्य। Explore एक बातचीत है, इसलिए यह /opsx:propose फायर करने और उम्मीद करने से धीमा है। ऐसे काम के लिए जिसे आप वास्तव में पहले से समझते हैं, वह अतिरिक्त कदम शुद्ध ओवरहेड है, और आपको इसे छोड़ना चाहिए।

सामान्य नियम: जितनी धुंधली कार्य, उतना ज़्यादा explore का लाभ। जितना स्पष्ट कार्य, उतना ज़्यादा आप सीधे propose पर जा सकते हैं।

अगला कदम कहाँ

• Commands: /opsx:explore: सटीक संदर्भ
• Workflows: explore को रोज़मर्रा के लूप का हिस्सा के रूप में
• Examples & Recipes: पूरे walkthrough में explore
• Getting Started: पहला बदलाव गाइड, exploration सहित