CLI संदर्भ

OpenSpec CLI (openspec) प्रोजेक्ट सेटअप, सत्यापन, स्थिति निरीक्षण और प्रबंधन के लिए टर्मिनल कमांड प्रदान करता है। ये कमांड एआई स्लैश कमांड (जैसे /opsx:propose) के पूरक हैं, जो आदेश में दस्तावेज़ित हैं।

सारांश

श्रेणी	कमांड्स	उद्देश्य
सेटअप	`init`, `update`	आपके प्रोजेक्ट में ओपनस्पेक को आरंभ और अद्यतन करें
स्टोर्स (स्टैंडअलोन ओपनस्पेक रिपॉज़िटरी)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	स्टोर्स प्रबंधित करें — वे स्टैंडअलोन ओपनस्पेक रिपॉज़िटरी जिन्हें आपने पंजीकृत किया है
स्वास्थ्य	`doctor`	हल किए गए रूट के लिए संबंध स्वास्थ्य की रिपोर्ट करें
कार्य संदर्भ	`context`	कार्य सेट (रूट + संदर्भित स्टोर्स) को संकलित करें
व्यक्तिगत वर्कसेट	`workset create`, `workset list`, `workset open`, `workset remove`	अपने टूल में व्यक्तिगत, स्थानीय कार्य दृश्य रखें और खोलें
ब्राउज़िंग	`list`, `view`, `show`	परिवर्तनों और स्पेक्स का अन्वेषण करें
सत्यापन	`validate`	मुद्दों के लिए परिवर्तनों और स्पेक्स की जाँच करें
जीवनचक्र	`archive`	पूर्ण किए गए परिवर्तनों को अंतिम रूप दें
वर्कफ़्लो	`new change`, `status`, `instructions`, `templates`, `schemas`	आर्टिफैक्ट-आधारित वर्कफ़्लो समर्थन
स्कीमा	`schema init`, `schema fork`, `schema validate`, `schema which`	कस्टम वर्कफ़्लो बनाएं और प्रबंधित करें
कॉन्फ़िग	`config`	सेटिंग्स देखें और संशोधित करें
उपयोगिता	`feedback`, `completion`	प्रतिक्रिया और शेल एकीकरण

मानव बनाम एजेंट कमांड्स

ज़्यादातर CLI कमांड्स टर्मिनल में मानव उपयोग के लिए डिज़ाइन किए गए हैं। कुछ कमांड्स JSON आउटपुट के माध्यम से एजेंट/स्क्रिप्ट उपयोग का भी समर्थन करते हैं।

केवल मानव कमांड्स

ये कमांड्स इंटरैक्टिव हैं और टर्मिनल उपयोग के लिए डिज़ाइन किए गए हैं:

कमांड	उद्देश्य
`openspec init`	परियोजना प्रारंभ करें (इंटरैक्टिव प्रॉम्प्ट)
`openspec view`	इंटरैक्टिव डैशबोर्ड
`openspec workset open <name>`	एक सहेजा गया वर्कसेट खोलें (एडिटर विंडो या टर्मिनल एजेंट सेशन)
`openspec config edit`	कॉन्फ़िग को एडिटर में खोलें
`openspec feedback`	GitHub के माध्यम से फीडबैक सबमिट करें
`openspec completion install`	शेल कंप्लीशन इंस्टॉल करें

एजेंट-संगत कमांड्स

ये कमांड्स AI एजेंट्स और स्क्रिप्ट्स के प्रोग्रामैटिक उपयोग के लिए --json आउटपुट का समर्थन करते हैं:

कमांड	मानव उपयोग	एजेंट उपयोग
`openspec list`	परिवर्तन/स्पेक्स ब्राउज़ करें	संरचित डेटा के लिए `--json`
`openspec show <item>`	कंटेंट पढ़ें	पार्सिंग के लिए `--json`
`openspec validate`	समस्याओं की जाँच करें	बल्क वैलिडेशन के लिए `--all --json`
`openspec status`	आर्टिफैक्ट प्रगति देखें	संरचित स्थिति के लिए `--json`
`openspec instructions`	अगले चरण प्राप्त करें	एजेंट निर्देशों के लिए `--json`
`openspec templates`	टेम्पलेट पथ खोजें	पथ रिज़ॉल्यूशन के लिए `--json`
`openspec schemas`	उपलब्ध स्कीमा सूची	स्कीमा डिस्कवरी के लिए `--json`; पंजीकृत रूट चुनने के लिए `--store <id>`
`openspec store setup <id>`	स्थानीय स्टोर बनाएं और पंजीकृत करें	संरचित सेटअप आउटपुट के लिए स्पष्ट इनपुट के साथ `--json`
`openspec store register <path>`	मौजूदा स्टोर पंजीकृत करें	संरचित पंजीकरण आउटपुट के लिए `--json`
`openspec store unregister <id>`	स्थानीय स्टोर पंजीकरण भूल जाएँ	संरचित क्लीनअप आउटपुट के लिए `--json`
`openspec store remove <id>`	पंजीकृत स्थानीय स्टोर फ़ोल्डर हटाएं	गैर-इंटरैक्टिव डिलीशन के लिए `--yes --json`
`openspec store list`	पंजीकृत स्टोर ब्राउज़ करें	संरचित पंजीकरण के लिए `--json`
`openspec store doctor`	स्थानीय स्टोर सेटअप की जाँच करें	संरचित डायग्नोस्टिक्स के लिए `--json`
`openspec new change <id>`	रिपो-स्थानीय परिवर्तन स्कैफ़ोल्डिंग बनाएं	`--json`, साथ में पंजीकृत स्टोर को OpenSpec रूट के रूप में उपयोग करने के लिए `--store <id>`
`openspec workset create [name]`	व्यक्तिगत कार्य दृश्य बनाएं	गैर-इंटरैक्टिव संयोजन के लिए `--member <path> --json`
`openspec workset list`	सहेजे गए वर्कसेट ब्राउज़ करें	संरचित दृश्यों के लिए `--json`
`openspec workset remove <name>`	सहेजा गया दृश्य हटाएं	गैर-इंटरैक्टिव रिमूवल के लिए `--yes --json`

वैश्विक विकल्प

ये विकल्प सभी कमांड्स के साथ काम करते हैं:

विकल्प	विवरण
`--version`, `-V`	वर्जन नंबर दिखाएं
`--no-color`	रंग आउटपुट निष्क्रिय करें
`--help`, `-h`	कमांड के लिए सहायता दिखाएं

सेटअप कमांड्स

`openspec init`

अपनी परियोजना में OpenSpec प्रारंभ करें। फ़ोल्डर संरचना बनाता है और AI टूल इंटीग्रेशन कॉन्फ़िगर करता है।

डिफ़ॉल्ट व्यवहार वैश्विक कॉन्फ़िग डिफ़ॉल्ट्स का उपयोग करता है: प्रोफ़ाइल core, डिलीवरी both, वर्कफ़्लो propose, explore, apply, update, sync, archive।

openspec init [path] [options]

--language <language> का उपयोग करके नई परियोजना के openspec/config.yaml में भाषा निर्देश जोड़ें। मौजूदा परियोजना के लिए, कॉन्फ़िग का context फील्ड संपादित करें ताकि OpenSpec परियोजना-विशिष्ट मार्गदर्शन कभी ओवरराइट न करे।

आर्ग्यूमेंट्स:

आर्ग्यूमेंट	आवश्यक	विवरण
`path`	नहीं	लक्षित डायरेक्टरी (डिफ़ॉल्ट: वर्तमान डायरेक्टरी)

विकल्प:

विकल्प	विवरण
`--tools <list>`	AI टूल गैर-इंटरैक्टिव रूप से कॉन्फ़िगर करें। `all`, `none`, या कॉमा-अलग सूची का उपयोग करें
`--language <language>`	नई कॉन्फ़िग बनाते समय आर्टिफैक्ट इस भाषा में लिखें
`--force`	प्रॉम्प्ट किए बिना लीगेसी फ़ाइलों का स्वतः क्लीनअप करें
`--profile <profile>`	इस init चाल के लिए वैश्विक प्रोफ़ाइल ओवरराइड करें (`core` या `custom`)
`--no-animation`	एनिमेटेड स्क्रीन के बजाय स्थिर स्वागत स्क्रीन दिखाएं
`--copilot-cloud`	प्रॉम्प्ट किए बिना GitHub Copilot क्लाउड कोडिंग-एजेंट फ़ाइलें सेटअप करें
`--no-copilot-cloud`	प्रॉम्प्ट किए बिना GitHub Copilot क्लाउड कोडिंग-एजेंट फ़ाइलें छोड़ें

--profile custom वैश्विक कॉन्फ़िग में वर्तमान में चयनित वर्कफ़्लो का उपयोग करता है (openspec config profile)।

स्वागत एनिमेशन तब भी छोड़ा जाता है जब OPENSPEC_NO_ANIMATION पर्यावरण वेरिएबल सेट हो (कोई भी मान, खाली सहित), जब NO_COLOR को गैर-खाली मान सेट किया गया हो, या जब OS रीड्यूस्ड-मोशन पसंद सक्षम हो (macOS Reduce Motion, GNOME एनिमेशन निष्क्रिय)।

