OPSX कार्यप्रवाह
Discord पर प्रतिक्रिया स्वागत है।
यह क्या है?
OPSX अब OpenSpec के लिए मानक कार्यप्रवाह है।
यह OpenSpec परिवर्तनों के लिए एक लचीला, पुनरावृत्ति-आधारित कार्यप्रवाह है। अब कोई कठोर चरण नहीं — बस ऐसे कार्य जो आप कभी भी कर सकते हैं।
यह क्यों मौजूद है
पुरानी OpenSpec कार्यप्रणाली काम करती है, लेकिन यह बंद है:
- निर्देश हार्डकोडेड हैं — TypeScript में दबे हैं, आप उन्हें बदल नहीं सकते
- सब-या-कुछ-नहीं — एक बड़ा कमांड सब कुछ बना देता है, अलग-अलग हिस्सों का परीक्षण नहीं कर सकते
- निश्चित संरचना — सबके लिए एक जैसी कार्यप्रणाली, कोई अनुकूलन नहीं
- ब्लैक बॉक्स — जब AI आउटपुट खराब हो, तो प्रॉम्प्ट में बदलाव नहीं कर सकते
OPSX इसे खोलता है। अब कोई भी यह कर सकता है:
- निर्देशों के साथ प्रयोग करें — एक टेम्पलेट संपादित करें, देखें कि AI बेहतर करता है या नहीं
- सूक्ष्मता से परीक्षण करें — प्रत्येक आर्टिफैक्ट के निर्देशों को स्वतंत्र रूप से मान्य करें
- कार्यप्रवाहों को अनुकूलित करें — अपने स्वयं के आर्टिफैक्ट और निर्भरताएँ परिभाषित करें
- तेजी से पुनरावृत्ति करें — टेम्पलेट बदलें, तुरंत परीक्षण करें, कोई पुनर्निर्माण नहीं
पुरानी कार्यप्रणाली: OPSX:
┌─────────────────────────────────────┐ ┌─────────────────────────────────────┐
│ पैकेज में हार्डकोडेड │ │ schema.yaml ◄── आप इसे │
│ (बदल नहीं सकते) │ │ templates/*.md ◄── या इसे │
│ ↓ │ │ ↓ │
│ नई रिलीज़ की प्रतीक्षा करें │ │ तुरंत प्रभाव │
│ ↓ │ │ ↓ │
│ उम्मीद करें कि यह बेहतर हो │ │ स्वयं परीक्षण करें │
└─────────────────────────────────────┘ └─────────────────────────────────────┘यह सबके लिए है:
- टीमें — ऐसे वर्कफ़्लो बनाएँ जो आपकी वास्तविक कार्यशैली से मेल खाएँ
- पावर यूज़र्स — अपने कोडबेस के लिए बेहतर AI आउटपुट पाने हेतु प्रॉम्प्ट में फेरबदल करें
- OpenSpec योगदानकर्ता — रिलीज़ के बिना नए दृष्टिकोणों के साथ प्रयोग करें
हम सब अभी भी सीख रहे हैं कि सबसे अच्छा क्या काम करता है। OPSX हमें एक साथ सीखने देता है।
उपयोगकर्ता अनुभव
रैखिक वर्कफ़्लो की समस्या: आप 'योजना चरण' में होते हैं, फिर 'कार्यान्वयन चरण' में, फिर 'पूर्ण'। लेकिन वास्तविक काम इस तरह नहीं होता। आप कुछ लागू करते हैं, पाते हैं कि आपका डिज़ाइन गलत था, स्पेक्स अपडेट करने की जरूरत होती है, कार्यान्वयन जारी रखते हैं। रैखिक चरण वास्तविक कार्यप्रवाह से लड़ते हैं।
OPSX दृष्टिकोण:
- क्रियाएँ, चरण नहीं — बनाएँ, कार्यान्वित करें, अद्यतन करें, संग्रहित करें — कभी भी करें
- निर्भरताएँ सक्षमक हैं — वे दिखाती हैं कि क्या संभव है, न कि अगला क्या आवश्यक है
प्रस्ताव ──→ स्पेक्स ──→ डिज़ाइन ──→ कार्य ──→ कार्यान्वयनसेटअप
# सुनिश्चित करें कि openspec इंस्टॉल है — कौशल स्वचालित रूप से उत्पन्न होते हैं
openspec initयह .claude/skills/ (या समकक्ष) में कौशल बनाता है जिन्हें AI कोडिंग असिस्टेंट स्वतः पहचान लेते हैं।
डिफ़ॉल्ट रूप से, OpenSpec core वर्कफ़्लो प्रोफ़ाइल का उपयोग करता है (propose, explore, apply, update, sync, archive)। यदि आप विस्तारित वर्कफ़्लो कमांड चाहते हैं (new, continue, ff, verify, bulk-archive, onboard), तो उन्हें openspec config profile के साथ कॉन्फ़िगर करें और openspec update के साथ लागू करें।
सेटअप के दौरान, आपको एक प्रोजेक्ट कॉन्फ़िग (openspec/config.yaml) बनाने के लिए कहा जाएगा। यह वैकल्पिक है लेकिन अनुशंसित है।
प्रोजेक्ट कॉन्फ़िगरेशन
प्रोजेक्ट कॉन्फ़िग आपको सभी आर्टिफैक्ट के लिए डिफ़ॉल्ट सेट करने और प्रोजेक्ट-विशिष्ट संदर्भ इंजेक्ट करने देता है।
कॉन्फ़िग बनाना
कॉन्फ़िग openspec init के दौरान बनता है, या मैन्युअली:
# 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 | object | प्रति-आर्टिफैक्ट नियम, आर्टिफैक्ट ID के अनुसार |
यह कैसे काम करता है
स्कीमा प्राथमिकता (उच्चतम से निम्नतम):
- CLI फ़्लैग (
--schema <name>) - परिवर्तन मेटाडेटा (परिवर्तन निर्देशिका में
.openspec.yaml) - प्रोजेक्ट कॉन्फ़िग (
openspec/config.yaml) - डिफ़ॉल्ट (
spec-driven)
संदर्भ इंजेक्शन:
- संदर्भ हर आर्टिफैक्ट के निर्देशों के आरंभ में जोड़ा जाता है
<context>...</context>टैग में लपेटा जाता है- AI को आपके प्रोजेक्ट की परंपराओं को समझने में मदद करता है
नियम इंजेक्शन:
- नियम केवल मेल खाने वाले आर्टिफैक्ट के लिए इंजेक्ट किए जाते हैं
<rules>...</rules>टैग में लपेटे जाते हैं- संदर्भ के बाद, टेम्पलेट से पहले दिखाई देते हैं
स्कीमा के अनुसार आर्टिफैक्ट IDs
spec-driven (डिफ़ॉल्ट):
proposal— परिवर्तन प्रस्तावspecs— विशिष्टताएँdesign— तकनीकी डिज़ाइनtasks— कार्यान्वयन कार्य
कॉन्फ़िग मान्यता
rulesमें अज्ञात आर्टिफैक्ट IDs चेतावनियाँ उत्पन्न करते हैं- स्कीमा नाम उपलब्ध स्कीमाओं के विरुद्ध मान्य होते हैं
- संदर्भ की 50KB आकार सीमा है
- अमान्य YAML लाइन नंबरों के साथ सूचित किया जाता है
समस्या निवारण
"rules में अज्ञात आर्टिफैक्ट ID: X"
- जाँचें कि आर्टिफैक्ट IDs आपके स्कीमा से मेल खाते हैं (ऊपर सूची देखें)
- प्रत्येक स्कीमा के आर्टिफैक्ट IDs देखने के लिए
openspec schemas --jsonचलाएँ
कॉन्फ़िग लागू नहीं हो रहा:
- सुनिश्चित करें कि फ़ाइल
openspec/config.yamlपर है (.ymlनहीं) - किसी वैलिडेटर से YAML सिंटैक्स जाँचें
- कॉन्फ़िग परिवर्तन तुरंत प्रभावी होते हैं (पुनरारंभ की आवश्यकता नहीं)
संदर्भ बहुत बड़ा:
- संदर्भ 50KB तक सीमित है
- इसके बजाय सारांश बनाएँ या बाहरी दस्तावेज़ से लिंक करें
कमांड
| कमांड | यह क्या करता है |
|---|---|
/opsx:propose | एक चरण में परिवर्तन बनाएँ और योजना आर्टिफैक्ट उत्पन्न करें (डिफ़ॉल्ट त्वरित पथ) |
/opsx:explore | विचारों पर विचार करें, समस्याओं की जाँच करें, आवश्यकताओं को स्पष्ट करें |
/opsx:new | नया परिवर्तन स्कैफोल्ड शुरू करें (विस्तारित कार्यप्रवाह) |
/opsx:continue | अगला आर्टिफैक्ट बनाएँ (विस्तारित कार्यप्रवाह) |
/opsx:ff | योजना आर्टिफैक्ट तेज़ी से बनाएँ (विस्तारित कार्यप्रवाह) |
/opsx:apply | कार्य कार्यान्वित करें, आवश्यकतानुसार आर्टिफैक्ट अद्यतन करें |
/opsx:update | किसी परिवर्तन की योजना आर्टिफैक्ट को संशोधित करें और उन्हें सुसंगत रखें |
/opsx:verify | कार्यान्वयन को आर्टिफैक्ट के विरुद्ध मान्य करें (विस्तारित कार्यप्रवाह) |
/opsx:sync | डेल्टा स्पेक्स को मुख्य स्पेक्स में मर्ज करें (वैकल्पिक) |
/opsx:archive | समाप्त होने पर संग्रहित करें |
/opsx:bulk-archive | एकाधिक पूर्ण परिवर्तनों को संग्रहित करें (विस्तारित कार्यप्रवाह) |
/opsx:onboard | एक संपूर्ण परिवर्तन का निर्देशित पूर्वाभ्यास (विस्तारित कार्यप्रवाह) |
उपयोग
एक विचार का अन्वेषण करें
/opsx:exploreविचारों पर विचार करें, समस्याओं की जाँच करें, विकल्पों की तुलना करें। किसी संरचना की आवश्यकता नहीं - बस एक विचार-साथी। जब अंतर्दृष्टि स्पष्ट हो जाए, /opsx:propose (डिफ़ॉल्ट) या /opsx:new//opsx:ff (विस्तारित) पर जाएँ।
नया परिवर्तन शुरू करें
/opsx:proposeपरिवर्तन बनाता है और कार्यान्वयन से पहले आवश्यक योजना आर्टिफैक्ट उत्पन्न करता है।
यदि आपने विस्तारित वर्कफ़्लो सक्षम किए हैं, तो आप इसके बजाय उपयोग कर सकते हैं:
/opsx:new # केवल स्कैफोल्ड
/opsx:continue # एक बार में एक आर्टिफैक्ट बनाएँ
/opsx:ff # सभी योजना आर्टिफैक्ट एक साथ बनाएँआर्टिफैक्ट बनाएँ
/opsx:continueनिर्भरताओं के आधार पर दिखाता है कि क्या बनाने के लिए तैयार है, फिर एक आर्टिफैक्ट बनाता है। अपने परिवर्तन को क्रमिक रूप से बनाने के लिए बार-बार उपयोग करें।
/opsx:ff add-dark-modeएक ही बार में सभी योजना आर्टिफैक्ट बनाता है। जब आपको स्पष्ट चित्र हो कि आप क्या बना रहे हैं तब उपयोग करें।
कार्यान्वयन (तरल भाग)
/opsx:applyकार्यों पर काम करता है, उन्हें चेक करता जाता है। यदि आप एक से अधिक परिवर्तनों पर काम कर रहे हैं, तो /opsx:apply <name> चला सकते हैं; अन्यथा इसे बातचीत से अनुमान लगाना चाहिए और पूछेगा अगर पता न लगा सके।
परिवर्तन अद्यतन करना
/opsx:update add-dark-mode - अब हम थीम को कुकी में संग्रहीत कर रहे हैंमौजूदा योजना आर्टिफैक्ट को संशोधित करता है और उन्हें सुसंगत रखता है — किसी भी दिशा में (डिज़ाइन संपादन प्रस्ताव तक वापस जा सकता है)। केवल योजना आर्टिफैक्ट: यह कभी कोड संपादित नहीं करता, और कभी गायब आर्टिफैक्ट नहीं बनाता (वह /opsx:continue है)। प्रत्येक संपादन पहले आपके साथ पुष्ट होता है। यदि परिवर्तन पहले ही लागू हो चुका था, तो यह /opsx:apply की अनुशंसा करता है ताकि कोड संशोधित योजना के साथ अद्यतित हो सके। यदि आपका संशोधन परिवर्तन के इरादे को बदलता है, तो इसके बजाय नए सिरे से शुरू करें — देखें कब अपडेट करें बनाम नए सिरे से शुरू करें।
डेल्टा स्पेक्स सिंक करें
/opsx:syncवर्तमान परिवर्तन की डेल्टा स्पेक्स को आपकी मुख्य openspec/specs/ में बिना संग्रहित किए मर्ज करता है — परिवर्तन सक्रिय रहता है। यह पूरा डेल्टा लागू करता है: ## REMOVED के अंतर्गत एक आवश्यकता मुख्य स्पेक्स से हटा दी जाती है और पुनर्नामित आवश्यकता को जगह-पर-बदला जाता है, जबकि डेल्टा में शामिल न की गई सामग्री अछूती रहती है। सिंकिंग वैकल्पिक है — संग्रह करने पर पहले सिंक करने का संकेत देता है यदि नहीं किया है। इसका सहारा लें जब आप चाहते हैं कि मुख्य स्पेक्स संग्रहण से पहले अद्यतित हों, जब एक समानांतर परिवर्तन को इस परिवर्तन द्वारा जोड़े गए स्पेक्स पर निर्माण करना हो, या जब आप संग्रहण से पहले मिली हुई मुख्य स्पेक्स की समीक्षा करना चाहते हैं।
समाप्ति
/opsx:archive # समाप्त होने पर संग्रह में ले जाएँ (जरूरत होने पर स्पेक्स सिंक करने का संकेत देता है)कब अपडेट करें बनाम नए सिरे से शुरू करें
आप कार्यान्वयन से पहले हमेशा अपना प्रस्ताव या स्पेक्स संपादित कर सकते हैं। लेकिन कब परिष्करण "यह अलग काम है" बन जाता है?
प्रस्ताव क्या दर्शाता है
एक प्रस्ताव तीन चीजें परिभाषित करता है:
- इरादा — आप कौन सी समस्या हल कर रहे हैं?
- दायरा — क्या अंदर/बाहर है?
- दृष्टिकोण — आप इसे कैसे हल करेंगे?
सवाल है: क्या बदला, और कितना?
मौजूदा परिवर्तन को अपडेट करें जब:
समान इरादा, परिष्कृत निष्पादन
- आपको ऐसे एज केस मिले जिन पर आपने विचार नहीं किया था
- दृष्टिकोण में बदलाव की जरूरत है लेकिन लक्ष्य अपरिवर्तित है
- कार्यान्वयन से पता चला कि डिज़ाइन थोड़ा गलत था
दायरा संकुचित होता है
- आपको पता चला कि पूरा दायरा बहुत बड़ा है, पहले MVP भेजना चाहते हैं
- "डार्क मोड जोड़ें" → "डार्क मोड टॉगल जोड़ें (v2 में सिस्टम प्राथमिकता)"
अधिगम-आधारित सुधार
- कोडबेस वैसा संरचित नहीं है जैसा आपने सोचा था
- कोई निर्भरता अपेक्षित रूप से काम नहीं करती
- "CSS वेरिएबल का उपयोग करें" → "Tailwind के dark: प्रीफ़िक्स का उपयोग करें"
नया परिवर्तन शुरू करें जब:
इरादा मौलिक रूप से बदल गया
- समस्या ही अब अलग है
- "डार्क मोड जोड़ें" → "कस्टम रंगों, फ़ॉन्ट्स, स्पेसिंग के साथ व्यापक थीम प्रणाली जोड़ें"
दायरा फट गया
- परिवर्तन इतना बढ़ गया कि मूलतः अलग काम है
- अपडेट के बाद मूल प्रस्ताव पहचाना नहीं जाएगा
- "लॉगिन बग ठीक करें" → "ऑथ प्रणाली पुनर्लेखन"
मूल पूरा किया जा सकता है
- मूल परिवर्तन को "पूर्ण" चिन्हित किया जा सकता है
- नया काम स्वतंत्र रूप से खड़ा हो, परिष्करण नहीं
- "डार्क मोड MVP" पूर्ण करें → संग्रहित करें → नया परिवर्तन "डार्क मोड बढ़ाएँ"
नियमावली
┌─────────────────────────────────────┐
│ क्या यह वही काम है? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
समान इरादा? >50% ओवरलैप? क्या मूल
समान समस्या? समान दायरा? 'पूर्ण' हो सकता
│ │ इन परिवर्तनों
│ │ के बिना?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
अपडेट नया अपडेट नया अपडेट नया| परीक्षण | अपडेट | नया परिवर्तन |
|---|---|---|
| पहचान | "वही चीज़, परिष्कृत" | "अलग काम" |
| दायरा ओवरलैप | >50% ओवरलैप | <50% ओवरलैप |
| समापन | परिवर्तनों के बिना "पूर्ण" नहीं हो सकता | मूल खत्म कर सकते हैं, नया काम स्वतंत्र |
| कहानी | अपडेट श्रृंखला सुसंगत कहानी बताती है | पैच भ्रमित करेंगे बजाय स्पष्ट करने के |
सिद्धांत
अपडेट संदर्भ सुरक्षित रखता है। नया परिवर्तन स्पष्टता प्रदान करता है।
अपडेट चुनें जब आपकी सोच का इतिहास मूल्यवान हो। नया चुनें जब साफ शुरुआत करना पैबंदी से बेहतर हो।
इसके बारे में git ब्रांचों की तरह सोचें:
- एक ही फीचर पर काम करते हुए कमिट करते रहें
- जब सचमुच नया काम हो तो नई ब्रांच शुरू करें
- कभी-कभी आंशिक फीचर को मर्ज करें और चरण 2 के लिए साफ शुरुआत करें
क्या अलग है?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Structure | एक बड़ा प्रस्ताव दस्तावेज़ | निर्भरताओं के साथ अलग-अलग आर्टिफैक्ट्स |
| Workflow | रैखिक चरण: plan → implement → archive | प्रवाही कार्रवाई — कभी भी कुछ भी करें |
| Iteration | वापस जाना कठिन | सीखते हुए आर्टिफैक्ट्स अपडेट करें |
| Customization | निश्चित संरचना | Schema-driven (अपने आर्टिफैक्ट्स परिभाषित करें) |
मुख्य अंतर्दृष्टि: कार्य रैखिक नहीं होते। OPSX इसका दिखावा बंद कर देता है।
आर्किटेक्चर डीप डाइव
यह अनुभाग बताता है कि OPSX अंदर से कैसे काम करता है और विरासत (legacy) वर्कफ़्लो से इसकी तुलना कैसे होती है। इस अनुभाग के उदाहरण विस्तृत कमांड सेट (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 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘घटक आर्किटेक्चर
पुराना (Legacy) वर्कफ़्लो 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, Devin) │
│ • 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सूचना प्रवाह
पुराना (Legacy) वर्कफ़्लो — एजेंट स्थिर निर्देश प्राप्त करता है:
User: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Static instructions: │
│ • Create proposal.md │
│ • Create tasks.md │
│ • Create design.md │
│ • Create delta spec files │
│ │
│ 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", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ 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 │
└──────────────────────────────────────────────────────────────────────────┘पुनरावृत्ति मॉडल
पुराना (Legacy) वर्कफ़्लो — पुनरावृत्ति करना बोझिल है:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/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कस्टम स्कीमा
स्कीमा प्रबंधन कमांड का उपयोग करके कस्टम वर्कफ़्लो बनाएँ:
# 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:
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सारांश
| पहलू | Legacy | OPSX |
|---|---|---|
| टेम्प्लेट | हार्डकोडेड TypeScript | बाहरी YAML + Markdown |
| डिपेंडेंसी | कोई नहीं (एक साथ सब) | Topological सॉर्ट के साथ DAG |
| स्थिति | चरण-आधारित मानसिक मॉडल | फाइलसिस्टम अस्तित्व |
| अनुकूलन | स्रोत संपादित करें, पुनर्निर्माण करें | schema.yaml बनाएँ |
| पुनरावृत्ति | चरण-लॉक किया हुआ | तरल, कुछ भी संपादित करें |
| संपादक समर्थन | टूल-विशिष्ट कॉन्फ़िगरेटर/एडैप्टर | एकल स्किल्स निर्देशिका |
स्कीमा
स्कीमा यह परिभाषित करती हैं कि कौन से आर्टिफैक्ट मौजूद हैं और उनकी निर्भरताएँ। वर्तमान में उपलब्ध:
- spec-driven (डिफ़ॉल्ट): प्रस्ताव → स्पेक्स → डिज़ाइन → कार्य
# उपलब्ध स्कीमा की सूची बनाएं
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 पर एक मुद्दा खोलें।