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

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

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

OPSX पुराने फेज़-लॉक्ड वर्कफ़्लो (phase-locked workflow) को एक तरल, क्रिया-आधारित दृष्टिकोण (action-based approach) से प्रतिस्थापित करता है। यहाँ मुख्य परिवर्तन है:

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

दर्शन में परिवर्तन: कार्य रैखिक (linear) नहीं है। 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
Devin Desktop, formerly 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 में समर्थित नहीं)
Codex: OpenSpec अब कैनोनिकल .agents/skills/openspec-* पथ का उपयोग करता है। पूर्व .codex/skills पथ के तहत OpenSpec-प्रबंधित SKILL.md फ़ाइलें केवल तभी समायोजित की जाती हैं जब प्रतिस्थापन मौजूद हों; कस्टम फ़ाइलें और विचलित कॉपियाँ अपनी जगह पर रहती हैं。 यदि एक अनमार्क्ड .agents ट्री में पहले से ही OpenSpec स्किल्स मौजूद हैं, तो OpenSpec पुरानी डायरेक्टरी से अनुमान लगाने के बजाय अपना मौजूदा Codex ($openspec-*) या जेनेरिक (/openspec-*) रेंडरिंग सुरक्षित रखता है। स्वामित्व बदलने के लिए openspec init के साथ codex स्पष्ट रूप से चुनें। पुरानी प्रॉम्प्ट क्लीनअप अभी भी केवल OpenSpec की अनुमोदित फ़ाइल नामों को $CODEX_HOME/prompts या ~/.codex/prompts में लक्षित करता है।
और अन्य (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, update, sync, archive) पर होते हैं।
मिग्रेटेड इंस्टॉल आवश्यकतानुसार custom प्रोफ़ाइल लिखकर आपके पूर्व में इंस्टॉल किए गए वर्कफ्लो को सुरक्षित रखते हैं।

`openspec init` का उपयोग

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

bash

openspec init

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

Upgrading to the new OpenSpec

OpenSpec now uses agent skills, the emerging standard across coding
agents. This simplifies your setup while keeping everything working
as before.

Files to remove
No user content to preserve:
  • .claude/commands/openspec/
  • openspec/AGENTS.md

Files to update
OpenSpec markers will be removed, your content preserved:
  • CLAUDE.md
  • AGENTS.md

Needs your attention
  • openspec/project.md
    We won't delete this file. It may contain useful project context.

    The new openspec/config.yaml has a "context:" section for planning
    context. This is included in every OpenSpec request and works more
    reliably than the old project.md approach.

    Review project.md, move any useful content to config.yaml's context
    section, then delete the file when ready.

? Upgrade and clean up legacy files? (Y/n)

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

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

`openspec update` का उपयोग

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

bash

openspec update

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

नॉन-इंटरैक्टिव / CI पर्यावरण

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

bash

openspec init --force --tools claude

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

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

project.md से config.yaml में मिग्रेशन

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

पहले (project.md)

markdown

# 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)

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 पहले से जानता है
विस्तृत व्याख्याएँ जो सारांशित की जा सकती हैं
ऐतिहासिक संदर्भ जो वर्तमान कार्य को प्रभावित नहीं करता

मिग्रेशन चरण

config.yaml बनाएँ (यदि init द्वारा पहले से नहीं बनाया गया):
yaml
```
schema: spec-driven
```
अपना संदर्भ जोड़ें (संक्षिप्त रहें—यह हर अनुरोध में जाता है):
yaml
```
context: |
  Your project background goes here.
  Focus on what the AI genuinely needs to know.
```

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

yaml

rules:
  proposal:
    - Your proposal-specific guidance
  specs:
    - Your spec-writing rules

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:update`	परिवर्तन के प्लानिंग आर्टिफैक्ट्स संशोधित करें और उन्हें सुसंगत रखें
`/opsx:sync`	डेल्टा स्पेक्स को मुख्य स्पेक्स में मर्ज करें
`/opsx:archive`	परिवर्तन को अंतिम रूप दें और आर्काइव करें

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

कमांड	उद्देश्य
`/opsx:new`	नया परिवर्तन स्काफ़ोल्ड शुरू करें
`/opsx:continue`	अगला आर्टिफैक्ट बनाएँ (एक समय में एक)
`/opsx:ff`	फास्ट-फ़ॉरवर्ड—एक साथ प्लानिंग आर्टिफैक्ट्स बनाएँ
`/opsx:verify`	सत्यापित करें कि कार्यान्वयन स्पेक्स से मेल खाता है
`/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     │
└──────────────┘      └──────────────┘      └──────────────┘