समर्थित टूल ID (--tools) — windsurf भी स्वीकार किया जाता है, devin के एलियास के रूप में: amazon-q, antigravity, auggie, bob, claude, cline, command-code, codeartsagent, codex, devin, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, minimax-code, vibe, oh-my-pi, opencode, pi, codeassistant, qoder, qwen, rovodev, roocode, trae, zed, zcode, agents

यह सूची src/core/config.ts में AI_TOOLS का प्रतिबिंब है。 प्रत्येक टूल के स्किल और कमांड पथ के लिए समर्थित टूल देखें।

उदाहरण:

bash

# इंटरैक्टिव इनिशियलाइज़ेशन
openspec init

# विशिष्ट डायरेक्टरी में इनिशियलाइज़ करें
openspec init ./my-project

# गैर-इंटरैक्टिव: Claude और Cursor के लिए कॉन्फ़िगर करें
openspec init --tools claude,cursor

# गैर-इंटरैक्टिव: वैश्विक MiniMax Code स्किल कॉन्फ़िगर करें
openspec init --tools minimax-code

# सभी समर्थित टूल के लिए कॉन्फ़िगर करें
openspec init --tools all

# इस चाल के लिए प्रोफ़ाइल ओवरराइड करें
openspec init --profile core

# प्रॉम्प्ट छोड़ें और लीगेसी फ़ाइलों का स्वतः क्लीनअप करें
openspec init --force

यह क्या बनाता है:

openspec/
├── specs/              # आपकी विशिष्टताएँ (सच का स्रोत)
├── changes/            # प्रस्तावित परिवर्तन
└── config.yaml         # परियोजना कॉन्फ़िगरेशन

.claude/skills/         # Claude Code स्किल (यदि claude चुना गया हो)
.cursor/skills/         # Cursor स्किल (यदि cursor चुना गया हो)
.cursor/commands/       # Cursor OPSX कमांड्स (यदि डिलीवरी में कमांड्स शामिल हों)
.agents/skills/         # AGENTS.md-संगत टूल के लिए साझा स्किल (यदि agents चुना गया हो)
... (अन्य टूल कॉन्फ़िग)

`openspec update`

CLI अपग्रेड के बाद OpenSpec निर्देश फ़ाइलें अपडेट करें। आपकी वर्तमान वैश्विक प्रोफ़ाइल, चयनित वर्कफ़्लो और डिलीवरी मोड का उपयोग करके AI टूल कॉन्फ़िगरेशन फ़ाइलें पुनः जनरेट करता है।

openspec update [path] [options]

आर्ग्यूमेंट्स:

आर्ग्यूमेंट	आवश्यक	विवरण
`path`	नहीं	लक्षित डायरेक्टरी (डिफ़ॉल्ट: वर्तमान डायरेक्टरी)

विकल्प:

विकल्प	विवरण
`--force`	फ़ाइलें अप-टू-डेट होने पर भी अपडेट करें

उदाहरण:

bash

# npm अपग्रेड के बाद निर्देश फ़ाइलें अपडेट करें
npm install -g @fission-ai/openspec@latest
openspec update

पहले पैकेज अपग्रेड करें। निर्देश फ़ाइलें इंस्टॉल किए गए CLI द्वारा जनरेट की जाती हैं, इसलिए पुरानी इंस्टॉलेशन के विरुद्ध openspec update चलाने पर सब कुछ अप-टू-डेट रिपोर्ट करता है बिना नए रिलीज़ के वर्कफ़्लो जोड़े।

इसे स्पष्ट करने के लिए, openspec update npm रजिस्ट्री से पूछता है कि क्या नया CLI प्रकाशित किया गया है। जब आपका पीछे है, तो यह अपग्रेड का प्रस्ताव देता है:

text

A newer OpenSpec CLI is available (v1.6.0 → v1.7.0).
  Running from: /usr/local/lib/node_modules/@fission-ai/openspec
? Upgrade to v1.7.0 now? (Y/n)

हाँ का उत्तर दें और यह npm install -g @fission-ai/openspec@latest चलाता है, फिर नए CLI के साथ अपडेट पुनः चलाता है ताकि नए वर्कफ़्लो उसी कमांड में आ जाएँ। यह अपग्रेड की पुष्टि इंस्टॉल किए गए बाइनरी से उसका वर्जन पूछकर करता है, npm के एग्ज़िट कोड पर भरोसा किए बिना, इसलिए यदि आपकी PATH पर पहले की कोई अन्य इंस्टॉलेशन अभी भी जवाब दे रही है, तो यह सफलता का दावा करने के बजाय आपको बताता है। नहीं का उत्तर दें और यह कमांड प्रिंट करता है और आपके पास जो CLI है उससे अपडेट करता है। Ctrl-C कमांड रोकता है।

यह प्रस्ताव केवल इंटरैक्टिव टर्मिनल में दिखाई देता है, और केवल तब जब npm इंस्टॉल का मालिक हो — वह एक ही मामला जहाँ npm install -g वास्तव में ठीक करता है। बाकी सबको उसी तरह से इंस्टॉल किया गया था उसी अनुसार कमांड मिलता है:

