OPSX पर माइग्रेट करना

यह गाइड आपको पुराने OpenSpec वर्कफ़्लो से OPSX पर स्विच करने में मदद करता है। माइग्रेशन को सहज डिज़ाइन किया गया है—आपका मौजूदा काम सुरक्षित रहता है, और नया सिस्टम अधिक लचीलापन प्रदान करता है।

क्या बदल रहा है?

OPSX पुराने फेज-लॉक्ड वर्कफ़्लो को एक तरल, एक्शन-आधारित दृष्टिकोण से बदल देता है। यहाँ मुख्य बदलाव है:

पहलू	पुराना सिस्टम	OPSX
कमांड	`/openspec:proposal`, `/openspec:apply`, `/openspec:archive`	डिफॉल्ट: `/opsx:propose`, `/opsx:apply`, `/opsx:sync`, `/opsx:archive` (विस्तारित वर्कफ़्लो कमांड वैकल्पिक हैं)
वर्कफ़्लो	सभी आर्टिफैक्ट एक बार में बनाएं	चरणबद्ध तरीके से या सभी एक बार में बनाएं—आपकी पसंद है
वापस जाना	अजीब फेज गेट्स	स्वाभाविक—किसी भी आर्टिफैक्ट को किसी भी समय अपडेट करें
कस्टमाइज़ेशन	स्थिर संरचना	स्कीमा-आधारित, पूरी तरह से हैक करने योग्य
कॉन्फ़िगरेशन	मार्कर वाला `CLAUDE.md` + `project.md`	`openspec/config.yaml` में साफ कॉन्फ़िगरेशन

दर्शन परिवर्तन: काम रैखिक नहीं होता है। OPSX इसे ऐसा दिखाना बंद कर देता है।

शुरू करने से पहले

आपका मौजूदा काम सुरक्षित है

स्थानांतरण प्रक्रिया को संरक्षण के मन में डिज़ाइन किया गया है:

openspec/changes/ में सक्रिय परिवर्तन — पूरी तरह से संरक्षित। आप OPSX कमांड के साथ उन्हें जारी रख सकते हैं।
आर्काइव किए गए परिवर्तन — बिल्कुल बरकरार। आपका इतिहास अखंड रहता है।
openspec/specs/ में मुख्य स्पेक्स — बिल्कुल बरकरार। ये आपकी सत्यता के स्रोत हैं।
CLAUDE.md, AGENTS.md आदि में आपका सामग्री — संरक्षित। केवल OpenSpec मार्कर ब्लॉक हटा दिए जाते हैं; आपके लिखे हुए सब कुछ बरकरार रहता है।

क्या हटा दिया जाता है

केवल वे OpenSpec-प्रबंधित फाइलें जो बदली जा रही हैं:

क्या	क्यों
पुराने स्लैश कमांड डिरेक्ट्री/फाइलें	नई स्किल्स सिस्टम द्वारा बदली गई
`openspec/AGENTS.md`	अप्रचलित वर्कफ्लो ट्रिगर
`CLAUDE.md`, `AGENTS.md` आदि में OpenSpec मार्कर	अब जरूरी नहीं

टूल के अनुसार पुराने कमांड स्थान (उदाहरण—आपका टूल भिन्न हो सकता है):

Claude Code: .claude/commands/openspec/
Cursor: .cursor/commands/openspec-*.md
Windsurf: .windsurf/workflows/openspec-*.md
Cline: .cinerules/workflows/openspec-*.md
Roo: .roo/commands/openspec-*.md
GitHub Copilot: .github/prompts/openspec-*.prompt.md (केवल IDE एक्सटेंशन के लिए; Copilot CLI में समर्थित नहीं)
Codex: OpenSpec अब .codex/skills/openspec-* का उपयोग करता है; पुरानी सफाई केवल OpenSpec की अनुमोदित सूची में दिए गए Codex प्रॉम्प्ट फाइलनाम को $CODEX_HOME/prompts या ~/.codex/prompts में लक्षित करती है, और उन्हें केवल बदलाव .codex/skills/openspec-* स्किल्स मौजूद होने पर ही हटाती है।
और अन्य (Augment, Continue, Amazon Q, आदि)

