OPSX Workflow

फीडबैक डिस्कॉर्ड पर स्वागत है।

यह क्या है?

OPSX अब OpenSpec के लिए मानक वर्कफ़्लो है। यह OpenSpec परिवर्तनों के लिए एक तरल, पुनरावृत्त वर्कफ़्लो है। अब कठोर चरणों की जरूरत नहीं — बस ऐसे कार्य जिन्हें आप किसी भी समय कर सकते हैं।

यह क्यों मौजूद है

पुराना OpenSpec वर्कफ्लो काम करता है, लेकिन यह लॉक्ड है:

• निर्देश हार्डकोडेड हैं — TypeScript में दबे हुए, आप उन्हें बदल नहीं सकते
• सब कुछ या कुछ नहीं — एक बड़ा कमांड सब कुछ बनाता है, अलग-अलग हिस्सों का परीक्षण नहीं कर सकते
• स्थिर संरचना — सभी के लिए समान वर्कफ्लो, कोई कस्टमाइजेशन नहीं
• ब्लैक बॉक्स — जब AI आउटपुट खराब होता है, आप प्रॉम्प्ट्स को एडजस्ट नहीं कर सकते

OPSX इसे खोल देता है। अब कोई भी कर सकता है:

1. निर्देशों के साथ प्रयोग करें — टेम्पलेट संपादित करें, देखें कि AI बेहतर काम करता है या नहीं
2. सूक्ष्म रूप से परीक्षण करें — प्रत्येक आर्टिफैक्ट के निर्देशों को स्वतंत्र रूप से वैलिडेट करें
3. वर्कफ्लो को कस्टमाइज़ करें — अपने स्वयं के आर्टिफैक्ट और डिपेंडेंसीज़ परिभाषित करें
4. जल्दी से इटरेट करें — टेम्पलेट बदलें, तुरंत परीक्षण करें, कोई रीबिल्ड नहीं

