OpenSpec

उदाहरण और रसोई ​

वास्तविक परिवर्तन, शुरुआत से अंत तक। हर रसोई उन कमांड्स को दिखाती है जो आप टाइप करेंगे और आपको क्या वापस मिलेगा, ताकि आप अपनी स्थिति को किसी पैटर्न से मिला सकें और उसे कॉपी कर सकें। ये डिफ़ॉल्ट core कमांड्स (propose, explore, apply, update, sync, archive) का उपयोग करते हैं; जहाँ विस्तारित सेट मदद करता है, वहाँ इसका उल्लेख किया गया है।

शुरू करने से पहले एक अनुस्मारक: /opsx:propose जैसे स्लैश कमांड्स आपके AI सहायक के चैट में जाते हैं, और openspec कमांड्स आपके टर्मिनल में जाते हैं。 अगर यह नया है, तो पहले कमांड्स कैसे काम करते हैं पढ़ें। नीचे दिए गए ट्रांसक्रिप्ट में, You: और AI: चैट हैं, और $ से शुरू होने वाली पंक्तियाँ टर्मिनल हैं।

अभी तक पक्का नहीं कि आप क्या बना रहे हैं? इनमें से अधिकांश रसोइयाँ तब और अधिक प्रभावी होती हैं जब आप /opsx:explore से शुरू करके पहले सोचते हैं। रसोई 3 इसे क्रिया में दिखाता है, और पहले एक्सप्लोर करें गाइड पूरा मामला पेश करता है।

रसोई 1: एक छोटा फीचर, तेज़ रास्ता ​

कब उपयोग करें: आपको पता है कि आप क्या चाहते हैं, और यह काम का एक सीमित हिस्सा है। यह सबसे आम रसोई है।

पूरा काम तीन कमांड्स में होता है। Propose, build, archive।

text
You: /opsx:propose add-logout-button

AI:  Created openspec/changes/add-logout-button/
     ✓ proposal.md — why and what
     ✓ specs/      — the new requirement and its scenarios
     ✓ design.md   — technical approach
     ✓ tasks.md    — implementation checklist
     Ready for implementation. Run /opsx:apply.

अब प्लान पढ़ें। प्रोपोज़ल और डेल्टा स्पेक खोलें। यह वह पल है जिसके लिए OpenSpec बनाया गया है: गलत धारणा को पकड़ना जब वह अभी भी एक पैराग्राफ है, न कि 400 लाइनों का कोड। अगर कुछ गलत है तो किसी भी आर्टिफैक्ट को सीधे एडिट करें, फिर आगे बढ़ें।

text
You: /opsx:apply

AI:  Working through tasks...
     ✓ 1.1 Add logout button to header
     ✓ 1.2 Clear session on click
     ✓ 1.3 Add confirmation dialog
     All tasks complete!

You: /opsx:archive

AI:  Archiving add-logout-button...
     ✓ Merged specs into openspec/specs/auth/spec.md
     ✓ Moved to openspec/changes/archive/2026-06-22-add-logout-button/
     Done. Ready for the next change.

बस इतना। लॉगआउट व्यवहार अब आपके स्पेक्स का हिस्सा है, और परिवर्तन अपने पूरे संदर्भ के साथ फाइल कर दिया गया है।

रसोई 2: एक बग फिक्स ​

कब उपयोग करें: कुछ टूटा हुआ है और आप चाहते हैं कि फिक्स व्यवहार में एक जानबूझकर किया गया परिवर्तन के रूप में दर्ज हो, न कि किसी रहस्यमय कमीट के रूप में।

बग फिक्स बिल्कुल फीचर्स की तरह काम करते हैं। अंतर प्रोपोज़ल को कैसे फ्रेम करने में है: सही व्यवहार का वर्णन करें, न कि बस "बग ठीक करें"।

text
You: /opsx:propose fix-login-redirect-loop

AI:  Created openspec/changes/fix-login-redirect-loop/
     The proposal captures the current broken behavior and the
     intended behavior. The delta spec MODIFIES the redirect
     requirement so it's now precise and testable.
     Ready for implementation.

क्योंकि फिक्स एक MODIFIED आवश्यकता के रूप में एक नए सिनेरियो के साथ आता है, अगला व्यक्ति (या अगला AI सेशन) न केवल यह देखता है कि आपने इसे ठीक किया, बल्कि यह भी कि "सही" का क्या अर्थ है। फिर /opsx:apply और /opsx:archive सामान्य रूप से करें।