स्थानांतरण आपके द्वारा कॉन्फ़िगर किए गए किसी भी टूल का पता लगाता है और उनके पुराने फाइलों को साफ करता है।

हटाने की सूची लंबी लग सकती है, लेकिन ये सभी फाइलें हैं जिन्हें OpenSpec ने मूल रूप से बनाया था। आपका अपना सामग्री कभी भी हटाया नहीं जाता।

आपका ध्यान किस चीज़ पर जरूरी है

एक फाइल को मैन्युअल रूप से स्थानांतरित करने की जरूरत है:

openspec/project.md — यह फाइल स्वतः हटाई नहीं जाती क्योंकि इसमें आपके द्वारा लिखा गया प्रोजेक्ट संदर्भ हो सकता है। आपको यह करने की जरूरत होगी:

इसकी सामग्री की समीक्षा करें
उपयोगी संदर्भ को openspec/config.yaml में स्थानांतरित करें (नीचे दिए गए मार्गदर्शन देखें)
तैयार होने पर फाइल को हटा दें

हमने यह बदलाव क्यों किया:

पुराना project.md निष्क्रिय था—एजेंट इसे पढ़ सकते थे, नहीं भी पढ़ सकते थे, या जो पढ़ा उसे भूल सकते थे। हमने पाया कि विश्वसनीयता असंगत थी।

नया config.yaml संदर्भ सक्रिय रूप से हर OpenSpec प्लानिंग अनुरोध में इंजेक्ट किया जाता है। इसका मतलब है कि जब AI आर्टिफैक्ट बना रहा हो तो आपके प्रोजेक्ट परंपराएं, टेक स्टैक और नियम हमेशा मौजूद रहेंगे। अधिक विश्वसनीयता।

समझौता:

चूंकि संदर्भ को हर अनुरोध में इंजेक्ट किया जाता है, इसलिए आप संक्षिप्त रहना चाहेंगे। उस पर ध्यान दें जो वास्तव में मायने का है:

टेक स्टैक और मुख्य परंपराएं
गैर-स्पष्ट बाधाएं जिन्हें AI को जानने की जरूरत है
नियम जो पहले अक्सर नज़रअंदाज किए जाते थे

इसे पूर्ण बनाने की चिंता न करें। हम अभी भी यहां क्या सबसे अच्छा काम करता है उस को सीख रहे हैं, और जैसे हम प्रयोग करेंगे वैसे ही संदर्भ इंजेक्शन को काम करने के तरीके को सुधारते रहेंगे।

स्थानांतरण चलाना

दोनों openspec init और openspec update पुरानी फाइलों का पता लगाते हैं और आपको उसी सफाई प्रक्रिया के माध्यम से मार्गदर्शन करते हैं। अपनी स्थिति के अनुसार जो भी उपयुक्त हो उसका उपयोग करें:

नई इंस्टॉल के लिए डिफ़ॉल्ट प्रोफाइल core (propose, explore, apply, sync, archive) होता है।
स्थानांतरित इंस्टॉल आपके पहले से इंस्टॉल किए गए वर्कफ्लो को जरूरत पड़ने पर custom प्रोफाइल लिखकर संरक्षित करती है।

`openspec init` का उपयोग करना

इसे तब चलाएं जब आप नए टूल जोड़ना चाहें या जिन टूल को सेट अप किया गया है उनकी पुनःकॉन्फ़िगरेशन करना चाहें:

bash

openspec init

इनिट कमांड पुरानी फाइलों का पता लगाता है और आपको सफाई के माध्यम से मार्गदर्शन करता है:

नए OpenSpec में अपग्रेड कर रहे हैं

OpenSpec अब एजेंट स्किल्स का उपयोग करता है, जो कोडिंग एजेंट्स में उभरती हुई मानक है। यह आपके सेटअप को सरल बनाता है जबकि पहले की तरह हर काम चलता रहता है।

