OPSX में माइग्रेशन

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

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

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

पहलू	पुराना	OPSX
कमांड	/openspec:proposal, /openspec:apply, /openspec:archive	डिफ़ॉल्ट: /opsx:propose, /opsx:apply, /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: .clinerules/workflows/openspec-*.md
• Roo: .roo/commands/openspec-*.md
• GitHub Copilot: .github/prompts/openspec-*.prompt.md (केवल IDE एक्सटेंशन; Copilot CLI में समर्थित नहीं)
• और अन्य (Augment, Continue, Amazon Q, आदि)

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

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

आपके ध्यान की आवश्यकता

एक फ़ाइल के लिए मैनुअल माइग्रेशन की आवश्यकता है:

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

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

हमने यह परिवर्तन क्यों किया:

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

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

व्यापार-बंधन:

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

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

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

---

माइग्रेशन चलाना

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

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

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

यदि आप नए उपकरण जोड़ना या यह पुनर्कॉन्फ़िगर करना चाहते हैं कि कौन से उपकरण सेटअप हैं, तो यह चलाएँ:

openspec init

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)

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

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

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

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

openspec update

update कमांड भी लेगेसी कलाकृतियों का पता लगाता है और साफ़ करता है, फिर आपकी वर्तमान प्रोफ़ाइल और डिलीवरी सेटिंग्स से मेल खाने के लिए जनरेटेड स्किल्स/कमांड को रीफ्रेश करता है।

गैर-इंटरैक्टिव / CI वातावरण

स्क्रिप्टेड माइग्रेशन के लिए:

openspec init --force --tools claude

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

---

project.md को config.yaml में माइग्रेट करना

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

पहले (project.md)

# Project Context

This is a TypeScript monorepo using React and Node.js.
We use Jest for testing and follow strict ESLint rules.
Our API is RESTful and documented in docs/api.md.

## Conventions

- All public APIs must maintain backwards compatibility
- New features should include tests
- Use Given/When/Then format for specifications

बाद में (config.yaml)

schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  Testing: Jest with React Testing Library
  API: RESTful, documented in docs/api.md
  We maintain backwards compatibility for all public APIs

rules:
  proposal:
    - Include rollback plan for risky changes
  specs:
    - Use Given/When/Then format for scenarios
    - Reference existing patterns before inventing new ones
  design:
    - Include sequence diagrams for complex flows

मुख्य अंतर

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

क्या रखना है, क्या छोड़ना है

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

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

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

इसके बजाय rules: में ले जाएँ

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

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

• सामान्य सर्वोत्तम प्रथाएँ जो AI को पहले से पता हैं
• विस्तृत व्याख्याएँ जिन्हें संक्षेपित किया जा सकता है
• ऐतिहासिक संदर्भ जो वर्तमान काम को प्रभावित नहीं करता

माइग्रेशन चरण

1. config.yaml बनाएँ (यदि init द्वारा पहले से नहीं बनाया गया):

   schema: spec-driven

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

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

3. प्रति-कलाकृति नियम जोड़ें (वैकल्पिक):

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

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

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

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

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

मैं OpenSpec के पुराने project.md से नए config.yaml प्रारूप में माइग्रेट कर रहा हूँ।

यहाँ मेरा वर्तमान project.md है:
[अपनी project.md सामग्री पेस्ट करें]

कृपया मेरी मदद करें एक config.yaml बनाने में जिसमें:
1. एक संक्षिप्त `context:` अनुभाग (यह हर प्लानिंग अनुरोध में इंजेक्ट किया जाता है, इसलिए इसे तंग रखें—टेक स्टैक, प्रमुख बाधाओं, और अक्सर अनदेखी की जाने वाली परंपराओं पर ध्यान केंद्रित करें)
2. विशिष्ट कलाकृतियों के लिए `rules:` यदि कोई सामग्री कलाकृति-विशिष्ट है (जैसे, "Given/When/Then का उपयोग करें" specs नियमों में होना चाहिए, वैश्विक संदर्भ में नहीं)

AI मॉडल्स को पहले से पता है वह कुछ भी सामान्य छोड़ दें। संक्षिप्तता के लिए निर्दयी रहें।

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

परिवर्तन के लिए प्रतिबद्ध होने से पहले एक साथी के साथ विचारों पर विचार करें।

---

नई वास्तुकला को समझना

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

