OPSX वर्कफ़्लो
Discord पर प्रतिक्रिया का स्वागत है।
यह क्या है?
OPSX अब OpenSpec के लिए मानक वर्कफ़्लो है।
यह OpenSpec परिवर्तनों के लिए एक तरल, आवर्ती वर्कफ़्लो है। अब कोई कठोर चरण नहीं — बस ऐसे क्रियाएँ जो आप कभी भी कर सकते हैं।
यह क्यों मौजूद है
पुराना OpenSpec वर्कफ़्लो काम करता है, लेकिन यह बंद है:
- निर्देश हार्डकोडेड हैं — TypeScript में दबे हुए हैं, आप इन्हें बदल नहीं सकते
- सब या कुछ नहीं — एक बड़ा कमांड सब कुछ बनाता है, अलग-अलग टुकड़ों का परीक्षण नहीं कर सकते
- निश्चित संरचना — सभी के लिए एक ही वर्कफ़्लो, कोई अनुकूलन नहीं
- ब्लैक बॉक्स — जब AI आउटपुट खराब होता है, तो आप प्रॉम्प्ट को ट्वीक नहीं कर सकते
OPSX इसे खोलता है। अब कोई भी कर सकता है:
- निर्देशों के साथ प्रयोग करें — एक टेम्पलेट संपादित करें, देखें कि क्या AI बेहतर करता है
- ग्रैन्युलर रूप से परीक्षण करें — प्रत्येक आर्टिफैक्ट के निर्देशों को स्वतंत्र रूप से मान्य करें
- वर्कफ़्लो को अनुकूलित करें — अपने स्वयं के आर्टिफैक्ट और निर्भरताएँ परिभाषित करें
- तेजी से दोहराएँ — एक टेम्पलेट बदलें, तुरंत परीक्षण करें, पुनर्निर्माण की आवश्यकता नहीं
पुराना वर्कफ़्लो: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ पैकेज में हार्डकोडेड │ │ schema.yaml │◄── आप इसे संपादित करते हैं
│ (बदल नहीं सकते) │ │ templates/*.md │◄── या इसे
│ ↓ │ │ ↓ │
│ नए रिलीज़ की प्रतीक्षा │ │ तत्काल प्रभाव │
│ ↓ │ │ ↓ │
│ उम्मीद है बेहतर होगा │ │ स्वयं परीक्षण करें │
└────────────────────────┘ └────────────────────────┘यह सबके लिए है:
- टीमें — ऐसे वर्कफ़्लो बनाएँ जो वास्तव में आपके काम करने के तरीके से मेल खाते हों
- पावर यूज़र — अपने कोडबेस के लिए बेहतर AI आउटपुट पाने के लिए प्रॉम्प्ट को ट्वीक करें
- OpenSpec योगदानकर्ता — बिना रिलीज़ के नए दृष्टिकोणों के साथ प्रयोग करें
हम सभी अभी भी सीख रहे हैं कि क्या सबसे अच्छा काम करता है। OPSX हमें एक साथ सीखने देता है।
उपयोगकर्ता अनुभव
रैखिक वर्कफ़्लो की समस्या: आप "योजना चरण में" हैं, फिर "कार्यान्वयन चरण में", फिर "पूर्ण"। लेकिन वास्तविक काम ऐसे नहीं चलता। आप कुछ लागू करते हैं, महसूस करते हैं कि आपका डिज़ाइन गलत था, विनिर्देशों को अपडेट करने की आवश्यकता है, कार्यान्वयन जारी रखें। रैखिक चरण वास्तव में काम कैसे होता है उसके विरुद्ध लड़ते हैं।
OPSX दृष्टिकोण:
- क्रियाएँ, चरण नहीं — बनाएँ, लागू करें, अपडेट करें, संग्रहीत करें — कभी भी कोई भी करें
- निर्भरताएँ सक्षम करने वाली हैं — वे दिखाती हैं कि क्या संभव है, न कि अगला क्या आवश्यक है
प्रस्ताव ──→ विनिर्देश ──→ डिज़ाइन ──→ कार्य ──→ कार्यान्वयनसेटअप
bash
# सुनिश्चित करें कि आपके पास openspec इंस्टॉल है — कौशल स्वचालित रूप से उत्पन्न होते हैं
openspec initयह .claude/skills/ (या समतुल्य) में कौशल बनाता है जिन्हें AI कोडिंग सहायक स्वचालित रूप से पहचानते हैं।
डिफ़ॉल्ट रूप से, OpenSpec core वर्कफ़्लो प्रोफ़ाइल (propose, explore, apply, archive) का उपयोग करता है। यदि आप विस्तारित वर्कफ़्लो कमांड (new, continue, ff, verify, sync, bulk-archive, onboard) चाहते हैं, तो उन्हें openspec config profile से कॉन्फ़िगर करें और openspec update से लागू करें।
सेटअप के दौरान, आपको एक प्रोजेक्ट कॉन्फ़िग (openspec/config.yaml) बनाने के लिए कहा जाएगा। यह वैकल्पिक है लेकिन अनुशंसित है।
प्रोजेक्ट कॉन्फ़िगरेशन
प्रोजेक्ट कॉन्फ़िग आपको डिफ़ॉल्ट सेट करने और सभी आर्टिफैक्ट में प्रोजेक्ट-विशिष्ट संदर्भ इंजेक्ट करने देता है।
कॉन्फ़िग बनाना
कॉन्फ़िग openspec init के दौरान बनाया जाता है, या मैन्युअल रूप से:
yaml
# openspec/config.yaml
schema: spec-driven
context: |
टेक स्टैक: TypeScript, React, Node.js
API परंपराएँ: RESTful, JSON प्रतिक्रियाएँ
परीक्षण: यूनिट परीक्षण के लिए Vitest, e2e के लिए Playwright
शैली: ESLint with Prettier, सख्त TypeScript
rules:
proposal:
- रोलबैक योजना शामिल करें
- प्रभावित टीमों की पहचान करें
specs:
- परिदृश्यों के लिए Given/When/Then प्रारूप का उपयोग करें
design:
- जटिल प्रवाहों के लिए सीक्वेंस डायग्राम शामिल करेंकॉन्फ़िग फ़ील्ड्स
| फ़ील्ड | प्रकार | विवरण |
|---|---|---|
schema | स्ट्रिंग | नए परिवर्तनों के लिए डिफ़ॉल्ट स्कीमा (जैसे, spec-driven) |
context | स्ट्रिंग | सभी आर्टिफैक्ट निर्देशों में इंजेक्ट किया गया प्रोजेक्ट संदर्भ |
rules | ऑब्जेक्ट | आर्टिफैक्ट-वार नियम, आर्टिफैक्ट आईडी से कुंजीबद्ध |
यह कैसे काम करता है
स्कीमा प्राथमिकता (सर्वोच्च से न्यूनतम):
- CLI फ़्लैग (
--schema <name>) - परिवर्तन मेटाडेटा (परिवर्तन निर्देशिका में
.openspec.yaml) - प्रोजेक्ट कॉन्फ़िग (
openspec/config.yaml) - डिफ़ॉल्ट (
spec-driven)
संदर्भ इंजेक्शन:
- संदर्भ हर आर्टिफैक्ट के निर्देशों के आगे जोड़ा जाता है
<context>...</context>टैग में लिपटा होता है- AI को आपकी परियोजना की परंपराओं को समझने में मदद करता है
नियम इंजेक्शन:
- नियम केवल मेल खाने वाले आर्टिफैक्ट के लिए इंजेक्ट किए जाते हैं
<rules>...</rules>टैग में लिपटे होते हैं- संदर्भ के बाद, टेम्पलेट से पहले दिखाई देते हैं
स्कीमा द्वारा आर्टिफैक्ट आईडी
spec-driven (डिफ़ॉल्ट):
proposal— परिवर्तन प्रस्तावspecs— विनिर्देशdesign— तकनीकी डिज़ाइनtasks— कार्यान्वयन कार्य
कॉन्फ़िग मान्यता
rulesमें अज्ञात आर्टिफैक्ट आईडी चेतावनियाँ उत्पन्न करते हैं- स्कीमा नाम उपलब्ध स्कीमा के विरुद्ध मान्य किए जाते हैं
- संदर्भ की आकार सीमा 50KB है
- अमान्य YAML को लाइन नंबरों के साथ रिपोर्ट किया जाता है
समस्या निवारण
"नियमों में अज्ञात आर्टिफैक्ट आईडी: X"
- जाँचें कि आर्टिफैक्ट आईडी आपके स्कीमा से मेल खाते हैं (ऊपर सूची देखें)
- प्रत्येक स्कीमा के लिए आर्टिफैक्ट आईडी देखने के लिए
openspec schemas --jsonचलाएँ
कॉन्फ़िग लागू नहीं हो रहा:
- सुनिश्चित करें कि फ़ाइल
openspec/config.yamlपर है (न कि.yml) - YAML सिंटैक्स को वैलिडेटर से जाँचें
- कॉन्फ़िग परिवर्तन तुरंत प्रभावी होते हैं (पुनरारंभ की आवश्यकता नहीं)
संदर्भ बहुत बड़ा:
- संदर्भ 50KB तक सीमित है
- संक्षेप में बताएँ या बाहरी दस्तावेज़ों से लिंक करें
कमांड
| कमांड | यह क्या करता है |
|---|---|
/opsx:propose | एक परिवर्तन बनाएँ और एक चरण में योजना आर्टिफैक्ट उत्पन्न करें (डिफ़ॉल्ट त्वरित पथ) |
/opsx:explore | विचारों पर विचार करें, समस्याओं की जाँच करें, आवश्यकताओं को स्पष्ट करें |
/opsx:new | एक नया परिवर्तन स्कैफ़ोल्ड शुरू करें (विस्तारित वर्कफ़्लो) |
/opsx:continue | अगला आर्टिफैक्ट बनाएँ (विस्तारित वर्कफ़्लो) |
/opsx:ff | योजना आर्टिफैक्ट को फास्ट-फ़ॉरवर्ड करें (विस्तारित वर्कफ़्लो) |
/opsx:apply | कार्य लागू करें, आवश्यकतानुसार आर्टिफैक्ट अपडेट करें |
/opsx:verify | आर्टिफैक्ट के विरुद्ध कार्यान्वयन को मान्य करें (विस्तारित वर्कफ़्लो) |
/opsx:sync | डेल्टा विनिर्देशों को मुख्य में सिंक करें (विस्तारित वर्कफ़्लो, वैकल्पिक) |
/opsx:archive | पूर्ण होने पर संग्रहीत करें |
/opsx:bulk-archive | कई पूर्ण परिवर्तनों को संग्रहीत करें (विस्तारित वर्कफ़्लो) |
/opsx:onboard | एक अंत-से-अंत परिवर्तन का निर्देशित वॉकथ्रू (विस्तारित वर्कफ़्लो) |
उपयोग
एक विचार का अन्वेषण करें
/opsx:exploreविचारों पर विचार करें, समस्याओं की जाँच करें, विकल्पों की तुलना करें। कोई संरचना आवश्यक नहीं - बस एक सोचने वाला साथी। जब अंतर्दृष्टि स्पष्ट हो जाए, तो /opsx:propose (डिफ़ॉल्ट) या /opsx:new//opsx:ff (विस्तारित) पर संक्रमण करें।
एक नया परिवर्तन शुरू करें
/opsx:proposeपरिवर्तन बनाता है और कार्यान्वयन से पहले आवश्यक योजना आर्टिफैक्ट उत्पन्न करता है।
यदि आपने विस्तारित वर्कफ़्लो सक्षम किया है, तो आप इसके बजाय उपयोग कर सकते हैं:
text
/opsx:new # केवल स्कैफ़ोल्ड
/opsx:continue # एक समय में एक आर्टिफैक्ट बनाएँ
/opsx:ff # सभी योजना आर्टिफैक्ट एक साथ बनाएँआर्टिफैक्ट बनाएँ
/opsx:continueनिर्भरताओं के आधार पर दिखाता है कि क्या बनाने के लिए तैयार है, फिर एक आर्टिफैक्ट बनाता है। अपने परिवर्तन को क्रमिक रूप से बनाने के लिए बार-बार उपयोग करें।
/opsx:ff add-dark-modeसभी योजना आर्टिफैक्ट एक साथ बनाता है। तब उपयोग करें जब आपको स्पष्ट हो कि आप क्या बना रहे हैं।
कार्यान्वयन (तरल भाग)
/opsx:applyकार्यों के माध्यम से काम करता है, जैसे-जैसे आप आगे बढ़ते हैं उन्हें चेक करता है। यदि आप कई परिवर्तनों को संभाल रहे हैं, तो आप /opsx:apply <name> चला सकते हैं; अन्यथा यह बातचीत से अनुमान लगाना चाहिए और यदि यह नहीं बता सकता तो आपको चुनने के लिए कहेगा।
समाप्त करें
/opsx:archive # पूर्ण होने पर संग्रह में ले जाएँ (यदि आवश्यक हो तो विनिर्देशों को सिंक करने के लिए कहता है)कब अपडेट करें बनाम नया शुरू करें
आप कार्यान्वयन से पहले हमेशा अपने प्रस्ताव या विनिर्देशों को संपादित कर सकते हैं। लेकिन कब परिष्करण "यह अलग काम है" बन जाता है?
एक प्रस्ताव क्या कैप्चर करता है
एक प्रस्ताव तीन चीजें परिभाषित करता है:
- इरादा — आप कौन सी समस्या हल कर रहे हैं?
- दायरा — क्या सीमा में है/बाहर है?
- दृष्टिकोण — आप इसे कैसे हल करेंगे?
सवाल यह है: क्या बदला, और कितना?
मौजूदा परिवर्तन को अपडेट करें जब:
समान इरादा, परिष्कृत निष्पादन
- आप ऐसे किनारे के मामलों की खोज करते हैं जिन पर आपने विचार नहीं किया था
- दृष्टिकोण में बदलाव की आवश्यकता है लेकिन लक्ष्य अपरिवर्तित है
- कार्यान्वयन से पता चलता है कि डिज़ाइन थोड़ा गलत था
दायरा संकुचित होता है
- आप महसूस करते हैं कि पूर्ण दायरा बहुत बड़ा है, पहले MVP शिप करना चाहते हैं
- "डार्क मोड जोड़ें" → "डार्क मोड टॉगल जोड़ें (v2 में सिस्टम प्रेफरेंस)"
सीख-संचालित सुधार
- कोडबेस उस तरह से संरचित नहीं है जैसा आपने सोचा था
- एक निर्भरता अपेक्षा के अनुसार काम नहीं करती
- "CSS वेरिएबल्स का उपयोग करें" → "इसके बजाय Tailwind के dark: प्रीफ़िक्स का उपयोग करें"
एक नया परिवर्तन शुरू करें जब:
इरादा मौलिक रूप से बदल गया
- समस्या अब अलग है
- "डार्क मोड जोड़ें" → "कस्टम रंगों, फ़ॉन्ट्स, स्पेसिंग के साथ एक व्यापक थीम सिस्टम जोड़ें"
दायरा विस्फोट हो गया
- परिव�र्तन इतना बढ़ गया कि यह अनिवार्य रूप से अलग काम है
- मूल प्रस्ताव अपडेट के बाद पहचानने योग्य नहीं होगा
- "लॉगिन बग ठीक करें" → "ऑथ सिस्टम को फिर से लिखें"
मूल पूर्ण करने योग्य है
- मूल परिवर्तन को "पूर्ण" चिह्नित किया जा सकता है
- नया काम अकेला खड़ा है, परिष्करण नहीं
- "डार्क मोड MVP जोड़ें" पूर्ण करें → संग्रहीत करें → नया परिवर्तन "डार्क मोड बढ़ाएँ"
ह्यूरिस्टिक्स
┌─────────────────────────────────────┐
│ क्या यह समान काम है? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
समान इरादा? >50% ओवरलैप? क्या मूल
समान समस्या? समान दायरा? इन परिवर्तनों के
│ │ बिना "पूर्ण" हो सकता है?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
हाँ नहीं हाँ नहीं नहीं हाँ
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
अपडेट करें नया अपडेट करें नया अपडेट करें नया| परीक्षण | अपडेट करें | नया परिवर्तन |
|---|---|---|
| पहचान | "समान चीज़, परिष्कृत" | "अलग काम" |
| दायरा ओवरलैप | >50% ओवरलैप | <50% ओवरलैप |
| पूर्णता | परिवर्तनों के बिना "पूर्ण" नहीं हो सकता | मूल को पूरा कर सकते हैं, नया काम अकेला खड़ा है |
| कहानी | अपडेट श्रृंखला एक सुसंगत कहानी बताती है | पैच स्पष्ट करने से अधिक भ्रमित करेंगे |
सिद्धांत
अपडेट संदर्भ को संरक्षित करता है। नया परिवर्तन स्पष्टता प्रदान करता है।
अपडेट चुनें जब आपकी सोच का इतिहास मूल्यवान हो। नया चुनें जब नया शुरू करना पैचिंग से अधिक स्पष्ट हो।
इसे git शाखाओं की तरह सोचें:
- जब तक आप एक ही फ़ीचर पर काम कर रहे हैं तब तक कमिट करते रहें
- जब वास्तव में नया काम हो तो एक नई शाखा शुरू करें
- कभी-कभी एक आंशिक फ़ीचर को मर्ज करें और चरण 2 के लिए नया शुरू करें
क्या अलग है?
लेगेसी (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| संरचना | एक बड़ा प्रस्ताव दस्तावेज़ | निर्भरताओं वाले अलग-अलग आर्टिफैक्ट्स |
| कार्यप्रवाह | रैखिक चरण: योजना → कार्यान्वयन → संग्रह | तरल क्रियाएँ — कभी भी कुछ भी करें |
| पुनरावृत्ति | वापस जाना असहज | सीखते हुए आर्टिफैक्ट्स अपडेट करें |
| अनुकूलन | निश्चित संरचना | स्कीमा-संचालित (अपने आर्टिफैक्ट्स परिभाषित करें) |
मुख्य अंतर्दृष्टि: काम रैखिक नहीं है। OPSX इसे होने का दिखावा करना बंद कर देता है।
आर्किटेक्चर गहन विश्लेषण
यह अनुभाग समझाता है कि OPSX अंदरूनी रूप से कैसे काम करता है और यह पुराने वर्कफ़्लो की तुलना में कैसे है। इस अनुभाग के उदाहरण विस्तारित कमांड सेट (new, continue, आदि) का उपयोग करते हैं; डिफ़ॉल्ट core उपयोगकर्ता उसी प्रवाह को propose → apply → archive में मैप कर सकते हैं।
दर्शन: चरण बनाम क्रियाएँ
┌─────────────────────────────────────────────────────────────────────────────┐
│ पुराना वर्कफ़्लो │
│ (चरण-बंद, सब-या-कुछ नहीं) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ योजना │ ───► │ कार्यान्वयन │ ───► │ संग्रहण │ │
│ │ चरण │ │ चरण │ │ चरण │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • एक बार में सभी कलाकृतियाँ बनाता है │
│ • कार्यान्वयन के दौरान स्पेसिफिकेशन अपडेट करने के लिए वापस नहीं जा सकता │
│ • चरण द्वार रैखिक प्रगति लागू करते हैं │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX वर्कफ़्लो │
│ (तरल क्रियाएँ, आवर्ती) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ क्रियाएँ (चरण नहीं) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ कोई भी क्रम │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • कलाकृतियाँ एक-एक करके बनाएँ या तेज़ी से आगे बढ़ें │
│ • कार्यान्वयन के दौरान स्पेसिफिकेशन/डिज़ाइन/कार्य अपडेट करें │
│ • निर्भरताएँ प्रगति को सक्षम करती हैं, चरण मौजूद नहीं हैं │
│ │
└─────────────────────────────────────────────────────────────────────────────┘घटक आर्किटेक्चर
पुराना वर्कफ़्लो TypeScript में हार्डकोडेड टेम्पलेट का उपयोग करता है:
┌─────────────────────────────────────────────────────────────────────────────┐
│ पुराने वर्कफ़्लो के घटक │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ हार्डकोडेड टेम्पलेट (TypeScript स्ट्रिंग्स) │
│ │ │
│ ▼ │
│ टूल-विशिष्ट कॉन्फ़िगरेटर/एडाप्टर │
│ │ │
│ ▼ │
│ जनरेटेड कमांड फ़ाइलें (.claude/commands/openspec/*.md) │
│ │
│ • निश्चित संरचना, कलाकृति जागरूकता नहीं │
│ • परिवर्तन के लिए कोड संशोधन + पुनर्निर्माण आवश्यक │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX बाहरी स्कीमा और एक निर्भरता ग्राफ़ इंजन का उपयोग करता है:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX घटक │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ स्कीमा परिभाषाएँ (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── निर्भरताएँ │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── ग्लोब पैटर्न │ │
│ │ requires: [proposal] ◄── proposal के बाद सक्षम करता है │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ कलाकृति ग्राफ़ इंजन │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • टोपोलॉजिकल सॉर्ट (निर्भरता क्रम) │ │
│ │ • स्थिति पहचान (फ़ाइलसिस्टम अस्तित्व) │ │
│ │ • समृद्ध निर्देश जनरेशन (टेम्पलेट + संदर्भ) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ स्किल फ़ाइलें (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • क्रॉस-एडिटर संगत (Claude Code, Cursor, Windsurf) │
│ • संरचित डेटा के लिए स्किल्स CLI क्वेरी करते हैं │
│ • स्कीमा फ़ाइलों के माध्यम से पूरी तरह से अनुकूलन योग्य │
│ │
└─────────────────────────────────────────────────────────────────────────────┘निर्भरता ग्राफ़ मॉडल
कलाकृतियाँ एक निर्देशित अचक्रीय ग्राफ़ (DAG) बनाती हैं। निर्भरताएँ सक्षमकर्ता हैं, द्वार नहीं:
proposal
(मूल नोड)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(आवश्यक: (आवश्यक:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(आवश्यक:
specs, design)
│
▼
┌──────────────┐
│ APPLY चरण │
│ (आवश्यक: │
│ tasks) │
└──────────────┘स्थिति संक्रमण:
अवरुद्ध ────────────────► तैयार ────────────────► पूर्ण
│ │ │
गायब सभी निर्भरताएँ फ़ाइल मौजूद है
निर्भरताएँ पूर्ण हैं फ़ाइलसिस्टम परसूचना प्रवाह
पुराना वर्कफ़्लो — एजेंट को स्थिर निर्देश प्राप्त होते हैं:
उपयोगकर्ता: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ स्थिर निर्देश: │
│ • proposal.md बनाएँ │
│ • tasks.md बनाएँ │
│ • design.md बनाएँ │
│ • specs/<capability>/spec.md बनाएँ │
│ │
│ इस बात की जागरूकता नहीं कि क्या मौजूद है या
│ कलाकृतियों के बीच निर्भरताएँ │
└─────────────────────────────────────────┘
│
▼
एजेंट एक बार में सभी कलाकृतियाँ बनाता हैOPSX — एजेंट समृद्ध संदर्भ के लिए क्वेरी करता है:
उपयोगकर्ता: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ चरण 1: वर्तमान स्थिति क्वेरी करें │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── पहला तैयार │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ चरण 2: तैयार कलाकृति के लिए समृद्ध निर्देश प्राप्त करें │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# विनिर्देश\n\n## जोड़े गए आवश्यकताएँ...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ चरण 3: निर्भरताएँ पढ़ें → एक कलाकृति बनाएँ → दिखाएँ क्या अनलॉक हुआ │
└──────────────────────────────────────────────────────────────────────────┘आवर्तन मॉडल
पुराना वर्कफ़्लो — आवर्तन करना असहज:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "रुकिए, डिज़ाइन गलत है"
│ │
│ ├── विकल्प:
│ │ • फ़ाइलें मैन्युअल रूप से संपादित करें (संदर्भ टूटता है)
│ │ • छोड़ें और फिर से शुरू करें
│ │ • आगे बढ़ें और बाद में ठीक करें
│ │
│ └── कोई आधिकारिक "वापस जाएँ" तंत्र नहीं
│
└── एक बार में सभी कलाकृतियाँ बनाता हैOPSX — प्राकृतिक आवर्तन:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "डिज़ाइन गलत है"
│ │ │
│ │ ▼
│ │ बस design.md संपादित करें
│ │ और जारी रखें!
│ │ │
│ │ ▼
│ │ /opsx:apply वहीं से उठाता है
│ │ जहाँ आप छोड़ गए थे
│ │
│ └── एक कलाकृति बनाता है, दिखाता है क्या अनलॉक हुआ
│
└── परिवर्तन का स्कैफ़ोल्ड बनाता है, निर्देश की प्रतीक्षा करता हैकस्टम स्कीमा
स्कीमा प्रबंधन कमांड का उपयोग करके कस्टम वर्कफ़्लो बनाएँ:
bash
# शुरू से एक नई स्कीमा बनाएँ (इंटरैक्टिव)
openspec schema init my-workflow
# या एक मौजूदा स्कीमा को शुरुआती बिंदु के रूप में फ़ोर्क करें
openspec schema fork spec-driven my-workflow
# अपनी स्कीमा संरचना मान्य करें
openspec schema validate my-workflow
# देखें कि स्कीमा कहाँ से रिज़ॉल्व होती है (डीबगिंग के लिए उपयोगी)
openspec schema which my-workflowस्कीमाएँ openspec/schemas/ (प्रोजेक्ट-स्थानीय, संस्करण नियंत्रित) या ~/.local/share/openspec/schemas/ (उपयोगकर्ता वैश्विक) में संग्रहीत होती हैं।
स्कीमा संरचना:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdउदाहरण schema.yaml:
yaml
name: research-first
artifacts:
- id: research # proposal से पहले जोड़ा गया
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # अब research पर निर्भर है
- id: tasks
generates: tasks.md
requires: [proposal]निर्भरता ग्राफ़:
research ──► proposal ──► tasksसारांश
| पहलू | पुराना | OPSX |
|---|---|---|
| टेम्पलेट | हार्डकोडेड TypeScript | बाहरी YAML + Markdown |
| निर्भरताएँ | कोई नहीं (सब एक बार में) | टोपोलॉजिकल सॉर्ट वाला DAG |
| स्थिति | चरण-आधारित मानसिक मॉडल | फ़ाइलसिस्टम अस्तित्व |
| अनुकूलन | स्रोत संपादित करें, पुनर्निर्माण करें | schema.yaml बनाएँ |
| आवर्तन | चरण-बंद | तरल, कुछ भी संपादित करें |
| एडिटर समर्थन | टूल-विशिष्ट कॉन्फ़िगरेटर/एडाप्टर | एकल स्किल्स निर्देशिका |
स्कीमाज़
स्कीमाज़ यह परिभाषित करते हैं कि कौन सी कलाकृतियाँ मौजूद हैं और उनकी निर्भरताएँ क्या हैं। वर्तमान में उपलब्ध:
- spec-driven (डिफ़ॉल्ट): प्रस्ताव → विनिर्देश → डिज़ाइन → कार्य
bash
# उपलब्ध स्कीमाज़ सूचीबद्ध करें
openspec schemas
# सभी स्कीमाज़ और उनके समाधान स्रोत देखें
openspec schema which --all
# एक नया स्कीमा इंटरैक्टिव रूप से बनाएँ
openspec schema init my-workflow
# कस्टमाइज़ेशन के लिए एक मौजूदा स्कीमा को फ़ोर्क करें
openspec schema fork spec-driven my-workflow
# उपयोग से पहले स्कीमा संरचना मान्य करें
openspec schema validate my-workflowसुझाव
- किसी बदलाव को लागू करने से पहले किसी विचार पर विचार करने के लिए
/opsx:exploreका उपयोग करें - जब आप जानते हैं कि आपको क्या चाहिए तब
/opsx:ffका उपयोग करें, और जब खोज रहे हों तब/opsx:continue /opsx:applyके दौरान, यदि कुछ गलत है — कलाकृति को ठीक करें, फिर जारी रखें- कार्य
tasks.mdमें चेकबॉक्स के माध्यम से प्रगति ट्रैक करते हैं - कभी भी स्थिति जाँचें:
openspec status --change "name"
प्रतिक्रिया
यह अपरिष्कृत है। यह जानबूझकर है — हम सीख रहे हैं कि क्या काम करता है।
कोई बग मिला? कोई विचार है? हमसे Discord पर जुड़ें या GitHub पर कोई इश्यू खोलें।