हटाने के लिए फाइलें
संरक्षित करने के लिए कोई उपयोगकर्ता सामग्री नहीं:
  • .claude/commands/openspec/
  • openspec/AGENTS.md

अपडेट करने के लिए फाइलें
OpenSpec मार्कर हटा दिए जाएंगे, आपकी सामग्री संरक्षित रहेगी:
  • CLAUDE.md
  • AGENTS.md

आपका ध्यान जरूरी है
  • openspec/project.md
    हम यह फाइल हटाएंगे नहीं। इसमें उपयोगी प्रोजेक्ट संदर्भ हो सकता है।

    नया openspec/config.yaml प्लानिंग संदर्भ के लिए "context:" सेक्शन रखता है। यह हर OpenSpec अनुरोध में शामिल है और पुराने project.md तरीके की तुलना में अधिक विश्वसनीय रूप से काम करता है।

    project.md की समीक्षा करें, किसी भी उपयोगी सामग्री को config.yaml के context सेक्शन में स्थानांतरित करें, फिर तैयार होने पर फाइल को हटा दें।

? पुरानी फाइलों को अपग्रेड और साफ करें? (Y/n)

जब आप हां कहेंगे तो क्या होता है:

पुराने स्लैश कमांड डिरेक्ट्री हटा दी जाती है
CLAUDE.md, AGENTS.md आदि से OpenSpec मार्कर हटा दिए जाते हैं (आपकी सामग्री बरकरार रहती है)
openspec/AGENTS.md हटा दी जाती है
नई स्किल्स .claude/skills/ में इंस्टॉल की जाती है
openspec/config.yaml को डिफ़ॉल्ट स्कीमा के साथ बनाया जाता है

`openspec update` का उपयोग करना

इसे तब चलाएं जब आप बस अपने मौजूदा टूल को नवीनतम संस्करण में स्थानांतरित करना और रीफ्रेश करना चाहें:

bash

openspec update

अपडेट कमांड भी पुराने आर्टिफैक्ट का पता लगाता है और उन्हें साफ करता है, फिर जनरेट की गई स्किल्स/कमांड को आपके वर्तमान प्रोफाइल और डिलीवरी सेटिंग के अनुसार रीफ्रेश करता है।

नॉन-इंटरैक्टिव / CI परिवेश

स्क्रिप्टेड स्थानांतरण के लिए:

bash

openspec init --force --tools claude

--force फ्लैग प्रॉम्पट्स को छोड़ता है और स्वतः सफाई को स्वीकार कर लेता है।

यह में ग्लोबल Codex प्रॉम्प्ट डिरेक्ट्री में OpenSpec-प्रबंधित Codex प्रॉम्प्ट फाइलों की सफाई शामिल है। सफाई केवल OpenSpec की अनुमोदित सूची में दिए गए पुराने Codex प्रॉम्प्ट फाइलनाम को लक्षित करती है, उन्हें केवल बदलाव .codex/skills/openspec-* स्किल्स मौजूद होने पर ही हटाती है, और अन्य सभी फाइलों को संरक्षित रखती है।

project.md को config.yaml में स्थानांतरित करना

पुराना openspec/project.md प्रोजेक्ट संदर्भ के लिए एक फ्रीफॉर्म मार्कडाउन फाइल थी। नया openspec/config.yaml संरचित है और—महत्वपूर्ण बात यह है कि—हर प्लानिंग अनुरोध में इंजेक्ट किया जाता है ताकि जब AI काम करता हो तो आपकी परंपराएं हमेशा मौजूद रहें।

पहले (project.md)

markdown

# प्रोजेक्ट संदर्भ

यह React और Node.js का उपयोग करने वाला एक TypeScript मोनोरेपो है।
हम टेस्टिंग के लिए Jest का उपयोग करते हैं और कठोर ESLint नियमों का पालन करते हैं।
हमारा API RESTful है और docs/api.md में दस्तावेजित है।

## परंपराएं