सुझाव: फिक्स के लिए, एक अच्छा सिनेरियो प्रोसे में रीग्रेशन टेस्ट है। "GIVEN एक लॉग-आउट उपयोगकर्ता, WHEN वे मान्य क्रेडेंशियल्स सबमिट करते हैं, THEN वे डैशबोर्ड पर पहुँचते हैं और फिर से रीडायरेक्ट नहीं होते।" इसे लिखें, और इम्प्लीमेंटेशन का एक स्पष्ट लक्ष्य होता है।

रसोई 3: कमीट करने से पहले एक्सप्लोर करना ​

कब उपयोग करें: आपके पास एक समस्या है लेकिन अभी तक कोई प्लान नहीं। आपको पक्का नहीं कि क्या बनाना है, या कौन सा दृष्टिकोण सही है।

/opsx:explore से शुरू करें। यह एक सोचने का साथी है जिसमें कोई संरचना नहीं और कोई आर्टिफैक्ट नहीं बनाया जाता। यह आपका कोडबेस पढ़ता है और आपको निर्णय लेने में मदद करता है।

text
You: /opsx:explore

AI:  What would you like to explore?

You: Page loads feel slow but I don't know where the time goes.

AI:  Let me look... I found three likely culprits:
     1. Large unoptimized images on the product list
     2. Synchronous data fetching that blocks render
     3. Re-renders triggered by context changes
     Which should we tackle first?

You: The data fetching one.

You: /opsx:propose optimize-product-list-fetching

AI:  Created the change, with a proposal informed by what we just
     found. Ready for implementation.

एक्सप्लोरेशन आपके सोचने को पहले स्पष्ट करता है जब आप उस पर एक परिवर्तन खर्च करते हैं। जब अंतर्दृष्टि स्पष्ट होती है, तो प्रोपोज़ करें, और AI संदर्भ को आगे ले जाता है。

रसोई 4: एक साथ दो परिवर्तन संभालना ​

कब उपयोग करें: आप फीचर के बीच में हैं और एक आपातकालीन फिक्स कतार में आ जाता है।

परिवर्तन स्वतंत्र फोल्डर्स हैं, इसलिए समानांतर काम टकराव नहीं करता। फिक्स शुरू करें, उसे शिप करें, फिर फीचर पर वापस आएं जहाँ आप रुके थे।

text
You: I'm partway through add-dark-mode, but I need to fix a login bug now.

You: /opsx:propose fix-login-redirect

AI:  Created openspec/changes/fix-login-redirect/. Ready for implementation.

You: /opsx:apply

AI:  Implemented the fix. All tasks complete.

You: /opsx:archive

AI:  ✓ Archived fix-login-redirect.

You: Back to dark mode.

You: /opsx:apply add-dark-mode

AI:  Resuming add-dark-mode. Picking up at task 2.3: Update Header...

/opsx:apply add-dark-mode में परिवर्तन का नाम देना वह तरीका है जिससे आप AI को एक विशिष्ट परिवर्तन की ओर इशारा करते हैं जब एक से अधिक सक्रिय हों। क्योंकि टास्क tasks.md में पूर्णता ट्रैक करते हैं, AI को पता है कि आप ठीक कहाँ रुके थे।

जब कई परिवर्तन एक साथ पूरे हो जाते हैं, तो विस्तारित /opsx:bulk-archive उन्हें एक साथ फाइल करता है और वास्तव में क्या इम्प्लीमेंट किया गया है यह जाँचकर स्पेक टकराव को हल करता है। वर्कफ़्लो देखें।

रसोई 5: व्यवहार परिवर्तन के बिना रिफैक्टर ​

कब उपयोग करें: आप कोड को पुनर्गठित कर रहे हैं, और बाहरी रूप से दृश्य व्यवहार समान रहना चाहिए।

यह दिलचस्प मामला है, क्योंकि शुद्ध रिफैक्टर में आपके स्पेक्स में जोड़ने के लिए कुछ नहीं होता। व्यवहार अनुबंध नहीं बदलता; केवल इम्प्लीमेंटेशन बदलता है। इसलिए काम डिज़ाइन और टास्क में रहता है, और स्पेक डेल्टा खाली या अनुपस्थित होता है।

text
You: /opsx:propose refactor-payment-module

AI:  Created the change. The proposal states the goal (split the
     payment module, no behavior change) and the design captures
     the new structure. No spec changes, since behavior is identical.
     Ready for implementation.

परिवर्तन के .openspec.yaml में skip_specs: true सेट करके खाली डेल्टा को स्पष्ट रूप से घोषित करें:

yaml
schema: spec-driven
skip_specs: true