OpenSpec कैसे इंस्टॉल है	आपको क्या मिलता है
वैश्विक npm इंस्टॉल	इंटरैक्टिव टर्मिनल में प्रॉम्प्ट, और आपके लिए अपग्रेड चलाया जाता है; पाइप किया गया आउटपुट को प्रिंट की गई कमांड मिलती है
वैश्विक pnpm, bun, yarn, या volta इंस्टॉल	उस मैनेजर की अपनी कमांड: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest`, या `volta install …@latest`
परियोजना की निर्भरता	निर्भरता अपडेट करने का नोट, क्योंकि इसका पैकेज मैनेजर लॉकफ़ाइल का मालिक है
`npx` / `dlx` कैश	`npx @fission-ai/openspec@latest update` — वह कमांड ही अपडेट है, इसलिए दूसरा चरण नहीं है
git क्लोन	कुछ नहीं — आपका वर्जन ब्रांच जो कहती है वह है

जब भी कुछ प्रिंट होता है, यह उस डायरेक्टरी का नाम बताता है जिससे चल रहा CLI लोड किया गया था — वह चीज़ जो जाँचनी चाहिए जब आपने अपग्रेड किया है लेकिन पुरानी शिम अभी भी आपकी PATH की मालकिन है।

यह रजिस्ट्री से पूछता है जब npm npm_config_registry निर्यात करता है, अन्यथा https://registry.npmjs.org। कोई .npmrc पढ़ा नहीं जाता: फ़ाइल कंटेंट को आउटबाउंड अनुरोध कहाँ जाए यह चुनने देना एक ऐसा फ़्लो है जिसे टालना चाहिए, और परियोजना का .npmrc रिपॉज़िटरी के साथ चलता है। प्राइवेट मिरर पर, npm_config_registry निर्यात करें — या जाँच पूरी तरह छोड़ने के लिए OPENSPEC_NO_UPDATE_CHECK सेट करें। जाँच तब छोड़ी जाती है जब CI को स्पष्ट ऑफ-मान (false, 0, no, off, या खाली) के अलावा कुछ भी सेट किया गया हो, NODE_ENV=test के तहत, और जब भी OPENSPEC_NO_UPDATE_CHECK (कोई भी मान), DO_NOT_TRACK=1, या OPENSPEC_TELEMETRY=0 सेट हो। यह अपडेट से पहले चलता है और अधिकतम 1.5 सेकंड तक इसे देरी कर सकता है — यह तब भी उस समय के बाद हार मान लेता है जब नेटवर्क चुपचाप पैकेट ड्रॉप करता है, और जब रजिस्ट्री अप्राप्य हो तो चुप रहता है।

"अप-टू-डेट" कैसे तय किया जाता है: स्किल फ़ाइलें वह वर्जन रिकॉर्ड करती हैं जिसने उनका निर्माण किया, इसलिए OpenSpec उसे इंस्टॉल किए गए CLI से तुलना करता है। कमांड फ़ाइलों में कोई वर्जन स्टैम्प नहीं होता, इसलिए ऐसे टूल के लिए जिसके कमांड्स हैं लेकिन स्किल नहीं (डिलीवरी commands), OpenSpec फ़ाइल कंटेंट को उससे तुलना करता है जो यह अभी जनरेट करेगा — उन फ़ाइलों में संपादन ड्रिफ्ट के रूप में गिने जाते हैं और ओवरराइट किए जाते हैं。 डिलीवरी skills या both के साथ, केवल रिकॉर्ड किया गया वर्जन जाँचा जाता है, इसलिए हाथ से संपादित फ़ाइल जिसका वर्जन अभी भी मेल खाता है, उसे छूड़ा जाता है; इसे पुनः लिखने के लिए --force का उपयोग करें। दोनों तरह से, जनरेट की गई फ़ाइलें OpenSpec की हैं — अपने निर्देश कहीं और रखें।

स्टोर (स्टैंडअलोन OpenSpec रेपोज़)

बीटा। स्टोर और उन पर निर्मित सुविधाएँ (संदर्भ, कार्य संदर्भ, कार्यसेट) नई हैं; कमांड नाम, फ्लैग, फ़ाइल प्रारूप, और JSON आउटपुट रिलीज़ के बीच आकार बदल सकते हैं। समस्या-प्रथम वॉकथ्रू के लिए, स्टोर गाइड देखें।

स्टोर एक स्टैंडअलोन OpenSpec रेपो है जिसे आपने इस मशीन पर पंजीकृत किया है — उदाहरण के लिए एक योजना रेपो या अनुबंध रेपो। स्टोर को पंजीकृत करने से सामान्य कमांड (list, show, status, validate, new change, archive, ...) --store <id> पास करके कहीं से भी उस पर कार्य कर सकते हैं।

`openspec store setup`

एक स्थानीय स्टोर बनाएँ और पंजीकृत करें। टर्मिनल में बिना तर्कों के, OpenSpec उपयोगकर्ता को सेटअप के माध्यम से मार्गदर्शन करता है। एजेंट और स्क्रिप्ट्स को स्पष्ट इनपुट पास करने चाहिए और --json का उपयोग करना चाहिए।

bash

openspec store setup [id] [options]

विकल्प:

विकल्प	विवरण
`--path <path>`	वह फ़ोल्डर जहाँ स्टोर रहना चाहिए (उदाहरण के लिए `~/openspec/<id>`)
`--remote <url>`	नए स्टोर के `store.yaml` में कैननिकल रिमोट रिकॉर्ड करें
`--init-git`	एक Git रेपोज़िटरी को प्रारंभिक कमिट के साथ आरंभ करें (डिफ़ॉल्ट)
`--no-init-git`	हर Git क्रिया को छोड़ें: कोई init नहीं, कोई प्रारंभिक कमिट नहीं
`--json`	JSON आउटपुट करें

गैर-इंटरैक्टिव रन (--json, स्क्रिप्ट्स, एजेंट) को स्टोर आईडी और --path दोनों पास करने होंगे। एक इंटरैक्टिव टर्मिनल में, सेटअप स्थान के लिए एक दृश्यमान, उपयोगकर्ता-स्वामित्व वाले स्थान में एक संपादन योग्य सुझाव के साथ पूछता है (उदाहरण के लिए ~/openspec/<id>); यह कभी भी OpenSpec के प्रबंधित डेटा निर्देशिका पर डिफ़ॉल्ट नहीं होता है।

उदाहरण:

bash

openspec store setup
openspec store setup team-context
openspec store setup team-context --path ~/openspec/team-context --no-init-git
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json

`openspec store register`

एक मौजूदा स्थानीय स्टोर फ़ोल्डर को पंजीकृत करें। स्टोर बीटा के दौरान, एक रूट को तब भी पंजीकृत किया जा सकता है जब कोई बदलाव मौजूद न हों, स्पेक लागू किए गए हों, या बदलाव संग्रहीत किए गए हों; उस स्थिति में openspec/changes/, openspec/specs/, और openspec/changes/archive/ तब तक अनुपस्थित हो सकते हैं जब तक सामान्य कमांड उन्हें नहीं बनाते। एक केवल-कॉन्फ़िग रेपो जो store: <id> घोषित करता है वह दूसरे स्टोर के लिए एक पॉइंटर बना रहता है और उसे स्टोर रूट के रूप में पंजीकृत नहीं किया जाता है जब तक उस पॉइंटर को हटा नहीं दिया जाता।

bash

openspec store register [path] [options]

विकल्प:

विकल्प	विवरण
`--id <id>`	स्टोर आईडी; स्टोर मेटाडेटा या फ़ोल्डर नाम पर डिफ़ॉल्ट होता है
`--yes`	एक स्वस्थ OpenSpec रूट के लिए स्टोर पहचान मेटाडेटा बनाने की पुष्टि करें
`--json`	JSON आउटपुट करें

`openspec store unregister`

फ़ाइलों को हटाए बिना एक स्थानीय स्टोर पंजीकरण को भूल जाएँ।

bash

openspec store unregister <id> [--json]

इसका उपयोग तब करें जब कोई स्टोर स्थानांतरित किया गया हो, कहीं और क्लोन किया गया हो, या इस मशीन पर OpenSpec द्वारा अब नहीं दिखाया जाना चाहिए।

`openspec store remove`

स्थानीय स्टोर पंजीकरण को भूल जाएँ और उसका स्थानीय फ़ोल्डर हटा दें।

bash

openspec store remove <id> [--yes] [--json]

remove एक इंटरैक्टिव टर्मिनल में हटाने से पहले सटीक फ़ोल्डर दिखाता है। एजेंट, स्क्रिप्ट्स और JSON कॉलर्स को हटाने की पुष्टि करने के लिए --yes पास करना होगा। OpenSpec उस फ़ोल्डर को हटाने से मना कर देता है जिसमें मेल खाते स्टोर मेटाडेटा नहीं होता है।

`openspec store list`

स्थानीय रूप से पंजीकृत स्टोरों की सूची दिखाएँ।

bash

openspec store list [--json]
openspec store ls [--json]

`openspec store doctor`

स्थानीय स्टोर पंजीकरण, मेटाडेटा और Git उपस्थिति की जाँच करें।

bash

openspec store doctor [id] [--json]

डॉक्टर केवल निदान है; यह स्टोर को संशोधित किए बिना लापता रूट, मेटाडेटा बेमेल और अमान्य स्थानीय रजिस्ट्री स्थिति की रिपोर्ट करता है।

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

एक प्रोजेक्ट रेपो openspec/config.yaml में घोषित कर सकता है कि उसका काम किन स्टोरों पर आधारित है:

yaml

schema: spec-driven
references:
  - team-context

उसके बाद, उस रेपो में openspec instructions आउटपुट (प्रति-आर्टिफैक्ट और apply सतहों, JSON और मानव मोड दोनों) प्रत्येक संदर्भित स्टोर के स्पेक्स का एक सूचकांक रखता है — स्पेक आईडी, प्रत्येक स्पेक के Purpose अनुभाग से एक-पंक्ति सारांश, और फ़ेच कमांड (openspec show <spec-id> --type spec --store <id>)। सूचकांक प्रत्येक रन पर पंजीकृत चेकआउट से लाइव बनाया जाता है; स्पेक सामग्री कभी भी आउटपुट में कॉपी नहीं की जाती है।

संदर्भ केवल-पठनीय संदर्भ हैं। वे कभी नहीं बदलते कि कमांड कहाँ कार्य करते हैं: कार्य रेपो के अपने रूट में रहता है, और संदर्भित स्टोर में लिखना एक स्पष्ट --store क्रिया बनी रहती है। एक संदर्भ जो हल नहीं किया जा सकता (उदाहरण के लिए, इस मशीन पर पंजीकृत नहीं स्टोर) सटीक समाधान के साथ सूचकांक में चेतावनी में बदल जाता है, और निर्देश अभी भी उत्पन्न होते हैं। openspec doctor एक स्थान पर संदर्भ स्वास्थ्य की रिपोर्ट करता है।

स्टोर कहाँ से क्लोन किया गया है, यह रिकॉर्ड करना

एक स्टोर अपने कमिट किए गए पहचान फ़ाइल में अपने कैननिकल क्लोन स्रोत को रिकॉर्ड कर सकता है, ताकि ऑनबोर्डिंग कभी भी "स्टोर पंजीकृत करें" पर समाप्त न हो:

bash

openspec store setup team-context --path ~/openspec/team-context \
  --remote git@github.com:acme/team-context.git

रिमोट प्रारंभिक कमिट के अंदर .openspec-store/store.yaml में रहता है, इसलिए हर क्लोन उसे जानकर जन्म लेता है। एक मौजूदा स्टोर के लिए, store.yaml को हाथ से संपादित करें और कमिट करें। store doctor रिकॉर्ड किए गए रिमोट (और चेकआउट का देखा गया Git ओरिजिन) दिखाता है; सेटअप/रजिस्टर साझाकरण मार्गदर्शन उसका नाम बताता है; और रजिस्टर मशीन-स्थानीय रजिस्ट्री में चेकआउट के ओरिजिन को रिकॉर्ड करता है।

एक संदर्भ घोषणा क्लोन स्रोत भी ले जा सकती है, ताकि एक सहकर्मी जिसके पास स्टोर अभी तक नहीं है, उसे एक पूर्ण, पेस्ट करने योग्य समाधान मिले (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

references:
  - { id: team-context, remote: "git@github.com:acme/team-context.git" }

रिमोट रिकॉर्ड करना सिंक नहीं है: OpenSpec कभी भी स्वयं क्लोन, पुल या पुश नहीं करता है।

डिफ़ॉल्ट स्टोर घोषित करना

एक रेपो जिसकी योजना पूरी तरह से बाहरी है — कोई स्थानीय openspec/specs/ या openspec/changes/ नहीं — हर कमांड पर --store पास करने के बजाय अपने स्टोर को एक बार घोषित कर सकता है:

yaml

# openspec/config.yaml (openspec/ के अंतर्गत एकमात्र फ़ाइल)
store: team-context

सामान्य कमांड फिर घोषित स्टोर पर स्वचालित रूप से हल हो जाते हैं; रूट बैनर और JSON root ब्लॉक source: "declared" स्टोर आईडी के साथ रिपोर्ट करते हैं, और मुद्रित संकेत अभी भी --store <id> ले जाते हैं। घोषणा एक फॉलबैक है, कभी ओवरराइड नहीं: स्पष्ट --store हमेशा जीतता है, और वास्तविक योजना फ़ोल्डरों वाली निर्देशिका पॉइंटर को अनदेखा करती है (चेतावनी के साथ)। एक पॉइंटर रेपो को स्थानीय OpenSpec रूट में बदलने के लिए, store: पंक्ति को हटाएँ और openspec init चलाएँ — init घोषणा के मौजूद रहते हुए स्कैफोल्ड करने से मना करता है।

एक मशीन-स्तरीय वैरिएंट एक बार में हर रेपो को कवर करता है: openspec config set defaultStore <id> (कॉन्फ़िगरेशन देखें)। इससे परामर्श केवल तब लिया जाता है जब --store, एक स्थानीय रूट और एक प्रोजेक्ट पॉइंटर सभी हल करने में विफल हो गए हों; रूट बैनर और JSON root ब्लॉक तब source: "global_default" रिपोर्ट करते हैं।

डॉक्टर (संबंध स्वास्थ्य)

एक केवल-पठन प्रश्न, एक स्थान: क्या OpenSpec रूट स्वस्थ है, और क्या इस मशीन पर इसके द्वारा संदर्भित स्टोर उपलब्ध हैं?

bash

openspec doctor [--store <id>] [--json]

यह रिपोर्ट रूट स्वास्थ्य, स्टोर मेटाडेटा स्वास्थ्य (जिसमें एक नोट दिखता है जब रिकॉर्ड किया गया रिमोट और चेकआउट का origin अलग हो जाता है, और एक नोट जब स्टोर चेकआउट अपने अंतिम फ़ेच किए गए अपस्ट्रीम ट्रैकिंग रेफ़ से पीछे हो जाता है), और रेफ़रेंस स्वास्थ्य (वही डायग्नोस्टिक निर्देश दिखते हैं, अनसुलझे रेफ़रेंस के लिए क्लोन समाधान के साथ) को अलग-अलग बताती है। किसी भी गंभीरता की स्वास्थ्य खोजें 0 से बाहर निकलती हैं — एजेंट status arrays पढ़ते हैं; केवल कमांड विफलताएँ (कोई रूट नहीं, अज्ञात स्टोर) 1 से बाहर निकलती हैं। डॉक्टर कभी भी क्लोन, सिंक या मरम्मत नहीं करता। असेंबल किए गए सेट को उसके स्वास्थ्य के बजाय प्राप्त करने के लिए, openspec context का उपयोग करें।

कार्य-संदर्भ (असेंबल किया गया सेट)

इस कार्य से जुड़ी हर चीज़ OpenSpec घोषणाओं के माध्यम से, एक कार्य सेट में: OpenSpec रूट और वे स्टोर जिन्हें यह संदर्भित करता है।

bash

openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]

JSON संक्षिप्त जानकारी एजेंट-उपभोज्य है (प्रत्येक उपलब्ध संदर्भित स्टोर में उसका फ़ेच नुस्खा होता है; अनसुलझे सदस्यों में वही समाधान निर्देश और डॉक्टर दिखाए जाते हैं)। --code-workspace इसके अतिरिक्त एक VS Code कार्यक्षेत्र फ़ाइल लिखता है जिसमें रूट और उपलब्ध संदर्भित स्टोर (ref:<id> फ़ोल्डर) शामिल होते हैं — यह एकमात्र लेखन है जो यह कमांड करता है, यदि फ़ाइल मौजूद है तो --force के बिना मना कर दिया जाता है। अनुपलब्ध सदस्यों की रिपोर्ट की जाती है, कभी अनुमान नहीं लगाया जाता।

"कार्य-संदर्भ" असेंबल किया गया सेट है; openspec/config.yaml में context: फ़ील्ड परियोजना पृष्ठभूमि है जो निर्देशों में इंजेक्ट की जाती है — दो अलग चीज़ें। openspec doctor उत्तर देता है कि क्या सेट स्वस्थ है; openspec context उत्तर देता है कि सेट क्या है।

व्यक्तिगत कार्य-सेट

बीटा। कार्य-सेट नए बीटा सतह का हिस्सा हैं; कमांड, फ़्लैग और फ़ाइल प्रारूप रिलीज़ के बीच बदल सकते हैं। पूर्वाभ्यास के लिए, स्टोर गाइड देखें।

एक कार्य-सेट उन फ़ोल्डरों का एक व्यक्तिगत, नामित दृश्य है जिन पर आप एक साथ काम करते हैं — एक योजना रूट और आप जो भी चुनें — जो आपकी मशीन पर रखा जाता है और आपके उपकरण में नाम से पुनः खोला जाता है। यह पूरी तरह से स्थानीय है: कभी प्रतिबद्ध नहीं किया जाता, कभी साझा नहीं किया जाता, कभी घोषणाओं से व्युत्पन्न नहीं किया जाता, और किसी को हटाने से सदस्य फ़ोल्डर को कभी स्पर्श नहीं होता।

bash

openspec workset create [नाम] [--member <पथ> | --member <नाम>=<पथ>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <नाम> [--tool <id>]
openspec workset remove <नाम> [--yes] [--json]

create एक संक्षिप्त निर्देशित प्रवाह चलाता है (या गैर-सहभागी रूप से --member फ़्लैग लेता है; पहला सदस्य प्राथमिक होता है — सत्र वहीं से शुरू होते हैं)। open चुने हुए उपकरण को लॉन्च करता है: संपादक (VS Code, Cursor) एक विंडो खोलते हैं जिसमें हर सदस्य होता है और लौट जाते हैं; CLI एजेंट (Claude Code, codex) हर सदस्य को संलग्न करके और कोई प्रॉम्प्ट पूर्व-भरा हुए बिना इस टर्मिनल को एक सत्र के रूप में ले लेते हैं, जो आपके बाहर निकलने पर समाप्त होता है। खुलने के समय अनुपलब्ध सदस्य फ़ोल्डर को एक नोट के साथ छोड़ दिया जाता है; शेष खुलता है। सहेजी गई उपकरण प्राथमिकता प्रति खोलने पर --tool से अधिरोहित की जा सकती है।

किसी नए उपकरण का समर्थन कोड नहीं, कॉन्फ़िगरेशन है। हर उपकरण दो लॉन्च शैलियों में से एक है — workspace-file (उत्पन्न .code-workspace के साथ लॉन्च) या attach-dirs (प्रति सदस्य एक संलग्न करने का फ़्लैग) — और वैश्विक config.json में openers कुंजी (इसे openspec config edit से खोलें) उपकरण जोड़ती है या फ़ील्ड के अनुसार अंतर्निहित को समायोजित करती है:

json

{
  "openers": {
    "zed": { "style": "workspace-file" },
    "claude": { "attach_flag": "--dir" }
  }
}

सभी कार्य-सेट स्थिति वैश्विक डेटा निर्देशिका के worksets/ फ़ोल्डर के अंदर रहती है (सहेजे गए दृश्य और उत्पन्न <नाम>.code-workspace फ़ाइलें, हर खोलने पर पुनः उत्पन्न); उस फ़ोल्डर को हटाने से हर निशान मिट जाता है।

ब्राउज़िंग कमांड

`openspec list`

अपनी परियोजना में बदलाव या स्पेक्स सूचीबद्ध करें।

openspec list [विकल्प]

विकल्प:

विकल्प	विवरण
`--specs`	बदलावों के बजाय स्पेक्स सूचीबद्ध करें
`--changes`	बदलाव सूचीबद्ध करें (डिफ़ॉल्ट)
`--sort <क्रम>`	`recent` (डिफ़ॉल्ट) या `name` के अनुसार क्रमबद्ध करें
`--json`	JSON के रूप में आउटपुट

उदाहरण:

bash

# सभी सक्रिय बदलाव सूचीबद्ध करें
openspec list

# सभी स्पेक्स सूचीबद्ध करें
openspec list --specs

# स्क्रिप्ट के लिए JSON आउटपुट
openspec list --json

आउटपुट (पाठ):

Changes:
  add-dark-mode     No tasks      just now

`openspec view`

स्पेक्स और बदलावों का अन्वेषण करने के लिए एक सहभागी डैशबोर्ड दिखाएँ।

openspec view

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

`openspec show`

किसी बदलाव या स्पेक का विवरण दिखाएँ।

openspec show [आइटम-नाम] [विकल्प]

तर्क:

तर्क	आवश्यक	विवरण
`आइटम-नाम`	नहीं	बदलाव या स्पेक का नाम (यदि छोड़ा जाए तो संकेत दिया जाता है)

विकल्प:

विकल्प	विवरण
`--type <प्रकार>`	प्रकार निर्दिष्ट करें: `change` या `spec` (यदि असंदिग्ध हो तो स्वतः पता लगाया जाता है)
`--json`	JSON के रूप में आउटपुट
`--no-interactive`	संकेत अक्षम करें

बदलाव-विशिष्ट विकल्प:

विकल्प	विवरण
`--deltas-only`	केवल डेल्टा स्पेक्स दिखाएँ (JSON मोड)

स्पेक-विशिष्ट विकल्प:

विकल्प	विवरण
`--requirements`	केवल आवश्यकताएँ दिखाएँ, परिदृश्यों को बाहर रखें (JSON मोड)
`--no-scenarios`	परिदृश्य सामग्री को बाहर रखें (JSON मोड)
`-r, --requirement <id>`	1-आधारित सूचकांक द्वारा विशिष्ट आवश्यकता दिखाएँ (JSON मोड)

उदाहरण:

bash

# सहभागी चयन
openspec show

# एक विशिष्ट बदलाव दिखाएँ
openspec show add-dark-mode

# एक विशिष्ट स्पेक दिखाएँ
openspec show auth --type spec

# पार्सिंग के लिए JSON आउटपुट
openspec show add-dark-mode --json

सत्यापन कमांड्स

`openspec validate`

संरचनात्मक समस्याओं के लिए परिवर्तनों और स्पेक्स का सत्यापन करें, और परिवर्तन के MODIFIED आवश्यकताओं की जाँच उन मुख्य स्पेक्स के विरुद्ध करें जिन्हें वे प्रतिस्थापित करेंगे।

openspec validate [item-name] [options]

शून्य स्पेक डेल्टा वाले परिवर्तन सत्यापन में विफल हो जाते हैं, जब तक कि उसका .openspec.yaml skip_specs: true घोषित न करे (शुद्ध रीफैक्टर, टूलिंग, या दस्तावेज़ीकरण कार्य के लिए — देखें Recipe 5)।

तर्क:

तर्क	आवश्यक	विवरण
`item-name`	नहीं	सत्यापित करने के लिए विशिष्ट आइटम (छोड़ा जाने पर प्रॉम्प्ट होगा)

विकल्प:

विकल्प	विवरण
`--all`	सभी परिवर्तनों और स्पेक्स का सत्यापन करें
`--changes`	सभी परिवर्तनों का सत्यापन करें
`--specs`	सभी स्पेक्स का सत्यापन करें
`--archived`	सत्यापित करें कि आर्काइव किए गए परिवर्तनों में सभी कार्य पूर्ण हैं (प्री-कमिट लींटिंग के लिए)
`--type <type>`	जब नाम अस्पष्ट हो तो प्रकार निर्दिष्ट करें: `change` या `spec`
`--strict`	कठोर सत्यापन मोड सक्षम करें
`--json`	JSON के रूप में आउटपुट करें
`--concurrency <n>`	अधिकतम समानांतर सत्यापन (डिफ़ॉल्ट: 6, या `OPENSPEC_CONCURRENCY` env)
`--no-interactive`	प्रॉम्प्ट्स निष्क्रिय करें

--archived अपना स्वयं का दायरा है: यह स्पेक डेल्टा का सत्यापन नहीं करता (आर्काइव समय पर पहले से लागू हो चुके हैं), यह सत्यापित करता है कि changes/archive/ के तहत हर परिवर्तन के सभी tasks.md चेकबॉक्स टिके हुए हैं, यदि कोई अनचेक्ड है तो गैर-शून्य स्थिति के साथ बाहर निकलता है। यह उन परिवर्तनों को पकड़ता है जो अधूरे कार्य के साथ आर्काइव किए गए थे — प्री-कमिट हुक में उपयोगी।

उदाहरण:

bash

# इंटरैक्टिव सत्यापन
openspec validate

# विशिष्ट परिवर्तन का सत्यापन करें
openspec validate add-dark-mode

# सभी परिवर्तनों का सत्यापन करें
openspec validate --changes

# JSON आउटपुट के साथ सब कुछ सत्यापित करें (CI/स्क्रिप्ट्स के लिए)
openspec validate --all --json

# बढ़े हुए समानांतरता के साथ कठोर सत्यापन
openspec validate --all --strict --concurrency 12

# यदि कोई आर्काइव परिवर्तन अभी भी अनचेक्ड कार्य रखता है तो विफल करें
openspec validate --archived

आउटपुट (टेक्स्ट):

Validating add-dark-mode...
  ✓ proposal.md valid
  ✓ specs/ui/spec.md valid
  ⚠ design.md: missing "Technical Approach" section

1 warning found

आउटपुट (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: missing 'Technical Approach' section"]
      }
    ]
  },
  "summary": {
    "total": 1,
    "valid": 1,
    "invalid": 0
  }
}

जीवनचक्र कमांड्स

`openspec archive`

पूर्ण किए गए परिवर्तन को आर्काइव करें और डेल्टा स्पेक्स को मुख्य स्पेक्स में मर्ज करें。

openspec archive [change-name] [options]

तर्क:

तर्क	आवश्यक	विवरण
`change-name`	नहीं	आर्काइव करने के लिए परिवर्तन (छोड़ा जाने पर प्रॉम्प्ट होगा; आवश्यक जब कुछ भी प्रॉम्प्ट का उत्तर नहीं दे सकता)

विकल्प:

विकल्प	विवरण
`-y, --yes`	पुष्टि प्रॉम्प्ट्स छोड़ें। आवश्यक जब कुछ भी उनका उत्तर नहीं दे सकता — एक AI एजेंट, CI जॉब, या stdin बंद होने वाला कोई भी रन
`--skip-specs`	एक आर्काइव रन के लिए स्पेक अपडेट छोड़ें। ऐसा परिवर्तन जो स्थायी रूप से कोई स्पेक डेल्टा नहीं रखता, इसके बजाय अपने `.openspec.yaml` में `skip_specs: true` घोषित करे — यह बिना किसी फ्लैग के आर्काइव होता है
`--no-validate`	सत्यापन छोड़ें (पुष्टि आवश्यक)। साथ ही क्षमता रिटायरमेंट भी निष्क्रिय करता है — बिना सत्यापक निर्णय के, कुछ भी रिटायर्ड नहीं होता

उदाहरण:

bash

# इंटरैक्टिव आर्काइव (पूछता किन परिवर्तन का, फिर पुष्टि करता है)
openspec archive

# विशिष्ट परिवर्तन आर्काइव करें
openspec archive add-dark-mode

# बिना प्रॉम्प्ट्स के आर्काइव करें (एजेंट्स, CI, स्क्रिप्ट्स)
openspec archive add-dark-mode --yes

# ऐसा टूलिंग परिवर्तन आर्काइव करें जो स्पेक्स को प्रभावित नहीं करता
openspec archive update-ci-config --skip-specs

क्षमता रिटायर करें: परिवर्तन मेटाडेटा में रिटायरमेंट मार्कर जोड़ें:

yaml

# openspec/changes/retire-legacy/.openspec.yaml
schema: spec-driven
retire_capabilities: true

फिर सामान्य रूप से परिवर्तन आर्काइव करें:

bash

openspec archive retire-legacy --yes

जब परिवर्तन क्षमता की अंतिम आवश्यकता हटाता है, OpenSpec उसका लाइव spec.md हटा देता है। उसी परिवर्तन में अन्य क्षमता डेल्टा अभी भी अपने मुख्य स्पेक्स अपडेट करते हैं। बिना मार्कर के, आर्काइव किसी भी फ़ाइल को बदलने से पहले रुक जाता है और आपको इसे जोड़ने के लिए बताता है।

यह क्या करता है:

परिवर्तन का सत्यापन करता है (जब तक --no-validate न हो)
पुष्टि के लिए प्रॉम्प्ट करता है (जब तक --yes न हो)
किसी भी मुख्य स्पेक को बदलने से पहले आर्काइव गंतव्य का दावा करता है
सक्रिय डेल्टा स्पेक्स का सत्यापन करता है और उन्हें openspec/specs/ में मर्ज करता है — ऐसी क्षमता जिसकी अंतिम आवश्यकता परिवर्तन हटाता है, वह रिटायर्ड हो जाती है और उसका स्पेक फ़ाइल हटा दिया जाता है, लेकिन केवल तभी जब परिवर्तन का .openspec.yaml अपने schema: के पास retire_capabilities: true घोषित करता है
परिवर्तन फ़ोल्डर को openspec/changes/archive/YYYY-MM-DD-<name>/ में ले जाता है
यदि पूर्ण आर्काइव सुरक्षित होने से पहले स्पेक परिवर्तन या अंतिम स्थानांतरण विफल हो जाता है, तो स्पेक्स पुनर्स्थापित करता है और परिवर्तन को उसके सक्रिय पथ पर छोड़ता या लौटाता है
यदि सत्यापित फॉलबैक कॉपी पूर्ण हो जाती है लेकिन स्टेज्ड-सोर्स क्लीनअप विफल हो जाता है, तो पुनर्स्थापना के लिए पूर्ण आर्काइव और कमीट किया गया स्पेक स्थिति बनाए रखता है

बिना टर्मिनल के: एक AI एजेंट, CI जॉब, या stdin बंद होने वाला कोई भी रन स्टेप 2 का उत्तर नहीं दे सकता, इसलिए आर्काइव कुछ भी छूने से पहले रुक जाता है, 1 स्थिति के साथ बाहर निकलता है, और पुनः चलाने के लिए कमांड का नाम बताता है — openspec archive <name> --yes, जो भी अन्य फ्लैग आपने पास किए थे। राउंड ट्रिप छोड़ने के लिए आगे से --yes (और परिवर्तन का नाम) पास करें।

वर्कफ़्लो कमांड्स

ये कमांड्स आर्टिफैक्ट-संचालित OPSX वर्कफ़्लो का समर्थन करते हैं। ये मनुष्यों के लिए प्रगति जाँचने और एजेंटों के लिए अगले कदम निर्धारित करने दोनों के लिए उपयोगी हैं।

`openspec new change`

समाधान किए गए OpenSpec रूट में एक चेंज निर्देशिका और वैकल्पिक चेक-इन मेटाडेटा बनाएँ।

bash

openspec new change <name> [options]

चेंज नामों में lowercase kebab-case का उपयोग करना चाहिए: छोटे अक्षर, संख्याएँ और एकल हाइफ़न। उनमें स्पेस, अंडरस्कोर, बड़े अक्षर, लगातार हाइफ़न, या आरंभिक/अंतिम हाइफ़न नहीं हो सकते। एक अग्रणी संख्या की अनुमति है, इसलिए आप नामों को क्रम या स्तर देने के लिए उपसर्ग लगा सकते हैं, उदाहरण के लिए 100-add-feature या 00001-add-auth।

विकल्प:

Option	Description
`--description <text>`	`index.md` में जोड़ने के लिए विवरण
`--goal <text>`	चेंज के साथ संग्रहीत करने के लिए वैकल्पिक लक्ष्य मेटाडेटा
`--schema <name>`	उपयोग करने के लिए वर्कफ़्लो स्कीमा
`--store <id>`	OpenSpec रूट के रूप में उपयोग करने के लिए स्टोर id (स्टोर एक स्टैंडअलोन OpenSpec रेपो है जिसे आपने पंजीकृत किया है)
`--json`	JSON आउटपुट करें

उदाहरण:

bash

openspec new change add-billing-api
openspec new change add-billing-api --store team-context --json

`openspec status`

किसी चेंज के लिए आर्टिफैक्ट पूर्णता स्थिति प्रदर्शित करें।

openspec status [options]

विकल्प:

Option	Description
`--change <id>`	चेंज नाम (छोड़े जाने पर संकेत देता है)
`--schema <name>`	स्कीमा ओवरराइड (चेंज के कॉन्फ़िग से स्वतः पता लगाया जाता है)
`--json`	JSON के रूप में आउटपुट करें

उदाहरण:

bash

# इंटरैक्टिव स्थिति जाँच
openspec status

# विशिष्ट चेंज के लिए स्थिति
openspec status --change add-dark-mode

# एजेंट उपयोग के लिए JSON
openspec status --change add-dark-mode --json

आउटपुट (पाठ):

Change: add-dark-mode
Schema: spec-driven
Progress: 2/4 artifacts complete

[x] proposal
[x] specs
[ ] design
[-] tasks (blocked by: design)

एक चेंज जो skip_specs: true घोषित करता है, वह अपने स्पेक्स चरण को [~] specs (skipped: change declares skip_specs) के रूप में दिखाता है और इसे प्रगति गणना से बाहर रखता है।

आउटपुट (JSON):

json

{
  "changeName": "add-dark-mode",
  "schemaName": "spec-driven",
  "isPlanningComplete": false,
  "isComplete": false,
  "applyRequires": ["tasks"],
  "artifacts": [
    {"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
    {"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
    {"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
    {"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
  ]
}

isPlanningComplete रिपोर्ट करता है कि क्या प्रत्येक गैर-छोड़ा गया नियोजन आर्टिफैक्ट मौजूद है; छोड़े गए आर्टिफैक्ट बिना बनाए संतुष्ट माने जाते हैं। यह रिपोर्ट नहीं करता कि कार्यान्वयन कार्य पूर्ण हैं। isComplete को समान मान के साथ संगतता उपनाम के रूप में बनाए रखा गया है।

आर्टिफैक्ट निर्भरता क्रम में सूचीबद्ध होते हैं - एक निर्भरता उस चीज़ के बाद कभी नहीं आती जिसके लिए उसकी आवश्यकता होती है - और जो आर्टिफैक्ट एक ही समय में तैयार होते हैं (spec-driven के specs और design दोनों को केवल proposal की आवश्यकता होती है) वे स्कीमा द्वारा घोषित क्रम को बनाए रखते हैं, न कि वर्णानुक्रम में। इसलिए पहली ready प्रविष्टि वह आर्टिफैक्ट है जिसे आगे लिखा जाना चाहिए।

`openspec instructions`

किसी आर्टिफैक्ट को बनाने या कार्यों को लागू करने के लिए समृद्ध निर्देश प्राप्त करें। AI एजेंटों द्वारा यह समझने के लिए उपयोग किया जाता है कि आगे क्या बनाना है।

openspec instructions [artifact] [options]

तर्क:

Argument	Required	Description
`artifact`	नहीं	आर्टिफैक्ट ID, या वर्कफ़्लो इनपुट सतह: `apply` या `archive`

विकल्प:

Option	Description
`--change <id>`	चेंज नाम (गैर-इंटरैक्टिव मोड में आवश्यक)
`--schema <name>`	स्कीमा ओवरराइड
`--json`	JSON के रूप में आउटपुट करें

विशेष मामले: apply का उपयोग कार्य कार्यान्वयन निर्देश प्राप्त करने के लिए करें। archive का उपयोग किसी मान्य चेंज के लिए वर्तमान, केवल-पढ़ने योग्य आर्काइव इनपुट (context और operationGuidance) प्राप्त करने के लिए करें; यह कुछ भी आर्काइव या बदलाव नहीं करता है।

उदाहरण:

bash

# अगले आर्टिफैक्ट के लिए निर्देश प्राप्त करें
openspec instructions --change add-dark-mode

# विशिष्ट आर्टिफैक्ट निर्देश प्राप्त करें
openspec instructions design --change add-dark-mode

# apply/कार्यान्वयन निर्देश प्राप्त करें
openspec instructions apply --change add-dark-mode

# बिना आर्काइव किए वर्तमान आर्काइव संचालन इनपुट प्राप्त करें
openspec instructions archive --change add-dark-mode --json

# एजेंट उपभोग के लिए JSON
openspec instructions design --change add-dark-mode --json

आउटपुट में शामिल है:

आर्टिफैक्ट के लिए टेम्पलेट सामग्री
कॉन्फ़िग से प्रोजेक्ट संदर्भ
निर्भरता आर्टिफैक्ट से सामग्री
कॉन्फ़िग से प्रति-आर्टिफैक्ट नियम
apply/archive के लिए वर्तमान प्रोजेक्ट संदर्भ और मिलान संचालन मार्गदर्शन

संचालन इनपुट हर आह्वान पर समाधान किए गए रेपो या चयनित स्टोर से पढ़े जाते हैं। प्रोजेक्ट संदर्भ एक आवश्यक प्रॉम्प्ट-स्तरीय इनपुट है: एजेंट इसे पढ़ते हैं और प्रासंगिक प्रोजेक्ट तथ्यों, परंपराओं और बाधाओं को लागू करते हैं। संचालन मार्गदर्शन वैकल्पिक योगात्मक सलाह है: एजेंट प्रत्येक प्रविष्टि पर विचार करते हैं और केवल उन प्रविष्टियों का पालन करते हैं जो लागू होती हैं और अंतर्निहित वर्कफ़्लो के साथ संगत होती हैं। दोनों फ़ील्ड स्पष्ट उपयोगकर्ता विकल्पों, CLI-नियंत्रित स्थिति, अंतर्निहित निर्देशों और आर्टिफैक्ट नियमों से अलग रहते हैं। विरोधाभासी संदर्भ रिपोर्ट किया जाता है; विरोधाभासी या अनुपयुक्त मार्गदर्शन का पालन नहीं किया जाता और कारण समझाया जाता है। ये जनरेट किए गए एजेंटों के लिए व्यवहारिक अनुबंध हैं, लागू करने योग्य CLI जाँच नहीं। instructions archive केवल चयनित चेंज, वैकल्पिक इनपुट और रूट मेटाडेटा लौटाता है; इसमें स्थिर आर्काइव वर्कफ़्लो शामिल नहीं है।

skip_specs: true के माध्यम से छोड़े गए आर्टिफैक्ट के लिए, आउटपुट केवल एक चेतावनी है (JSON में skipped/warning फ़ील्ड जोड़े जाते हैं) — आर्टिफैक्ट नहीं बनाया जाना चाहिए।

`openspec templates`

किसी स्कीमा में सभी आर्टिफैक्ट के लिए समाधान किए गए टेम्पलेट पथ दिखाएँ।

openspec templates [options]

विकल्प:

Option	Description
`--schema <name>`	जाँचने के लिए स्कीमा (डिफ़ॉल्ट: `spec-driven`)
`--json`	JSON के रूप में आउटपुट करें

उदाहरण:

bash

# डिफ़ॉल्ट स्कीमा के लिए टेम्पलेट पथ दिखाएँ
openspec templates

# कस्टम स्कीमा के लिए टेम्पलेट दिखाएँ
openspec templates --schema my-workflow

# प्रोग्रामेटिक उपयोग के लिए JSON
openspec templates --json

आउटपुट (पाठ):

Schema: spec-driven

Templates:
  proposal  → ~/.openspec/schemas/spec-driven/templates/proposal.md
  specs     → ~/.openspec/schemas/spec-driven/templates/specs.md
  design    → ~/.openspec/schemas/spec-driven/templates/design.md
  tasks     → ~/.openspec/schemas/spec-driven/templates/tasks.md

`openspec schemas`

उपलब्ध वर्कफ़्लो स्कीमा को उनके विवरण और आर्टिफैक्ट प्रवाह के साथ सूचीबद्ध करें।

openspec schemas [options]

विकल्प:

Option	Description
`--json`	JSON के रूप में आउटपुट करें
`--store <id>`	OpenSpec रूट के रूप में पंजीकृत स्टोर का उपयोग करें

उदाहरण:

bash

openspec schemas

आउटपुट:

Available schemas:

  spec-driven (package)
    The default spec-driven development workflow
    Flow: proposal → specs → design → tasks

  my-custom (project)
    Custom workflow for this project
    Flow: research → proposal → tasks

स्कीमा कमांड्स

कस्टम वर्कफ़्लो स्कीमा बनाने और प्रबंधित करने के लिए कमांड्स।

`openspec schema init`

नया प्रोजेक्ट-स्थानीय स्कीमा बनाएँ।

openspec schema init <name> [options]

तर्क:

तर्क	आवश्यक	विवरण
`name`	हाँ	स्कीमा का नाम (kebab-case)

विकल्प:

विकल्प	विवरण
`--description <text>`	स्कीमा का विवरण
`--artifacts <list>`	कॉमा-पृथक आर्टिफैक्ट आईडी (डिफ़ॉल्ट: `proposal,specs,design,tasks`)
`--default`	प्रोजेक्ट डिफ़ॉल्ट स्कीमा के रूप में सेट करें
`--no-default`	डिफ़ॉल्ट सेट करने के लिए संकेत न दें
`--force`	मौजूदा स्कीमा को अधिलेखित करें
`--json`	JSON के रूप में आउटपुट दें

उदाहरण:

bash

# इंटरैक्टिव स्कीमा निर्माण
openspec schema init research-first

# विशिष्ट आर्टिफैक्ट्स के साथ गैर-इंटरैक्टिव
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

यह क्या बनाता है:

openspec/schemas/<name>/
├── schema.yaml           # स्कीमा परिभाषा
└── templates/
    ├── proposal.md       # प्रत्येक आर्टिफैक्ट के लिए टेम्पलेट
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

अनुकूलन के लिए किसी मौजूदा स्कीमा को अपने प्रोजेक्ट में कॉपी करें।

openspec schema fork <source> [name] [options]

तर्क:

तर्क	आवश्यक	विवरण
`source`	हाँ	कॉपी करने के लिए स्कीमा
`name`	नहीं	नया स्कीमा नाम (डिफ़ॉल्ट: `<source>-custom`)

विकल्प:

विकल्प	विवरण
`--force`	मौजूदा गंतव्य को अधिलेखित करें
`--json`	JSON के रूप में आउटपुट दें

उदाहरण:

bash

# बिल्ट-इन spec-driven स्कीमा को फोर्क करें
openspec schema fork spec-driven my-workflow

`openspec schema validate`

किसी स्कीमा की संरचना और टेम्पलेट्स को मान्य करें।

openspec schema validate [name] [options]

तर्क:

तर्क	आवश्यक	विवरण
`name`	नहीं	मान्य करने के लिए स्कीमा (छोड़ने पर सभी मान्य हो जाते हैं)

विकल्प:

विकल्प	विवरण
`--verbose`	विस्तृत मान्यता चरण दिखाएँ
`--json`	JSON के रूप में आउटपुट दें

उदाहरण:

bash

# एक विशिष्ट स्कीमा मान्य करें
openspec schema validate my-workflow

# सभी स्कीमा मान्य करें
openspec schema validate

`openspec schema which`

दिखाएँ कि एक स्कीमा कहाँ से हल होता है (पूर्वता डिबग करने के लिए उपयोगी)।

openspec schema which [name] [options]

तर्क:

तर्क	आवश्यक	विवरण
`name`	नहीं	स्कीमा का नाम

विकल्प:

विकल्प	विवरण
`--all`	सभी स्कीमा को उनके स्रोतों के साथ सूचीबद्ध करें
`--json`	JSON के रूप में आउटपुट दें

उदाहरण:

bash

# देखें कि एक स्कीमा कहाँ से आता है
openspec schema which spec-driven

आउटपुट:

spec-driven resolves from: package
  Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

स्कीमा पूर्वता:

प्रोजेक्ट: openspec/schemas/<name>/
उपयोगकर्ता: ~/.local/share/openspec/schemas/<name>/
पैकेज: बिल्ट-इन स्कीमा

कॉन्फ़िगरेशन कमांड्स

`openspec config`

वैश्विक OpenSpec कॉन्फ़िगरेशन देखें और संशोधित करें।

openspec config <subcommand> [options]

उपकमांड्स:

उपकमांड	विवरण
`path`	कॉन्फ़िग फ़ाइल का स्थान दिखाएँ
`list`	सभी वर्तमान सेटिंग्स दिखाएँ
`get <key>`	कोई विशिष्ट मान प्राप्त करें
`set <key> <value>`	एक मान सेट करें
`unset <key>`	एक कुंजी हटाएँ
`reset`	डिफ़ॉल्ट पर रीसेट करें
`edit`	`$EDITOR` में खोलें
`profile [preset]`	वर्कफ़्लो प्रोफ़ाइल इंटरैक्टिव रूप से या प्रीसेट के माध्यम से कॉन्फ़िगर करें

उदाहरण:

bash

# कॉन्फ़िग फ़ाइल का पथ दिखाएँ
openspec config path

# सभी सेटिंग्स सूचीबद्ध करें
openspec config list

# एक विशिष्ट मान प्राप्त करें
openspec config get telemetry.enabled

# एक मान सेट करें (अनाम उपयोग टेलीमेट्री अक्षम करें)
openspec config set telemetry.enabled false

# एक स्ट्रिंग मान स्पष्ट रूप से सेट करें
openspec config set user.name "My Name" --string

# एक कस्टम सेटिंग हटाएँ
openspec config unset user.name

# मशीन-स्तरीय डिफ़ॉल्ट स्टोर सेट करें (जब कोई --store न हो, स्थानीय रूट, या प्रोजेक्ट स्टोर: पॉइंटर हल करता है) तो फ़ॉलबैक रूट
openspec config set defaultStore team-plans

# सभी कॉन्फ़िगरेशन रीसेट करें
openspec config reset --all --yes

# अपने एडिटर में कॉन्फ़िग संपादित करें
openspec config edit

# एक्शन-आधारित विज़ार्ड के साथ प्रोफ़ाइल कॉन्फ़िगर करें
openspec config profile

# त्वरित प्रीसेट: वर्कफ़्लो को कोर में बदलें (डिलीवरी मोड रखता है)
openspec config profile core

टेलीमेट्री ऑप्ट-आउट: telemetry.enabled सेट न किए जाने पर डिफ़ॉल्ट रूप से चालू रहता है (ऑप्ट-आउट मॉडल)। इसे अक्षम करने के लिए false पर सेट करें ताकि अनाम उपयोग आँकड़े और openspec update संस्करण जाँच बंद हो जाए। पर्यावरण चर कॉन्फ़िग पर प्राथमिकता लेते हैं: OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, और एक सत्य (truthy) CI मान (जैसे true/1/yes) हमेशा टेलीमेट्री को कॉन्फ़िग मान से परे अक्षम करता है।

openspec config profile वर्तमान स्थिति सारांश के साथ शुरू होता है, फिर आपको चयन करने देता है:

डिलीवरी + वर्कफ़्लो बदलें
केवल डिलीवरी बदलें
केवल वर्कफ़्लो बदलें
वर्तमान सेटिंग्स रखें (बाहर निकलें)

यदि आप वर्तमान सेटिंग्स रखते हैं, तो कोई परिवर्तन नहीं लिखा जाता और कोई अद्यतन संकेत नहीं दिखाया जाता। यदि कोई कॉन्फ़िग परिवर्तन नहीं हैं लेकिन वर्तमान प्रोजेक्ट फ़ाइलें आपके वैश्विक प्रोफ़ाइल/डिलीवरी के साथ समकालिक (sync) नहीं हैं, तो OpenSpec एक चेतावनी दिखाएगा और openspec update सुझाएगा। Ctrl+C दबाने से भी प्रवाह सफाई से रद्द हो जाता है (कोई स्टैक ट्रेस नहीं) और कोड 130 के साथ बाहर निकलता है। वर्कफ़्लो चेकलिस्ट में, [x] का अर्थ है कि वर्कफ़्लो वैश्विक कॉन्फ़िग में चयनित है। उन चयनों को प्रोजेक्ट फ़ाइलों पर लागू करने के लिए, openspec update चलाएँ (या प्रोजेक्ट के अंदर संकेत मिलने पर Apply changes to this project now? चुनें)।

इंटरैक्टिव उदाहरण:

bash

# केवल डिलीवरी अद्यतन
openspec config profile
# चुनें: केवल डिलीवरी बदलें
# डिलीवरी चुनें: केवल स्किल्स

# केवल वर्कफ़्लो अद्यतन
openspec config profile
# चुनें: केवल वर्कफ़्लो बदलें
# चेकलिस्ट में वर्कफ़्लो टॉगल करें, फिर पुष्टि करें

उपयोगिता कमांड्स

`openspec feedback`

OpenSpec के बारे में प्रतिक्रिया सबमिट करें। एक GitHub मुद्दा बनाता है।

openspec feedback <message> [options]

तर्क:

तर्क	आवश्यक	विवरण
`message`	हाँ	प्रतिक्रिया सारांश; लंबा पाठ मुद्दा शीर्षक में छोटा किया जाता है और बॉडी में संरक्षित रहता है

विकल्प:

विकल्प	विवरण
`--body <text>`	सारांश के बाद शामिल अतिरिक्त विवरण

आवश्यकताएँ: GitHub CLI (gh) स्थापित और प्रमाणित होना चाहिए।

उदाहरण:

bash

openspec feedback "Add support for custom artifact types" \
  --body "I'd like to define my own artifact types beyond the built-in ones."

`openspec completion`

OpenSpec CLI के लिए शेल कंप्लीशन प्रबंधित करें।

openspec completion <subcommand> [shell]

उपकमांड्स:

उपकमांड	विवरण
`generate [shell]`	stdout पर कंप्लीशन स्क्रिप्ट आउटपुट करें
`install [shell]`	अपने शेल के लिए कंप्लीशन स्थापित करें
`uninstall [shell]`	स्थापित कंप्लीशन हटाएँ

समर्थित शेल: bash, zsh, fish, powershell

उदाहरण:

bash

# कंप्लीशन स्थापित करें (शेल स्वतः पहचानता है)
openspec completion install

# विशिष्ट शेल के लिए स्थापित करें
openspec completion install zsh

# मैन्युअल स्थापना के लिए स्क्रिप्ट उत्पन्न करें (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# स्थापना रद्द करें
openspec completion uninstall

विंडोज़ (PowerShell): वर्तमान PowerShell होस्ट के लिए कंप्लीशन स्थापित करें:

powershell

$env:PROFILE = $PROFILE
openspec completion install powershell
. $PROFILE

$env:PROFILE OpenSpec को बताता है कि इस सत्र में कौन सी प्रोफ़ाइल कॉन्फ़िगर करनी है। इंस्टॉलर लापता प्रोफ़ाइल निर्देशिकाएँ बनाता है और एक प्रबंधित ब्लॉक जोड़ता है जो OpenSpecCompletion.ps1 को लोड करता है। प्रोफ़ाइल को पुनः लोड करने से कंप्लीशन तुरंत सक्षम हो जाते हैं।

वर्तमान होस्ट से स्थापना रद्द करने के लिए, चलाएँ:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

स्थापना रद्द करने के बाद वर्तमान सत्र से कंप्लीशन साफ़ करने के लिए PowerShell पुनः प्रारंभ करें।

कंप्लीशन ऑप्ट-इन हैं। CLI केवल एक बार, stderr पर, एक इंटरैक्टिव टर्मिनल में कमांड चलाने के पहली बार उनका उल्लेख करता है, और फिर कभी नहीं — यदि आपके पास पहले से कंप्लीशन स्थापित हैं तो यह शांत भी रहता है। उस टिप को पूरी तरह से दबाने के लिए OPENSPEC_NO_COMPLETIONS=1 सेट करें।

निकास कोड

कोड	अर्थ
`0`	सफलता
`1`	त्रुटि (मान्यता विफलता, लापता फ़ाइलें, आदि)

पर्यावरण चर

चर	विवरण
`OPENSPEC_TELEMETRY`	`0` पर सेट करने से टेलीमेट्री और `openspec update` संस्करण जाँच अक्षम हो जाती है (वैश्विक कॉन्फ़िग में `telemetry.enabled` को ओवरराइड करता है)
`DO_NOT_TRACK`	`1` पर सेट करने से टेलीमेट्री और `openspec update` संस्करण जाँच अक्षम हो जाती है (मानक DNT संकेत; कॉन्फ़िग को ओवरराइड करता है)
`OPENSPEC_CONCURRENCY`	बल्क मान्यता के लिए डिफ़ॉल्ट समवर्ती (डिफ़ॉल्ट: 6)
`EDITOR` या `VISUAL`	`openspec config edit` के लिए संपादक
`NO_COLOR`	सेट करने पर रंग आउटपुट अक्षम करें
`OPENSPEC_NO_ANIMATION`	सेट करने पर `openspec init` स्वागत एनीमेशन अक्षम करें
`OPENSPEC_NO_COMPLETIONS`	शेल कंप्लीशन के बारे में एक बार की टिप को दबाने के लिए `1` पर सेट करें
`OPENSPEC_NO_UPDATE_CHECK`	सेट करने पर (कोई भी मान, खाली सहित) नए प्रकाशित CLI के लिए `openspec update` जाँच अक्षम करें। `CI` सेट होने पर भी छोड़ दिया जाता है (जब तक `false`/`0`/`no`/`off` न हो) या `NODE_ENV=test` होने पर भी
`npm_config_registry`	`openspec update` संस्करण जाँच के लिए पूछा जाने वाला रजिस्ट्री। `http(s)` URL होना चाहिए या यह `https://registry.npmjs.org` पर वापस आ जाता है। कोई `.npmrc` फ़ाइल नहीं पढ़ी जाती है