- सभी पब्लिक API को बैकवर्ड कंपैटिबिलिटी बनाए रखनी चाहिए
- नई सुविधाओं में टेस्ट शामिल होने चाहिए
- स्पेसिफिकेशन के लिए Given/When/Then फॉर्मेट का उपयोग करें

बाद में (config.yaml)

yaml

schema: spec-driven

context: |
  टेक स्टैक: TypeScript, React, Node.js
  टेस्टिंग: Jest with React Testing Library
  API: RESTful, docs/api.md में दस्तावेजित
  हम सभी पब्लिक API के लिए बैकवर्ड कंपैटिबिलिटी बनाए रखते हैं

rules:
  proposal:
    - जोखिमपूर्ण परिवर्तनों के लिए रोलबैक प्लान शामिल करें
  specs:
    - सिनारियो के लिए Given/When/Then फॉर्मेट का उपयोग करें
    - नई पैटर्न बनाने से पहले मौजूदा पैटर्न का संदर्भ लें
  design:
    - जटिल फ्लो के लिए सीक्वेंस डायग्राम शामिल करें

मुख्य अंतर

project.md	config.yaml
फ्रीफॉर्म मार्कडाउन	संरचित YAML
टेक्स्ट का एक बड़ा ब्लॉब	अलग-अलग संदर्भ और प्रति-आर्टिफैक्ट नियम
अस्पष्ट कब उपयोग किया जाता है	संदर्भ सभी आर्टिफैक्ट में दिखाई देता है; नियम केवल मिलते-जुलते आर्टिफैक्ट में दिखाई देते हैं
कोई स्कीमा चयन नहीं	स्पष्ट `schema:` फ़ील्ड डिफ़ॉल्ट वर्कफ्लो सेट करता है

क्या रखें, क्या हटा दें

स्थानांतरण करते समय, चयनात्मक रहें। अपने आप से पूछें: "क्या AI को हर प्लानिंग अनुरोध के लिए इसकी जरूरत है?"

context: के लिए अच्छे उम्मीदवार

टेक स्टैक (भाषाएं, फ्रेमवर्क, डेटाबेस)
मुख्य आर्किटेक्चरल पैटर्न (मोनोरेपो, माइक्रोसर्विसेज, आदि)
गैर-स्पष्ट बाधाएं ("हम लाइब्रेरी X का उपयोग नहीं कर सकते क्योंकि...")
महत्वपूर्ण परंपराएं जो अक्सर नज़रअंदाज की जाती हैं

इसके बजाय rules: में स्थानांतरित करें

आर्टिफैक्ट-विशिष्ट फॉर्मेटिंग ("स्पेक्स में Given/When/Then का उपयोग करें")
समीक्षा मानदंड ("प्रस्तावों में रोलबैक प्लान शामिल होने चाहिए")
ये केवल मिलते-जुलते आर्टिफैक्ट के लिए दिखाई देते हैं, जिससे अन्य अनुरोध हल्के रहते हैं

पूरी तरह से छोड़ दें

सामान्य बेस्ट प्रैक्टिस जिन्हें AI पहले ही जानता है
विस्तृत व्याख्या जिन्हें सारांशित किया जा सकता है
ऐतिहासिक संदर्भ जो वर्तमान काम को प्रभावित नहीं करता

स्थानांतरण चरण

config.yaml बनाएं (यदि इनिट द्वारा पहले ही नहीं बनाया गया हो):
yaml
```
schema: spec-driven
```

अपना संदर्भ जोड़ें (संक्षिप्त रहें—यह हर अनुरोध में जाता है):

yaml

context: |
  आपका प्रोजेक्ट पृष्ठभूमि यहां जाएगा।
  उस पर ध्यान दें जो AI वास्तव में जानने की जरूरत रखता है।

प्रति-आर्टिफैक्ट नियम जोड़ें (वैकल्पिक):

yaml

rules:
  proposal:
    - आपका प्रस्ताव-विशिष्ट मार्गदर्शन
  specs:
    - आपके स्पेक लेखन नियम