मार्कर के बिना, openspec validate शून्य डेल्टा वाले परिवर्तन को अस्वीकार करता है (ताकि भूले हुए स्पेक्स चरण को भी पकड़ा जा सके); इसके साथ, वैलिडेशन पास होता है और openspec status स्पेक्स चरण को स्पष्ट रूप से छोड़ा हुआ दिखाता है, लंबित के बजाय। अगर रिफैक्टर के बाद व्यवहार बदल जाता है, तो .openspec.yaml से skip_specs हटा दें और डेल्टा स्पेक्स लिखें — वैलिडेशन मार्कर और स्पेक फाइलों को टकराव के रूप में मानता है, इसलिए पुराना मार्कर चुपचाप नहीं रह सकता।

मार्क किए गए परिवर्तन को आर्काइव करने के लिए कोई अतिरिक्त फ्लैग नहीं चाहिए (डेल्टा मर्ज करने के लिए कुछ नहीं है)। स्वतंत्र रूप से, --skip-specs फ्लैग टर्मिनल कमांड को स्पेक चरण को स्पष्ट रूप से छोड़ने का निर्देश देता है:

bash
$ openspec archive refactor-payment-module --skip-specs

यही फ्लैग टूलिंग, CI, और केवल दस्तावेज़ों के परिवर्तनों के लिए भी उपयोगी है। सिद्धांत: स्पेक्स व्यवहार का वर्णन करते हैं, इसलिए अगर व्यवहार नहीं बदला, तो स्पेक भी नहीं बदलना चाहिए। कॉन्सेप्ट्स देखें।

रसोई 6: चरण-दर-चरण नियंत्रण (विस्तारित कमांड्स) ​

कब उपयोग करें: एक जटिल या जोखिम भरा परिवर्तन जहाँ आप आगे बढ़ने से पहले हर आर्टिफैक्ट की समीक्षा करना चाहते हैं।

कोर /opsx:propose सब कुछ एक साथ ड्राफ्ट करता है। जब आप एक-एक चरण में जाना चाहें, तो विस्तारित कमांड्स चालू करें:

bash
$ openspec config profile      # select the expanded workflows
$ openspec update              # apply them to this project

अब आप क्रमिक रूप से स्केलेफोल्ड और बिल्ड कर सकते हैं:

text
You: /opsx:new add-2fa

AI:  Created openspec/changes/add-2fa/. Ready to create: proposal.

You: /opsx:continue

AI:  Created proposal.md. Now available: specs, design.

You: /opsx:continue

AI:  Created specs/auth/spec.md. Now available: design.

हर आर्टिफैक्ट की समीक्षा करें जैसे वह आता है, मुक्त रूप से एडिट करें, और जब आप संतुष्ट हों तो आगे बढ़ें। जब आप बाकी सब कुछ एक साथ ड्राफ्ट करना चाहें, /opsx:ff शेष प्लानिंग आर्टिफैक्ट्स के माध्यम से फास्ट-फॉरवर्ड करता है। आर्काइव करने से पहले, /opsx:verify जाँच करता है कि इम्प्लीमेंटेशन वास्तव में स्पेक्स से मेल खाता है। वर्कफ़्लो देखें।

रसोई 7: पूरा लूप हाथ से सीखना ​

कब उपयोग करें: आपने OpenSpec इंस्टॉल किया है और अपने कोड पर वर्कफ़्लो को अनुभव करना चाहते हैं, न कि किसी खिलौने जैसे उदाहरण पर।

विस्तारित कमांड्स चालू करें (रसोई 6 देखें), फिर:

text
You: /opsx:onboard

AI:  Welcome to OpenSpec! I'll walk you through a complete change
     using your actual codebase. Let me scan for a small, safe
     improvement we can make together...

/opsx:onboard एक वास्तविक (छोटा) सुधार खोजता है, उसके लिए एक परिवर्तन बनाता है, उसे इम्प्लीमेंट करता है, और आर्काइव करता है, हर चरण का वर्णन करते हुए। इसमें 15 से 30 मिनट लगते हैं और आपको एक वास्तविक परिवर्तन मिलता है जिसे आप रख सकते हैं या छोड़ सकते हैं। यह सीखने का सबसे हल्का तरीका है। कमांड्स देखें。

टर्मिनल से अपना काम जाँचना ​

कभी भी, अपने टर्मिनल से, आप चीज़ों की स्थिति का निरीक्षण कर सकते हैं:

bash
$ openspec list                      # active changes
$ openspec show add-dark-mode        # one change in detail
$ openspec validate add-dark-mode    # check structure
$ openspec view                      # interactive dashboard

ये पढ़ने और निरीक्षण के टूल हैं। प्रोपोज़ और बिल्ड अभी भी चैट में स्लैश कमांड्स के माध्यम से होते हैं। पूर्ण विवरण CLI संदर्भ में है।

अगला कदम कहाँ ​