पुरानी वर्कफ़्लो ने रैखिक प्रगति को मजबूर किया:

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │
│    PHASE     │      │    PHASE     │      │    PHASE     │
└──────────────┘      └──────────────┘      └──────────────┘

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

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

         ┌───────────────────────────────────────────────┐
         │           ACTIONS (not phases)                │
         │                                               │
         │     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 उभरते हुए skills मानक का उपयोग करता है:

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

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

---

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

आपके प्रगति में चल रहे परिवर्तन OPSX कमांड्स के साथ निर्बाध रूप से काम करते हैं।

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

/opsx:apply add-my-feature

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

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

/opsx:continue add-my-feature

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

स्थिति देखने की आवश्यकता है?

openspec status --change add-my-feature

---

नई कॉन्फ़िग प्रणाली

config.yaml संरचना

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

# वैकल्पिक: प्रोजेक्ट संदर्भ (अधिकतम 50KB)
# सभी आर्टिफैक्ट निर्देशों में इंजेक्ट किया जाता है
context: |
  आपकी परियोजना की पृष्ठभूमि, टेक स्टैक,
  परंपराएँ और बाधाएँ।

# वैकल्पिक: प्रति-आर्टिफैक्ट नियम
# केवल मेल खाने वाले आर्टिफैक्ट्स में इंजेक्ट किया जाता है
rules:
  proposal:
    - रोलबैक योजना शामिल करें
  specs:
    - Given/When/Then प्रारूप का उपयोग करें
  design:
    - फ़ॉलबैक रणनीतियों का दस्तावेज़ीकरण करें
  tasks:
    - 2 घंटे के अधिकतम चंक्स में तोड़ें

स्कीमा संकल्पना

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

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

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

स्कीमा	आर्टिफैक्ट्स	सर्वोत्तम के लिए
spec-driven	proposal → specs → design → tasks	अधिकांश परियोजनाएँ

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

openspec schemas

कस्टम स्कीमाएँ

अपनी वर्कफ़्लो बनाएँ:

openspec schema init my-workflow

या किसी मौजूदा को फोर्क करें:

openspec schema fork spec-driven my-workflow

विवरण के लिए कस्टमाइज़ेशन देखें।

---

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

"गैर-इंटरैक्टिव मोड में पुरानी फ़ाइलें पाई गईं"

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

openspec init --force

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

अपना IDE पुनरारंभ करें। स्किल्स स्टार्टअप पर पहचाने जाते हैं।

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

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

• spec-driven: proposal, specs, design, tasks

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

openspec schemas --json

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

1. सुनिश्चित करें कि फ़ाइल openspec/config.yaml पर है (.yml नहीं)
2. YAML सिंटैक्स मान्य करें
3. कॉन्फ़िग परिवर्तन तुरंत प्रभावी होते हैं—पुनरारंभ की आवश्यकता नहीं

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

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

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

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

---

त्वरित संदर्भ

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

project/
├── openspec/
│   ├── specs/                    # अपरिवर्तित
│   ├── changes/                  # अपरिवर्तित
│   │   └── archive/              # अपरिवर्तित
│   └── config.yaml               # नया: प्रोजेक्ट कॉन्फ़िगरेशन
├── .claude/
│   └── skills/                   # नया: OPSX स्किल्स
│       ├── openspec-propose/     # डिफ़ॉल्ट कोर प्रोफ़ाइल
│       ├── openspec-explore/
│       ├── openspec-apply-change/
│       └── ...                   # विस्तारित प्रोफ़ाइल new/continue/ff/आदि जोड़ती है
├── CLAUDE.md                     # OpenSpec मार्कर हटा दिए गए, आपकी सामग्री संरक्षित
└── AGENTS.md                     # OpenSpec मार्कर हटा दिए गए, आपकी सामग्री संरक्षित

क्या गायब है

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

कमांड चीटशीट

/opsx:propose      जल्दी शुरू करें (डिफ़ॉल्ट कोर प्रोफ़ाइल)
/opsx:apply        कार्य कार्यान्वित करें
/opsx:archive      समाप्त करें और संग्रहीत करें

# विस्तारित वर्कफ़्लो (यदि सक्षम हो):
/opsx:new          एक परिवर्तन का ढाँचा बनाएँ
/opsx:continue     अगला आर्टिफैक्ट बनाएँ
/opsx:ff           प्लानिंग आर्टिफैक्ट्स बनाएँ

---

सहायता प्राप्त करना

• Discord: discord.gg/YctCnvvshC
• GitHub Issues: github.com/Fission-AI/OpenSpec/issues
• दस्तावेज़ीकरण: पूर्ण OPSX संदर्भ के लिए docs/opsx.md