project.md को हटा दें एक बार जब आपने सभी उपयोगी सामग्री को स्थानांतरित कर लिया हो।

इस पर ज्यादा सोचें नहीं। आवश्यकताओं से शुरुआत करें और इटरेट करें। यदि आप देखें कि AI कुछ महत्वपूर्ण चीज़ को मिस कर रहा है, तो इसे जोड़ें। यदि संदर्भ बल्की लगता है, तो इसे कम करें। यह एक जीवित दस्तावेज है।

मदद चाहिए? इस प्रॉम्प्ट का उपयोग करें

यदि आप अपने project.md को वितरित करने के तरीके से अनिश्चित हैं, तो अपने AI सहायक से पूछें:

I'm migrating from OpenSpec's old project.md to the new config.yaml format.

Here's my current project.md:
[paste your project.md content]

Please help me create a config.yaml with:
1. A concise `context:` section (this gets injected into every planning request, so keep it tight—focus on tech stack, key constraints, and conventions that often get ignored)
2. `rules:` for specific artifacts if any content is artifact-specific (e.g., "use Given/When/Then" belongs in specs rules, not global context)

Leave out anything generic that AI models already know. Be ruthless about brevity.

AI आपको यह पहचानने में मदद करेगा कि क्या आवश्यक है और क्या कटा जा सकता है।

नए कमांड

कमांड की उपलब्धता प्रोफाइल पर निर्भर करती है:

डिफ़ॉल्ट (core प्रोफाइल):

कमांड	उद्देश्य
`/opsx:propose`	एक बार में एक परिवर्तन बनाएं और प्लानिंग आर्टिफैक्ट जनरेट करें
`/opsx:explore`	बिना संरचना के विचारों को समझें
`/opsx:apply`	tasks.md से कार्य लागू करें
`/opsx:archive`	परिवर्तन को फाइनलाइज़ और आर्काइव करें

विस्तारित वर्कफ्लो (कस्टम चयन):

कमांड	उद्देश्य
`/opsx:new`	एक नया परिवर्तन स्कैफोल्ड शुरू करें
`/opsx:continue`	अगला आर्टिफैक्ट बनाएं (एक समय में एक)
`/opsx:ff`	फास्ट-फॉरवर्ड—एक बार में प्लानिंग आर्टिफैक्ट बनाएं
`/opsx:verify`	लागूकरण को स्पेक्स से मिलाना सत्यापित करें
`/opsx:sync`	डेल्टा स्पेक्स को मुख्य स्पेक्स में मर्ज करें
`/opsx:bulk-archive`	एक बार में कई परिवर्तनों को आर्काइव करें
`/opsx:onboard`	गाइडेड एंड-टू-एंड ऑनबोर्डिंग वर्कफ्लो

विस्तारित कमांड को openspec config profile से सक्षम करें, फिर openspec update चलाएं।

पुराने से कमांड मैपिंग

पुराना	OPSX समकक्ष
`/openspec:proposal`	`/opsx:propose` (डिफ़ॉल्ट) या `/opsx:new` फिर `/opsx:ff` (विस्तारित)
`/openspec:apply`	`/opsx:apply`
`/openspec:archive`	`/opsx:archive`

नई क्षमताएं

ये क्षमताएं विस्तारित वर्कफ्लो कमांड सेट का हिस्सा हैं।

सूक्ष्म आर्टिफैक्ट निर्माण:

/opsx:continue

निर्भरताओं के आधार पर एक समय में एक आर्टिफैक्ट बनाता है। जब आप प्रत्येक चरण की समीक्षा करना चाहें तो इसका उपयोग करें।

एक्सप्लोरेशन मोड:

/opsx:explore

परिवर्तन के लिए कमिट करने से पहले एक साथी के साथ विचारों को समझें।

नई आर्किटेक्चर को समझना

फेज-लॉक्ड से फ्लूइड तक

पुराना वर्कफ्लो रेखीय प्रगति को बाध्य करता था:

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   प्लानिंग   │ ───► │ इंप्लीमेंटेशन │ ───► │  आर्काइविंग  │
│    फेज     │      │    फेज     │      │    फेज     │
└──────────────┘      └──────────────┘      └──────────────┘