If you're in implementation and realize the design is wrong?
Too bad. Phase gates don't let you go back easily.

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 उभरते स्किल्स स्टैंडर्ड का उपयोग करता है:

.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 कस्टम प्रॉम्प्ट फ़ाइलें जनरेट नहीं करता; इसके बजाय जनरेटेड .agents/skills/openspec-* डायरेक्टरीज़ का उपयोग करें।

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

आपके प्रगतिशील परिवर्तन OPSX कमांड्स के साथ सहजता से काम करते हैं।

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

/opsx:apply add-my-feature

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

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

/opsx:continue add-my-feature

यह दिखाता है कि मौजूदा सामग्री के आधार पर क्या तैयार है।

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

bash

openspec status --change add-my-feature

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

config.yaml संरचना

yaml

# Required: Default schema for new changes
schema: spec-driven

# Optional: Project context (max 50KB)
# Injected into ALL artifact instructions
context: |
  Your project background, tech stack,
  conventions, and constraints.

# Optional: Per-artifact rules
# Only injected into matching artifacts
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

विवरण के लिए Customization देखें।

ट्राबलशूटिंग

"Legacy files detected in non-interactive mode"

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

bash

openspec init --force

माइग्रेशन के बाद कमांड्स प्रकट नहीं हो रहे

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

"Unknown artifact ID in rules"

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

spec-driven: proposal, specs, design, tasks

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

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-update-change/
│       ├── openspec-sync-specs/
│       ├── openspec-archive-change/
│       └── ...                   # 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: discord.gg/YctCnvvshC
GitHub Issues: github.com/Fission-AI/OpenSpec/issues
Documentation: docs/opsx.md पूर्ण OPSX रीफ़रेंस के लिए

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

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

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

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

क्या हटाया जाएगा ​

क्या आपकी ध्यान देने की आवश्यकता है ​

मिग्रेशन चलाएँ ​

openspec init का उपयोग ​

openspec update का उपयोग ​

नॉन-इंटरैक्टिव / CI पर्यावरण ​

project.md से config.yaml में मिग्रेशन ​

पहले (project.md) ​

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

मुख्य अंतर ​

क्या रखें, क्या छोड़ें ​

मिग्रेशन चरण ​

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

नई कमांड्स ​

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

नई क्षमताएँ ​

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

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

डिपेंडेंसी ग्राफ़ ​

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

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

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

config.yaml संरचना ​

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

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

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

ट्राबलशूटिंग ​

"Legacy files detected in non-interactive mode" ​

माइग्रेशन के बाद कमांड्स प्रकट नहीं हो रहे ​

"Unknown artifact ID in rules" ​

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

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

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

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

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

क्या हटा दिया गया ​

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

मदद प्राप्त करना ​

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

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

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

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

क्या हटाया जाएगा

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

मिग्रेशन चलाएँ

`openspec init` का उपयोग

`openspec update` का उपयोग

नॉन-इंटरैक्टिव / CI पर्यावरण

project.md से config.yaml में मिग्रेशन

पहले (project.md)

बाद में (config.yaml)

मुख्य अंतर

क्या रखें, क्या छोड़ें

मिग्रेशन चरण

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

नई कमांड्स

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

नई क्षमताएँ

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

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

डिपेंडेंसी ग्राफ़

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

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

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

config.yaml संरचना

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

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

कस्टम स्कीमा

ट्राबलशूटिंग

"Legacy files detected in non-interactive mode"

माइग्रेशन के बाद कमांड्स प्रकट नहीं हो रहे

"Unknown artifact ID in rules"

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

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

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

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

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

क्या हटा दिया गया

कमांड चीटशीट

मदद प्राप्त करना