पुराना वर्कफ्लो:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  पैकेज में हार्डकोडेड  │           │  schema.yaml           │◄── आप इसे संपादित करते हैं
│  (बदल नहीं सकते)        │           │  templates/*.md        │◄── या इसे
│        ↓               │           │        ↓               │
│  नया रिलीज का इंतज़ार   │           │  तात्कालिक प्रभाव       │
│        ↓               │           │        ↓               │
│  उम्मीद है कि बेहतर होगा│           │  स्वयं परीक्षण करें     │
└────────────────────────┘           └────────────────────────┘

यह सभी के लिए है:

• टीम्स — वह वर्कफ्लो बनाएं जो आपके वास्तविक काम के अनुसार हो
• पावर यूजर्स — अपने कोडबेस के लिए बेहतर AI आउटपुट प्राप्त करने के लिए प्रॉम्प्ट्स को एडजस्ट करें
• OpenSpec कंट्रिब्यूटर्स — रिलीज के बिना नए दृष्टिकोणों के साथ प्रयोग करें

हम सभी अभी भी सीख रहे हैं कि क्या सबसे अच्छा काम करता है। OPSX हमें एक साथ सीखने की अनुमति देता है।

उपयोगकर्ता अनुभव

रैखिक वर्कफ्लो की समस्या: आप "प्लानिंग फेज" में होते हैं, फिर "इंप्लीमेंटेशन फेज" में, फिर "डोन"। लेकिन वास्तविक काम इस तरह नहीं होता है। आप कुछ इंप्लीमेंट करते हैं, महसूस करते हैं कि आपका डिजाइन गलत था, स्पेक्स अपडेट करने की जरूरत है, इंप्लीमेंटेशन जारी रखें। रैखिक फेज वास्तविक काम के होने के तरीके के खिलाफ लड़ते हैं।

OPSX दृष्टिकोण:

• फेज नहीं, एक्शन — बनाएं, इंप्लीमेंट करें, अपडेट करें, आर्काइव करें — किसी भी समय इनमें से कोई भी करें
• डिपेंडेंसीज़ एनेबलर्स हैं — वे दिखाते हैं कि क्या संभव है, न कि अगले में क्या आवश्यक है

  proposal ──→ specs ──→ design ──→ tasks ──→ implement

सेटअप

# सुनिश्चित करें कि आपके पास 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 के दौरान बनाई जाती है, या मैन्युअली:

# 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	आर्टिफैक्ट ID के आधार पर व्यवस्थित प्रति-आर्टिफैक्ट नियम

यह कैसे काम करता है

स्कीमा प्राथमिकता (उच्च से निम्न):

1. CLI फ्लैग (--schema <name>)
2. चेंज मेटाडेटा (चेंज डिरेक्ट्री में .openspec.yaml)
3. प्रोजेक्ट कॉन्फ़िग (openspec/config.yaml)
4. डिफॉल्ट (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 - we're storing the theme in a cookie now

चेंज के मौजूदा प्लानिंग आर्टिफैक्ट्स को संशोधित करता है और उन्हें किसी भी दिशा में सुसंगत रखता है - (डिजाइन एडिट प्रोपोज़ल में वापस रिपल हो सकता है)। केवल प्लानिंग आर्टिफैक्ट्स: यह कभी कोड संपादित नहीं करता, और यह कभी गुम आर्टिफैक्ट्स नहीं बनाता (यह /opsx:continue है)। हर एडिट को पहले आपके साथ कन्फर्म करता है। यदि चेंज पहले ही इंप्लीमेंट की जा चुकी हो, तो यह /opsx:apply की सिफारिश करता है ताकि कोड संशोधित योजना के साथ कैच अप हो जाए। यदि आपका संशोधन चेंज के इंटेंट को बदलता है, तो इसके बजाय नया शुरू करें - देखें अपडेट बनाम नया शुरू करने के लिए.

समाप्त करें

/opsx:archive   # समाप्त होने पर आर्काइव में ले जाएं (जरूरत पड़ने पर स्पेक्स सिंक करने के लिए प्रॉम्प्ट करता है)

अपडेट बनाम नया शुरू करने का समय

आप हमेशा इंप्लीमेंटेशन से पहले अपने प्रोपोज़ल या स्पेक्स संपादित कर सकते हैं। लेकिन रिफाइनिंग कब "यह अलग काम है" बन जाती है?

एक प्रोपोज़ल क्या कैप्चर करता है

एक प्रोपोज़ल तीन चीजें परिभाषित करता है:

1. इंटेंट — आप किस समस्या को हल कर रहे हैं?
2. स्कोप — सीमाओं में/बाहर क्या है?
3. एप्रोच — आप इसे कैसे हल करेंगे?

सवाल है: क्या बदला, और कितना बदला?

जब मौजूदा चेंज अपडेट करें:

समान इंटेंट, रिफाइंड एक्सीक्यूशन

• आप उन एज केसों की खोज करते हैं जिन्हें आपने नहीं सोचा था
• एप्रोच को एडजस्ट करने की जरूरत है लेकिन लक्ष्य अपरिवर्तित है
• इंप्लीमेंटेशन दिखाता है कि डिजाइन थोड़ा गलत था

स्कोप संकुचित होता है

• आप महसूस करते हैं कि पूरा स्कोप बहुत बड़ा है, पहले MVP शिप करना चाहते हैं
• "डार्क मोड जोड़ें" → "डार्क मोड टॉगल जोड़ें (v2 में सिस्टम प्रिफरेंस)"

सीखने-आधारित सुधार

• कोडबेस उस तरह से संरचित नहीं है जैसे आपने सोचा था
• एक डिपेंडेंसी अपेक्षित रूप से काम नहीं करती
• "CSS वेरिएबल का उपयोग करें" → "इसके बजाय Tailwind के dark: प्रिफिक्स का उपयोग करें"

नई चेंज शुरू करने के लिए:

इंटेंट मूल रूप से बदल गया

• समस्या स्वयं अब अलग है
• "डार्क मोड जोड़ें" → "कस्टम रंग, फॉन्ट, स्पेसिंग के साथ व्यापक थीम सिस्टम जोड़ें"

स्कोप बहुत बढ़ गया

• चेंज इतनी बढ़ गई कि यह मूल रूप से अलग काम है
• अपडेट के बाद मूल प्रोपोज़ल को पहचाना नहीं जा सकेगा
• "लॉगिन बग फिक्स करें" → "ऑथ सिस्टम रिराइट करें"

मूल पूर्ण करने योग्य है

• मूल चेंज को "डोन" मार्क किया जा सकता है
• नया काम अलग खड़ा है, कोई रिफाइनमेंट नहीं
• ""डार्क मोड MVP जोड़ें" को पूरा करें → आर्काइव → नई चेंज "डार्क मोड एन्हांस करें""

ह्यूरिस्टिक्स

                        ┌─────────────────────────────────────┐
                        │     Is this the same work?          │
                        └──────────────┬──────────────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             Same intent?      >50% overlap?      Can original
             Same problem?     Same scope?        be "done" without
                    │                  │          these changes?
                    │                  │                  │
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         YES               NO YES           NO  NO              YES
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       UPDATE            NEW  UPDATE       NEW  UPDATE          NEW

परीक्षण	अपडेट	नई चेंज
पहचान	"समान चीज, रिफाइंड"	"अलग काम"
स्कोप ओवरलैप	>50% ओवरलैप	<50% ओवरलैप
पूर्णता	परिवर्तनों के बिना "डोन" नहीं किया जा सकता	मूल को पूरा कर सकते हैं, नया काम अलग खड़ा है
कहानी	अपडेट चेन सुसंगत कहानी बताती है	पैचेस को स्पष्ट करने से ज्यादा भ्रमित करेंगे

सिद्धांत

अपडेट संदर्भ को बचाता है। नई चेंज स्पष्टता प्रदान करती है।

जब आपके सोचने का इतिहास मूल्यवान हो तो अपडेट चुनें। जब नया शुरू करना पैचिंग से ज्यादा स्पष्ट हो तो नया चुनें।

इसे गिट ब्रांच की तरह सोचें:

• समान फीचर पर काम करते समय कमिट करता रहें
• जब यह वास्तव में नया काम हो तो नई ब्रांच शुरू करें
• कभी-कभी आंशिक फीचर को मर्ज करें और फेज 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                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

घटक आर्किटेक्चर

Legacy workflow uses hardcoded templates in 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 uses external schemas and a dependency graph engine:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         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                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

निर्भरता ग्राफ मॉडल

Artifacts form a directed acyclic graph (DAG). Dependencies are enablers, not gates:

                              proposal
                             (root node)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 specs                       design
              (requires:                  (requires:
               proposal)                   proposal)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               tasks
                           (requires:
                           specs, design)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ APPLY PHASE  │
                          │ (requires:   │
                          │  tasks)      │
                          └──────────────┘

State transitions:

   BLOCKED ────────────────► READY ────────────────► DONE
      │                        │                       │
   Missing                  All deps               File exists
   dependencies             are DONE               on filesystem

सूचना प्रवाह

Legacy workflow — agent receives static instructions:

  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 go

OPSX — agent queries for rich context:

  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  │
  └──────────────────────────────────────────────────────────────────────────┘

पुनरावृत्ति मॉडल

Legacy workflow — awkward to iterate:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "डिज़ाइन गलत है"
       │               │
       │               ├── विकल्प:
       │               │   • फाइलों को मैन्युअली संपादित करें (कॉन्टेक्स्ट टूट जाता है)
       │               │   • छोड़ दें और नया शुरू करें
       │               │   • आगे बढ़ें और बाद में ठीक करें
       │               │
       │               └── कोई आधिकारिक "वापस जाएं" तंत्र नहीं है
       │
       └── एक बार में सभी आर्टिफैक्ट्स बनाता है

OPSX — स्वाभाविक इटरेशन:

  /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
      │                │                  │
      │                │                  ├── "डिज़ाइन गलत है"
      │                │                  │
      │                │                  ▼
      │                │            बस design.md को संपादित करें
      │                │            और जारी रखें!
      │                │                  │
      │                │                  ▼
      │                │         /opsx:apply आपके छोड़े हुए स्थान से
      │                │         फिर से शुरू करता है
      │                │
      │                └── एक ही आर्टिफैक्ट बनाता है, जो अनलॉक क्या है दिखाता है
      │
      └── बदलाव का स्कैफोल्ड बनाता है, निर्देश के लिए इंतज़ार करता है

कस्टम स्कीमा

स्कीमा प्रबंधन कमांड का उपयोग करके कस्टम वर्कफ़्लो बनाएं:

# नया स्कीमा शून्य से बनाएं (इंटरैक्टिव)
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:

name: research-first
artifacts:
  - id: research        # प्रॉपोज़ल से पहले जोड़ा गया
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # अब रिसर्च पर निर्भर करता है

  - id: tasks
    generates: tasks.md
    requires: [proposal]

निर्भरता ग्राफ:

   research ──► proposal ──► tasks

Summary

पहलू	लेगेसी	OPSX
टेम्पलेट्स	हार्डकोडेड TypeScript	बाहरी YAML + मार्कडाउन
निर्भरताएं	कोई नहीं (सभी एक बार में)	टोपोलॉजिकल सॉर्ट के साथ DAG
स्टेट	फेज-आधारित मेन्टल मॉडल	फाइलसिस्टम अस्तित्व
कस्टमाइज़ेशन	सोर्स संपादित करें, रीबिल्ड करें	schema.yaml बनाएं
इटरेशन	फेज-लॉक्ड	फ्लूइड, किसी भी चीज़ को संपादित करें
एडिटर सपोर्ट	टूल-स्पेसिफिक कॉन्फ़िग्यूरेटर/एडेप्टर	सिंगल स्किल्स डिरेक्ट्री

Schemas

स्कीमा यह परिभाषित करती हैं कि कौन से आर्टिफैक्ट मौजूद हैं और उनकी निर्भरताएं क्या हैं। वर्तमान में उपलब्ध:

• spec-driven (डिफॉल्ट): proposal → specs → design → tasks

# उपलब्ध स्कीमाओं की सूची बनाएं
openspec schemas

# सभी स्कीमाओं को उनके रिज़ॉल्यूशन सोर्स के साथ देखें
openspec schema which --all

# नई स्कीमा को इंटरैक्टिव तरीके से बनाएं
openspec schema init my-workflow

# कस्टमाइज़ेशन के लिए मौजूदा स्कीमा को फोर्क करें
openspec schema fork spec-driven my-workflow

# उपयोग करने से पहले स्कीमा संरचना को वैलिडेट करें
openspec schema validate my-workflow

Tips

• किसी बदलाव के लिए कमिट करने से पहले किसी आइडिया पर विचार करने के लिए /opsx:explore का उपयोग करें
• जब आप जानते हैं कि आप क्या चाहते हैं तो /opsx:ff, जब एक्सप्लोर कर रहे हों तो /opsx:continue
• /opsx:apply के दौरान, यदि कुछ गलत है — तो आर्टिफैक्ट को ठीक करें, फिर जारी रखें
• टास्क tasks.md में चेकबॉक्स के माध्यम से प्रोग्रेस ट्रैक करते हैं
• किसी भी समय स्टेटस जांचें: openspec status --change "name"

Feedback

यह प्रारूप अभी कच्चा है। यह जानबूझकर किया गया है — हम यह सीख रहे हैं कि क्या काम करता है।

बग मिला? कोई आइडिया है? हमारे साथ डिस्कॉर्ड पर जुड़ें या गिटहब पर कोई इश्यू खोलें।