यदि आप इंप्लीमेंटेशन में हैं और डिज़ाइन गलत है यह पता चलता है?
बहुत खराब। फेज गेट्स आपको आसानी से वापस नहीं जाने देते।

OPSX एक्शन का उपयोग करता है, फेज नहीं:

         ┌───────────────────────────────────────────────┐
         │           एक्शन (फेज नहीं)                │
         │                                               │
         │     new ◄──► continue ◄──► apply ◄──► archive │
         │      │          │           │             │   │
         │      └──────────┴───────────┴─────────────┘   │
         │                    any order                  │
         └───────────────────────────────────────────────┘

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

आर्टिफैक्ट एक निर्देशित ग्राफ बनाते हैं। निर्भरताएं गेट नहीं, संचालक हैं:

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

जब आप /opsx:continue चलाते हैं, तो यह जांचता है कि क्या तैयार है और अगला आर्टिफैक्ट ऑफर करता है। आप किसी भी क्रम में कई तैयार आर्टिफैक्ट भी बना सकते हैं।

स्किल्स बनाम कमांड

पुराना सिस्टम टूल-विशिष्ट कमांड फाइलों का उपयोग करता था:

.claude/commands/openspec/
├── proposal.md
├── apply.md
└── archive.md

OPSX उभरती हुई स्किल्स मानक का उपयोग करता है:

.claude/skills/
├── openspec-explore/SKILL.md
├── openspec-new-change/SKILL.md
├── openspec-continue-change/SKILL.md
├── openspec-apply-change/SKILL.md
└── ...

स्किल्स को कई AI कोडिंग टूल में पहचाना जाता है और ये अधिक समृद्ध मेटाडेटा प्रदान करते हैं।

Codex OPSX में केवल स्किल्स-ऑनली है। OpenSpec अब Codex कस्टम प्रॉम्प्ट फाइलें जनरेट नहीं करता; इसके बजाय जनरेट की गई .codex/skills/openspec-* डिरेक्ट्री का उपयोग करें।

मौजूदा परिवर्तनों को जारी रखें

आपके प्रगति परिवर्तन OPSX कमांड के साथ बिना किसी समस्या के काम करेंगे।

पुराने वर्कफ्लो से कोई सक्रिय परिवर्तन है?

/opsx:apply add-my-feature

OPSX मौजूदा आर्टिफैक्ट्स को पढ़ता है और जहां आपने छोड़ा था वहां से जारी रखता है।

मौजूदा परिवर्तन में और आर्टिफैक्ट्स जोड़ना चाहते हैं?

/opsx:continue add-my-feature

यह दिखाता है कि मौजूदा चीजों के आधार पर क्या बनाने के लिए तैयार है।

स्थिति देखने की जरूरत है?

bash

openspec status --change add-my-feature

नया कॉन्फ़िग सिस्टम

config.yaml संरचना

yaml

# आवश्यक: नए परिवर्तनों के लिए डिफ़ॉल्ट स्कीमा
schema: spec-driven

# वैकल्पिक: प्रोजेक्ट संदर्भ (अधिकतम 50KB)
# सभी आर्टिफैक्ट निर्देशों में इंजेक्ट किया जाता है
context: |
  Your project background, tech stack,
  conventions, and constraints.

# वैकल्पिक: प्रति-आर्टिफैक्ट नियम
# केवल मिलते-जुलते आर्टिफैक्ट्स में इंजेक्ट किया जाता है
rules:
  proposal:
    - Include rollback plan
  specs:
    - Use Given/When/Then format
  design:
    - Document fallback strategies
  tasks:
    - Break into 2-hour maximum chunks

स्कीमा रिज़ॉल्यूशन

किस स्कीमा का उपयोग करने का निर्णय लेते समय, OPSX निम्नलिखित क्रम में जांचता है:

