OPSX कार्यप्रवाह
Discord पर प्रतिक्रिया का स्वागत है।
यह क्या है?
OPSX अब OpenSpec के लिए मानक कार्यप्रवाह है।
यह OpenSpec परिवर्तनों के लिए एक सहज, पुनरावृत्ति-आधारित कार्यप्रवाह है। कोई कठोर चरण नहीं — बस वे क्रियाएं जो आप कभी भी कर सकते हैं।
यह क्यों मौजूद है
पुराना OpenSpec वर्कफ़्लो काम करता है, लेकिन यह लॉक्ड डाउन है:
- निर्देश हार्डकोडेड हैं — TypeScript में दबे हुए, आप उन्हें बदल नहीं सकते
- ऑल-ऑर-नथिंग — एक बड़ा कमांड सब कुछ बनाता है, व्यक्तिगत टुकड़ों का परीक्षण नहीं कर सकता
- निश्चित संरचना — सभी के लिए एक ही वर्कफ़्लो, कोई कस्टमाइज़ेशन नहीं
- ब्लैक बॉक्स — जब AI आउटपुट खराब हो, तो आप प्रॉम्प्ट को ट्वीक नहीं कर सकते
OPSX इसे खोलता है। अब कोई भी कर सकता है:
- निर्देशों के साथ प्रयोग करें — एक टेम्पलेट संपादित करें, देखें कि क्या AI बेहतर करता है
- सूक्ष्म रूप से परीक्षण करें — प्रत्येक आर्टिफ़ैक्ट के निर्देशों को स्वतंत्र रूप से सत्यापित करें
- वर्कफ़्लो को कस्टमाइज़ करें — अपने स्वयं के आर्टिफ़ैक्ट और निर्भरताएं परिभाषित करें
- तेज़ी से दोहराएं — एक टेम्पलेट बदलें, तुरंत परीक्षण करें, कोई पुनर्निर्माण नहीं
पुराना वर्कफ़्लो: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ पैकेज में हार्डकोडेड │ │ schema.yaml │◄── आप इसे संपादित करें
│ (बदल नहीं सकते) │ │ templates/*.md │◄── या यह
│ ↓ │ │ ↓ │
│ नए रिलीज़ की प्रतीक्षा │ │ तत्काल प्रभाव │
│ ↓ │ │ ↓ │
│ आशा करें कि यह बेहतर है│ │ स्वयं परीक्षण करें │
└────────────────────────┘ └────────────────────────┘यह सभी के लिए है:
- टीमें — ऐसे वर्कफ़्लो बनाएं जो आपके वास्तविक काम करने के तरीके से मेल खाते हों
- पावर यूज़र्स — अपने कोडबेस के लिए बेहतर AI आउटपुट प्राप्त करने के लिए प्रॉम्प्ट को ट्वीक करें
- OpenSpec योगदानकर्ता — रिलीज़ के बिना नए दृष्टिकोणों के साथ प्रयोग करें
हम सभी अभी भी सीख रहे हैं कि सबसे अच्छा क्या काम करता है। OPSX हमें एक साथ सीखने देता है।
उपयोगकर्ता अनुभव
रैखिक वर्कफ़्लो की समस्या: आप "योजना चरण में" हैं, फिर "कार्यान्वयन चरण में", फिर "पूर्ण"। लेकिन वास्तविक काम इस तरह से काम नहीं करता। आप कुछ लागू करते हैं, महसूस करते हैं कि आपका डिज़ाइन गलत था, स्पेक्स को अपडेट करने की आवश्यकता है, कार्यान्वयन जारी रखें। रैखिक चरण इस बात के विरुद्ध लड़ते हैं कि काम वास्तव में कैसे होता है।
OPSX दृष्टिकोण:
- क्रियाएं, चरण नहीं — बनाएं, लागू करें, अपडेट करें, संग्रहीत करें — इनमें से कोई भी कभी भी करें
- निर्भरताएं सक्षमकर्ता हैं — वे दिखाते हैं कि क्या संभव है, न कि आगे क्या आवश्यक है
proposal ──→ specs ──→ design ──→ tasks ──→ implementसेटअप
bash
# सुनिश्चित करें कि आपके पास openspec इंस्टॉल है — स्किल्स स्वचालित रूप से जनरेट होती हैं
openspec initयह .claude/skills/ (या समकक्ष) में स्किल्स बनाता है जिन्हें AI कोडिंग असिस्टेंट स्वचालित रूप से पहचान लेते हैं।
डिफ़ॉल्ट रूप से, OpenSpec core वर्कफ़्लो प्रोफ़ाइल (propose, explore, apply, sync, archive) का उपयोग करता है। यदि आप विस्तारित वर्कफ़्लो कमांड (new, continue, ff, verify, 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
शैली: Prettier के साथ ESLint, सख्त TypeScript
rules:
proposal:
- रोलबैक योजना शामिल करें
- प्रभावित टीमों की पहचान करें
specs:
- परिदृश्यों के लिए Given/When/Then प्रारूप का उपयोग करें
design:
- जटिल प्रवाह के लिए अनुक्रम आरेख शामिल करेंकॉन्फ़िग फ़ील्ड
| फ़ील्ड | प्रकार | विवरण |
|---|---|---|
schema | string | नए परिवर्तनों के लिए डिफ़ॉल्ट स्कीमा (जैसे, spec-driven) |
context | string | सभी आर्टिफ़ैक्ट निर्देशों में इंजेक्ट किया गया प्रोजेक्ट संदर्भ |
rules | object | आर्टिफ़ैक्ट आईडी द्वारा कुंजीयुक्त, प्रति-आर्टिफ़ैक्ट नियम |
यह कैसे काम करता है
स्कीमा प्राथमिकता (उच्चतम से निम्नतम):
- 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 → sync → archive पर मैप कर सकते हैं।
दर्शनशास्त्र: चरण बनाम क्रियाएँ
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW │
│ (Phase-Locked, All-or-Nothing) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNING │ ───► │ IMPLEMENTING │ ───► │ ARCHIVING │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Creates ALL artifacts at once │
│ • Can't go back to update specs during implementation │
│ • Phase gates enforce linear progression │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX WORKFLOW │
│ (Fluid Actions, Iterative) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIONS (not phases) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ any order │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Create artifacts one at a time OR fast-forward │
│ • Update specs/design/tasks during implementation │
│ • Dependencies enable progress, phases don't exist │
│ │
└─────────────────────────────────────────────────────────────────────────────┘कंपोनेंट आर्किटेक्चर
लेगेसी वर्कफ़्लो TypeScript में हार्डकोडेड टेम्पलेट्स का उपयोग करता है:
┌─────────────────────────────────────────────────────────────────────────────┐
│ LEGACY WORKFLOW COMPONENTS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Hardcoded Templates (TypeScript strings) │
│ │ │
│ ▼ │
│ Tool-specific configurators/adapters │
│ │ │
│ ▼ │
│ Generated Command Files (.claude/commands/openspec/*.md) │
│ │
│ • Fixed structure, no artifact awareness │
│ • Change requires code modification + rebuild │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX बाहरी स्कीमा और एक निर्भरता ग्राफ़ इंजन का उपयोग करता है:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX COMPONENTS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Schema Definitions (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Dependencies │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob patterns │ │
│ │ requires: [proposal] ◄── Enables after proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Artifact Graph Engine │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Topological sort (dependency ordering) │ │
│ │ • State detection (filesystem existence) │ │
│ │ • Rich instruction generation (templates + context) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Skill Files (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Cross-editor compatible (Claude Code, Cursor, Windsurf) │
│ • Skills query CLI for structured data │
│ • Fully customizable via schema files │
│ │
└─────────────────────────────────────────────────────────────────────────────┘निर्भरता ग्राफ़ मॉडल
आर्टिफैक्ट्स एक निर्देशित एसाइक्लिक ग्राफ़ (DAG) बनाते हैं। निर्भरताएँ सक्षमकर्ता हैं, गेट नहीं:
proposal
(root node)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (requires: │
│ tasks) │
└──────────────┘स्थिति परिवर्तन:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
Missing All deps File exists
dependencies are DONE on filesystemसूचना प्रवाह
लेगेसी वर्कफ़्लो — एजेंट स्थैतिक निर्देश प्राप्त करता है:
User: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Static instructions: │
│ • Create proposal.md │
│ • Create tasks.md │
│ • Create design.md │
│ • Create specs/<capability>/spec.md │
│ │
│ No awareness of what exists or │
│ dependencies between artifacts │
└─────────────────────────────────────────┘
│
▼
Agent creates ALL artifacts in one goOPSX — एजेंट समृद्ध संदर्भ के लिए क्वेरी करता है:
User: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Step 1: Query current state │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── First ready │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Step 2: Get rich instructions for ready artifact │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Step 3: Read dependencies → Create ONE artifact → Show what's unlocked │
└──────────────────────────────────────────────────────────────────────────┘पुनरावृत्ति मॉडल
लेगेसी वर्कफ़्लो — पुनरावृत्ति करना अजीब है:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Wait, the design is wrong"
│ │
│ ├── Options:
│ │ • Edit files manually (breaks context)
│ │ • Abandon and start over
│ │ • Push through and fix later
│ │
│ └── No official "go back" mechanism
│
└── Creates ALL artifacts at onceOPSX — स्वाभाविक पुनरावृत्ति:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "The design is wrong"
│ │ │
│ │ ▼
│ │ Just edit design.md
│ │ and continue!
│ │ │
│ │ ▼
│ │ /opsx:apply picks up
│ │ where you left off
│ │
│ └── Creates ONE artifact, shows what's unlocked
│
└── Scaffolds change, waits for directionकस्टम स्कीमा
स्कीमा प्रबंधन कमांड का उपयोग करके कस्टम वर्कफ़्लो बनाएँ:
bash
# Create a new schema from scratch (interactive)
openspec schema init my-workflow
# Or fork an existing schema as a starting point
openspec schema fork spec-driven my-workflow
# Validate your schema structure
openspec schema validate my-workflow
# See where a schema resolves from (useful for debugging)
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 # Added before proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Now depends on research
- id: tasks
generates: tasks.md
requires: [proposal]निर्भरता ग्राफ़:
research ──► proposal ──► tasksसारांश
| पहलू | लेगेसी | OPSX |
|---|---|---|
| टेम्पलेट्स | हार्डकोडेड TypeScript | बाहरी YAML + Markdown |
| निर्भरताएँ | कोई नहीं (एक साथ सभी) | टोपोलॉजिकल सॉर्ट वाला DAG |
| स्थिति | चरण-आधारित मानसिक मॉडल | फ़ाइलसिस्टम अस्तित्व |
| अनुकूलन | स्रोत संपादित करें, पुनर्निर्माण करें | schema.yaml बनाएँ |
| पुनरावृत्ति | चरण-लॉक्ड | तरल, कुछ भी संपादित करें |
| संपादक समर्थन | टूल-विशिष्ट कॉन्फ़िगरेटर/एडाप्टर | एकल स्किल्स निर्देशिका |
स्कीमाएँ
स्कीमाएँ परिभाषित करती हैं कि कौन से आर्टिफैक्ट मौजूद हैं और उनकी निर्भरताएँ क्या हैं। वर्तमान में उपलब्ध:
- विनिर्देश-संचालित (डिफ़ॉल्ट): प्रस्ताव → विनिर्देश → डिज़ाइन → कार्य
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 पर एक इश्यू खोलें।