CLI संदर्भ ​

सारांश ​

मानव बनाम एजेंट कमांड्स ​

केवल मानव कमांड्स ​

एजेंट-संगत कमांड्स ​

वैश्विक विकल्प ​

सेटअप कमांड्स ​

openspec init ​

openspec update ​

स्टोर (स्टैंडअलोन OpenSpec रेपोज़) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

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

स्टोर कहाँ से क्लोन किया गया है, यह रिकॉर्ड करना ​

डिफ़ॉल्ट स्टोर घोषित करना ​

डॉक्टर (संबंध स्वास्थ्य) ​

कार्य-संदर्भ (असेंबल किया गया सेट) ​

व्यक्तिगत कार्य-सेट ​

ब्राउज़िंग कमांड ​

openspec list ​

openspec view ​

openspec show ​

सत्यापन कमांड्स ​

openspec validate ​

जीवनचक्र कमांड्स ​

openspec archive ​

वर्कफ़्लो कमांड्स ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

स्कीमा कमांड्स ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

कॉन्फ़िगरेशन कमांड्स ​

openspec config ​

उपयोगिता कमांड्स ​

openspec feedback ​

openspec completion ​

निकास कोड ​

पर्यावरण चर ​

संबंधित दस्तावेज़ ​

CLI संदर्भ

सारांश

मानव बनाम एजेंट कमांड्स

केवल मानव कमांड्स

एजेंट-संगत कमांड्स

वैश्विक विकल्प

सेटअप कमांड्स

`openspec init`

`openspec update`

स्टोर (स्टैंडअलोन OpenSpec रेपोज़)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

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

स्टोर कहाँ से क्लोन किया गया है, यह रिकॉर्ड करना

डिफ़ॉल्ट स्टोर घोषित करना

डॉक्टर (संबंध स्वास्थ्य)

कार्य-संदर्भ (असेंबल किया गया सेट)

व्यक्तिगत कार्य-सेट

ब्राउज़िंग कमांड

`openspec list`

`openspec view`

`openspec show`

सत्यापन कमांड्स

`openspec validate`

जीवनचक्र कमांड्स

`openspec archive`

वर्कफ़्लो कमांड्स

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

स्कीमा कमांड्स

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

कॉन्फ़िगरेशन कमांड्स

`openspec config`

उपयोगिता कमांड्स

`openspec feedback`

`openspec completion`

निकास कोड

पर्यावरण चर

संबंधित दस्तावेज़