CLI फ्लैग: --schema <name> (उच्चतम प्राथमिकता)
परिवर्तन मेटाडेटा: परिवर्तन निर्देशिका में .openspec.yaml
प्रोजेक्ट कॉन्फ़िग: openspec/config.yaml
डिफ़ॉल्ट: spec-driven

उपलब्ध स्कीमा

स्कीमा	आर्टिफैक्ट्स	सबसे अच्छा
`spec-driven`	proposal → specs → design → tasks	अधिकांश प्रोजेक्ट्स के लिए

सभी उपलब्ध स्कीमाओं को सूचीबद्ध करें:

bash

openspec schemas

कस्टम स्कीमा

अपना खुद का वर्कफ्लो बनाएं:

bash

openspec schema init my-workflow

या मौजूदा का फोर्क बनाएं:

bash

openspec schema fork spec-driven my-workflow

विवरण के लिए अनुकूलन देखें।

समस्या निवारण

"नॉन-इंटरैक्टिव मोड में लेगेसी फाइलें मिली हैं"

आप CI या नॉन-इंटरैक्टिव वातावरण में चल रहे हैं। उपयोग करें:

bash

openspec init --force

माइग्रेशन के बाद कमांड्स दिखाई नहीं दे रहे

अपना IDE रीस्टार्ट करें। स्किल्स स्टार्टअप पर डिटेक्ट होती हैं।

"नियमों में अज्ञात आर्टिफैक्ट ID"

सुनिश्चित करें कि आपके rules: कुंजियां आपकी स्कीमा के आर्टिफैक्ट IDs से मेल खाती हैं:

spec-driven: proposal, specs, design, tasks

वैध आर्टिफैक्ट IDs देखने के लिए यह चलाएं:

bash

openspec schemas --json

कॉन्फ़िग लागू नहीं हो रहा

सुनिश्चित करें कि फाइल openspec/config.yaml पर है (.yml नहीं)
YAML सिंटैक्स को वैलिडेट करें
कॉन्फ़िग परिवर्तन तुरंत लागू हो जाते हैं—रीस्टार्ट की जरूरत नहीं

project.md माइग्रेट नहीं हुआ

सिस्टम जानबूझकर project.md को संरक्षित रखता है क्योंकि इसमें आपका कस्टम कंटेंट हो सकता है। इसे मैन्युअली रिव्यू करें, उपयोगी हिस्सों को config.yaml में ले जाएं, फिर इसे डिलीट कर दें।

साफ किया जाएगा यह देखना चाहते हैं?

init चलाएं और क्लीनअप प्रॉम्प्ट को रद्द करें—आपको बिना किसी परिवर्तन के पूरा डिटेक्शन सारांश दिख जाएगा।

क्विक रेफरेंस

माइग्रेशन के बाद की फाइलें

project/
├── openspec/
│   ├── specs/                    # Unchanged
│   ├── changes/                  # Unchanged
│   │   └── archive/              # Unchanged
│   └── config.yaml               # NEW: Project configuration
├── .claude/
│   └── skills/                   # NEW: OPSX skills
│       ├── openspec-propose/     # default core profile
│       ├── openspec-explore/
│       ├── openspec-apply-change/
│       ├── openspec-sync-specs/
│       └── ...                   # expanded profile adds new/continue/ff/etc.
├── CLAUDE.md                     # OpenSpec markers removed, your content preserved
└── AGENTS.md                     # OpenSpec markers removed, your content preserved

क्या गायब हो गया है

.claude/commands/openspec/ — .claude/skills/ द्वारा बदला गया
openspec/AGENTS.md — अप्रचलित
openspec/project.md — config.yaml में माइग्रेट करें, फिर डिलीट करें
CLAUDE.md, AGENTS.md आदि में OpenSpec मार्कर ब्लॉक

कमांड चीटशीट

text

/opsx:propose      Start quickly (default core profile)
/opsx:apply        Implement tasks
/opsx:archive      Finish and archive

# Expanded workflow (if enabled):
/opsx:new          Scaffold a change
/opsx:continue     Create next artifact
/opsx:ff           Create planning artifacts

मदद प्राप्त करें

डिस्कॉर्ड: discord.gg/YctCnvvshC
गिटहब इश्यूज: github.com/Fission-AI/OpenSpec/issues
डॉक्यूमेंटेशन: पूर्ण OPSX रेफरेंस के लिए docs/opsx.md

OPSX पर माइग्रेट करना ​

क्या बदल रहा है? ​

शुरू करने से पहले ​

आपका मौजूदा काम सुरक्षित है ​

क्या हटा दिया जाता है ​

आपका ध्यान किस चीज़ पर जरूरी है ​

स्थानांतरण चलाना ​

openspec init का उपयोग करना ​

openspec update का उपयोग करना ​

नॉन-इंटरैक्टिव / CI परिवेश ​

project.md को config.yaml में स्थानांतरित करना ​

पहले (project.md) ​

बाद में (config.yaml) ​

मुख्य अंतर ​

क्या रखें, क्या हटा दें ​

स्थानांतरण चरण ​

मदद चाहिए? इस प्रॉम्प्ट का उपयोग करें ​

नए कमांड ​

पुराने से कमांड मैपिंग ​

नई क्षमताएं ​

नई आर्किटेक्चर को समझना ​

फेज-लॉक्ड से फ्लूइड तक ​

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

स्किल्स बनाम कमांड ​

मौजूदा परिवर्तनों को जारी रखें ​

नया कॉन्फ़िग सिस्टम ​

config.yaml संरचना ​

स्कीमा रिज़ॉल्यूशन ​

उपलब्ध स्कीमा ​

कस्टम स्कीमा ​

समस्या निवारण ​

"नॉन-इंटरैक्टिव मोड में लेगेसी फाइलें मिली हैं" ​

माइग्रेशन के बाद कमांड्स दिखाई नहीं दे रहे ​

"नियमों में अज्ञात आर्टिफैक्ट ID" ​

कॉन्फ़िग लागू नहीं हो रहा ​

project.md माइग्रेट नहीं हुआ ​

साफ किया जाएगा यह देखना चाहते हैं? ​

क्विक रेफरेंस ​

माइग्रेशन के बाद की फाइलें ​

क्या गायब हो गया है ​

कमांड चीटशीट ​

मदद प्राप्त करें ​

OPSX पर माइग्रेट करना

क्या बदल रहा है?

शुरू करने से पहले

आपका मौजूदा काम सुरक्षित है

क्या हटा दिया जाता है

आपका ध्यान किस चीज़ पर जरूरी है

स्थानांतरण चलाना

`openspec init` का उपयोग करना

`openspec update` का उपयोग करना

नॉन-इंटरैक्टिव / CI परिवेश

project.md को config.yaml में स्थानांतरित करना

पहले (project.md)

बाद में (config.yaml)

मुख्य अंतर

क्या रखें, क्या हटा दें

स्थानांतरण चरण

मदद चाहिए? इस प्रॉम्प्ट का उपयोग करें

नए कमांड

पुराने से कमांड मैपिंग

नई क्षमताएं

नई आर्किटेक्चर को समझना

फेज-लॉक्ड से फ्लूइड तक

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

स्किल्स बनाम कमांड

मौजूदा परिवर्तनों को जारी रखें

नया कॉन्फ़िग सिस्टम

config.yaml संरचना

स्कीमा रिज़ॉल्यूशन

उपलब्ध स्कीमा

कस्टम स्कीमा

समस्या निवारण

"नॉन-इंटरैक्टिव मोड में लेगेसी फाइलें मिली हैं"

माइग्रेशन के बाद कमांड्स दिखाई नहीं दे रहे

"नियमों में अज्ञात आर्टिफैक्ट ID"

कॉन्फ़िग लागू नहीं हो रहा

project.md माइग्रेट नहीं हुआ

साफ किया जाएगा यह देखना चाहते हैं?

क्विक रेफरेंस

माइग्रेशन के बाद की फाइलें

क्या गायब हो गया है

कमांड चीटशीट

मदद प्राप्त करें