CLI संदर्भ
OpenSpec CLI (openspec) परियोजना सेटअप, सत्यापन (validation), स्थिति निरीक्षण और प्रबंधन के लिए टर्मिनल कमांड प्रदान करता है। ये कमांड्स Commands में प्रलेखित AI स्लैश कमांड्स (जैसे /opsx:propose) को पूरक करते हैं।
सारांश
| Category | Commands | Purpose |
|---|---|---|
| Setup | init, update | आपके प्रोजेक्ट में OpenSpec को इनिशियलाइज़ और अपडेट करें। |
| Stores (standalone OpenSpec repos) | store setup, store register, store unregister, store remove, store list, store doctor | स्टोर का प्रबंधन करें — वे स्टैंडअलोन OpenSpec रिपॉजिटरी जिन्हें आपने पंजीकृत किया है। |
| Health | doctor | हल किए गए रूट के लिए संबंध स्वास्थ्य की रिपोर्ट करें। |
| Working context | context | वर्किंग सेट को इकट्ठा करें (रूट + संदर्भित स्टोर)। |
| Personal worksets | workset create, workset list, workset open, workset remove | अपने टूल में व्यक्तिगत, स्थानीय वर्किंग व्यू रखें और खोलें। |
| Browsing | list, view, show | परिवर्तनों और स्पेसिफिकेशन्स का अन्वेषण करें। |
| Validation | validate | समस्याओं के लिए परिवर्तनों और स्पेसिफिकेशन्स की जाँच करें। |
| Lifecycle | archive | पूर्ण किए गए परिवर्तनों को अंतिम रूप दें। |
| Workflow | new change, status, instructions, templates, schemas | आर्टिफैक्ट-संचालित वर्कफ़्लो समर्थन। |
| Schemas | schema init, schema fork, schema validate, schema which | कस्टम वर्कफ़्लो बनाएं और प्रबंधित करें। |
| Config | config | सेटिंग्स देखें और संशोधित करें। |
| Utility | feedback, completion | प्रतिक्रिया (Feedback) और शेल एकीकरण। |
मानव बनाम एजेंट कमांड्स
अधिकांश 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 |
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> | रेपो-स्थानीय बदलाव का ढांचा बनाएं | एक पंजीकृत स्टोर को OpenSpec रूट के रूप में उपयोग करने के लिए --json, साथ ही --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, sync, archive।
openspec init [path] [options]आर्गुमेंट्स:
| आर्गुमेंट | आवश्यक | विवरण |
|---|---|---|
path | नहीं | लक्ष्य निर्देशिका (डिफ़ॉल्ट: वर्तमान निर्देशिका) |
विकल्प्स:
| विकल्प | विवरण |
|---|---|
--tools <list> | AI टूल को गैर-इंटरैक्टिव रूप से कॉन्फ़िगर करें। all, none, या कॉमा-सेपरेटेड सूची का उपयोग करें |
--force | प्रॉम्प्ट के बिना विरासत फ़ाइलों की ऑटो-क्लीनअप करें |
--profile <profile> | इस init रन के लिए ग्लोबल प्रोफ़ाइल को ओवरराइड करें (core या custom) |
--profile custom ग्लोबल कॉन्फ़िग में वर्तमान में चयनित वर्कफ्लो का उपयोग करता है (openspec config profile)।
समर्थित टूल IDs (--tools): amazon-q, antigravity, auggie, bob, claude, cline, codex, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, iflow, junie, kilocode, kimi, kiro, lingma, vibe, opencode, pi, qoder, qwen, roocode, trae, windsurf
यह सूची
src/core/config.tsमेंAI_TOOLSको दर्शाती है। प्रत्येक टूल के कौशल और कमांड पाथ के लिए Supported Tools देखें।
उदाहरण:
bash
# इंटरैक्टिव इनिशियलाइज़ेशन
openspec init
# एक विशिष्ट निर्देशिका में इनिशियलाइज़ करें
openspec init ./my-project
# गैर-इंटरैक्टिव: Claude और Cursor के लिए कॉन्फ़िगर करें
openspec init --tools claude,cursor
# सभी समर्थित टूल के लिए कॉन्फ़िगर करें
openspec init --tools all
# इस रन के लिए प्रोफ़ाइल को ओवरराइड करें
openspec init --profile core
# प्रॉम्प्ट छोड़ें और विरासत फ़ाइलों की ऑटो-क्लीनअप करें
openspec init --forceयह क्या बनाता है:
openspec/
├── specs/ # आपके स्पेसिफिकेशन्स (सत्य का स्रोत)
├── changes/ # प्रस्तावित बदलाव
└── config.yaml # प्रोजेक्ट कॉन्फ़िगरेशन
.claude/skills/ # Claude कोड कौशल (यदि claude चुना गया है)
.cursor/skills/ # Cursor कौशल (यदि cursor चुना गया है)
.cursor/commands/ # Cursor OPSX कमांड्स (यदि डिलीवरी में कमांड शामिल हैं)
... (अन्य टूल कॉन्फ़िग्स)openspec update
CLI को अपग्रेड करने के बाद OpenSpec निर्देश फ़ाइलों को अपडेट करें। आपके वर्तमान ग्लोबल प्रोफ़ाइल, चयनित वर्कफ्लो और डिलीवरी मोड का उपयोग करके AI टूल कॉन्फ़िगरेशन फ़ाइलों को पुन: उत्पन्न करता है।
openspec update [path] [options]आर्गुमेंट्स:
| आर्गुमेंट | आवश्यक | विवरण |
|---|---|---|
path | नहीं | लक्ष्य निर्देशिका (डिफ़ॉल्ट: वर्तमान निर्देशिका) |
विकल्प्स:
| विकल्प | विवरण |
|---|---|
--force | फ़ाइलें अद्यतन होने पर भी जबरन अपडेट करें |
उदाहरण:
bash
# npm अपग्रेड के बाद निर्देश फ़ाइलों को अपडेट करें
npm update @fission-ai/openspec
openspec updateस्टोर्स (स्टैंडअलोन OpenSpec रेपो)
बीटा। स्टोर और उन पर निर्मित सुविधाएँ (संदर्भ, कार्य संदर्भ, वर्कसेट्स) नई हैं; कमांड के नाम, फ़्लैग, फ़ाइल प्रारूप और JSON आउटपुट रिलीज़ के बीच आकार बदल सकते हैं। समस्या-पहले वाले वॉकथ्रू के लिए, stores guide देखें।
एक स्टोर एक स्टैंडअलोन 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, स्क्रिप्ट्स, एजेंट) दोनों स्टोर id और --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 --jsonopenspec store register
एक मौजूदा स्थानीय स्टोर फ़ोल्डर को रजिस्टर करें।
bash
openspec store register [path] [options]विकल्प्स:
| विकल्प | विवरण |
|---|---|
--id <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 और मानव मोड) प्रत्येक संदर्भित स्टोर के स्पेसिफिकेशन्स का एक इंडेक्स रखता है — स्पेसिफिकेशन IDs, प्रत्येक Spec के Purpose अनुभाग से एक पंक्ति का सारांश, और फेच कमांड (openspec show <spec-id> --type spec --store <id>)। यह इंडेक्स हर रन पर पंजीकृत चेकआउट से लाइव बनाया जाता है; Spec सामग्री को कभी भी आउटपुट में कॉपी नहीं किया जाता है।
संदर्भ केवल रीड-ओनली संदर्भ होते हैं। वे कभी भी उस जगह को नहीं बदलते जहाँ कमांड कार्य करते हैं: काम रेपो के अपने रूट में रहता है, और एक संदर्भित स्टोर में लिखना अभी भी एक स्पष्ट --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 ब्लॉक स्टोर id के साथ source: "declared" की रिपोर्ट करते हैं, और प्रिंटेड संकेत अभी भी --store <id> ले जाते हैं। घोषणा एक फॉलबैक है, कभी ओवरराइड नहीं: स्पष्ट --store हमेशा जीतता है, और वास्तविक प्लानिंग फ़ोल्डरों वाली निर्देशिका पॉइंटर को अनदेखा करती है (एक चेतावनी के साथ)। एक पॉइंटर रेपो को स्थानीय OpenSpec रूट में बदलने के लिए, store: लाइन हटा दें और openspec init चलाएँ — घोषणा मौजूद होने पर init scaffolding से इनकार करता है।
डॉक्टर (रिलेशनशिप स्वास्थ्य)
एक रीड-ओनली प्रश्न, एक जगह: क्या OpenSpec रूट स्वस्थ है, और क्या यह जिन स्टोर्स को संदर्भित करता है वे इस मशीन पर उपलब्ध हैं?
bash
openspec doctor [--store <id>] [--json]रिपोर्ट रूट स्वास्थ्य, स्टोर मेटाडेटा स्वास्थ्य (जिसमें रिकॉर्ड किए गए रिमोट और चेकआउट की उत्पत्ति के भिन्न होने पर एक नोट शामिल होता है), और रेफरेंस स्वास्थ्य को अलग करती है (अनिर्धारित संदर्भों के लिए क्लोन फिक्स के साथ समान डायग्नोस्टिक्स निर्देश दिखाते हैं)। किसी भी गंभीरता की स्वास्थ्य खोज 0 से बाहर निकलती है—एजेंट्स status एरे पढ़ते हैं; केवल कमांड विफलताएं (कोई रूट नहीं, अज्ञात स्टोर) 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 उत्तर देता है कि सेट क्या है।
व्यक्तिगत वर्कसेट
बीटा। वर्कसेट नए बीटा सतह का हिस्सा हैं; रिलीज़ के बीच कमांड, फ्लैग और फ़ाइल फॉर्मेट बदल सकते हैं। वॉकथ्रू के लिए, stores guide देखें।
एक वर्कसेट आपके द्वारा एक साथ काम की जाने वाली फ़ोल्डरों का व्यक्तिगत, नाम वाला दृश्य है — यह आपकी मशीन पर रखा जाता है और आपके टूल में नाम से फिर से खोला जाता है, जिसमें एक प्लानिंग रूट और आपके द्वारा चुना गया अन्य तत्व शामिल होता है। यह पूरी तरह से स्थानीय है: इसे कभी कमिट नहीं किया जाता, कभी साझा नहीं किया जाता, घोषणाओं से प्राप्त नहीं किया जाता, और इसे हटाना किसी सदस्य फ़ोल्डर को कभी नहीं छूता।
bash
openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--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/ फ़ोल्डर के तहत रहती है (सहेजे गए दृश्य और जनरेटेड <name>.code-workspace फाइलें, जो हर ओपन पर रीजनरेट होती हैं); उस फ़ोल्डर को हटाने से इसका हर निशान मिट जाता है।
ब्राउजिंग कमांड्स
openspec list
अपने प्रोजेक्ट में बदलाव या स्पेसिफिकेशन्स की सूची देखें।
openspec list [options]विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--specs | बदलावों के बजाय स्पेसिफिकेशन्स की सूची दें |
--changes | बदलावों की सूची दें (डिफ़ॉल्ट) |
--sort <order> | recent (डिफ़ॉल्ट) या name द्वारा सॉर्ट करें |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Examples):
bash
# सभी सक्रिय बदलावों की सूची दें
openspec list
# सभी स्पेसिफिकेशन्स की सूची दें
openspec list --specs
# स्क्रिप्ट के लिए JSON आउटपुट
openspec list --jsonआउटपुट (पाठ/text):
Changes:
add-dark-mode No tasks just nowopenspec view
स्पेसिफिकेशन्स और बदलावों को एक्सप्लोर करने के लिए एक इंटरैक्टिव डैशबोर्ड प्रदर्शित करें।
openspec viewयह आपके प्रोजेक्ट की स्पेसिफिकेशन्स और बदलावों को नेविगेट करने के लिए एक टर्मिनल-आधारित इंटरफ़ेस खोलता है।
openspec show
किसी बदलाव या स्पेसिफिकेशन का विवरण प्रदर्शित करें।
openspec show [item-name] [options]आर्ग्युमेंट्स (Arguments):
| आर्ग्युमेंट | आवश्यक | विवरण |
|---|---|---|
item-name | नहीं | बदलाव या स्पेसिफिकेशन का नाम (यदि छोड़ा जाता है तो प्रॉम्प्ट करता है) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--type <type> | प्रकार निर्दिष्ट करें: change या spec (यदि अस्पष्ट नहीं है तो ऑटो-डिटेक्ट किया गया) |
--json | JSON के रूप में आउटपुट करें |
--no-interactive | प्रॉम्प्ट अक्षम करें |
चेंज-विशिष्ट विकल्प (Change-specific options):
| विकल्प | विवरण |
|---|---|
--deltas-only | केवल डेल्टा स्पेसिफिकेशन्स दिखाएं (JSON मोड) |
स्पेसिफिकेशन-विशिष्ट विकल्प (Spec-specific options):
| विकल्प | विवरण |
|---|---|
--requirements | केवल आवश्यकताएँ दिखाएं, परिदृश्य को बाहर करें (JSON मोड) |
--no-scenarios | परिदृश्य सामग्री को बाहर करें (JSON मोड) |
-r, --requirement <id> | 1-आधारित इंडेक्स द्वारा विशिष्ट आवश्यकता दिखाएं (JSON मोड) |
उदाहरण (Examples):
bash
# इंटरैक्टिव चयन
openspec show
# एक विशिष्ट बदलाव दिखाएँ
openspec show add-dark-mode
# एक विशिष्ट स्पेसिफिकेशन दिखाएँ
openspec show auth --type spec
# पार्सिंग के लिए JSON आउटपुट
openspec show add-dark-mode --jsonसत्यापन कमांड्स (Validation Commands)
openspec validate
संरचनात्मक समस्याओं के लिए बदलावों और स्पेसिफिकेशन्स को मान्य करें।
openspec validate [item-name] [options]आर्ग्युमेंट्स (Arguments):
| आर्ग्युमेंट | आवश्यक | विवरण |
|---|---|---|
item-name | नहीं | विशिष्ट आइटम जिसे मान्य करना है (यदि छोड़ा जाता है तो प्रॉम्प्ट करता है) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--all | सभी बदलावों और स्पेसिफिकेशन्स को मान्य करें |
--changes | सभी बदलावों को मान्य करें |
--specs | सभी स्पेसिफिकेशन्स को मान्य करें |
--type <type> | नाम अस्पष्ट होने पर प्रकार निर्दिष्ट करें: change या spec |
--strict | सख्त सत्यापन मोड सक्षम करें |
--json | JSON के रूप में आउटपुट करें |
--concurrency <n> | अधिकतम समानांतर सत्यापन (डिफ़ॉल्ट: 6, या OPENSPEC_CONCURRENCY env) |
--no-interactive | प्रॉम्प्ट अक्षम करें |
उदाहरण (Examples):
bash
# इंटरैक्टिव सत्यापन
openspec validate
# एक विशिष्ट बदलाव को मान्य करें
openspec validate add-dark-mode
# सभी बदलावों को मान्य करें
openspec validate --changes
# CI/स्क्रिप्ट के लिए JSON आउटपुट के साथ सब कुछ मान्य करें
openspec validate --all --json
# बढ़ी हुई समानांतरता के साथ सख्त सत्यापन
openspec validate --all --strict --concurrency 12आउटपुट (पाठ/text):
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
}
}लाइफसाइकिल कमांड्स (Lifecycle Commands)
openspec archive
एक पूर्ण किए गए बदलाव को संग्रहीत करें और डेल्टा स्पेसिफिकेशन्स को मुख्य स्पेसिफिकेशन्स में मर्ज करें।
openspec archive [change-name] [options]आर्ग्युमेंट्स (Arguments):
| आर्ग्युमेंट | आवश्यक | विवरण |
|---|---|---|
change-name | नहीं | संग्रहीत करने के लिए बदलाव (यदि छोड़ा जाता है तो प्रॉम्प्ट करता है) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
-y, --yes | पुष्टिकरण प्रॉम्प्ट को छोड़ दें |
--skip-specs | स्पेसिफिकेशन अपडेट को छोड़ें (इंफ्रास्ट्रक्चर/टूलिंग/doc-only बदलावों के लिए) |
--no-validate | सत्यापन को छोड़ दें (पुष्टि की आवश्यकता है) |
उदाहरण (Examples):
bash
# इंटरैक्टिव आर्काइव
openspec archive
# विशिष्ट बदलाव संग्रहीत करें
openspec archive add-dark-mode
# प्रॉम्प्ट के बिना संग्रहीत करें (CI/स्क्रिप्ट)
openspec archive add-dark-mode --yes
# एक टूलिंग बदलाव को संग्रहीत करें जो स्पेसिफिकेशन्स को प्रभावित नहीं करता है
openspec archive update-ci-config --skip-specsयह क्या करता है:
- बदलाव को मान्य करता है (जब तक कि
--no-validateन हो) - पुष्टिकरण के लिए प्रॉम्प्ट करता है (जब तक कि
--yesन हो) - डेल्टा स्पेसिफिकेशन्स को
openspec/specs/में मर्ज करता है - चेंज फ़ोल्डर को
openspec/changes/archive/YYYY-MM-DD-<name>/में ले जाता है
वर्कफ़्लो कमांड्स (Workflow Commands)
ये कमांड्स आर्टिफैक्ट-संचालित OPSX वर्कफ़्लो का समर्थन करते हैं। ये मनुष्यों द्वारा प्रगति की जाँच करने और एजेंटों द्वारा अगले चरणों को निर्धारित करने दोनों के लिए उपयोगी हैं।
openspec new change
रिज़ॉल्व्ड OpenSpec रूट में एक बदलाव डायरेक्टरी और वैकल्पिक चेक-इन मेटाडेटा बनाएँ।
bash
openspec new change <name> [options]विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--description <text> | index.md में जोड़ने के लिए विवरण |
--goal <text> | बदलाव के साथ संग्रहीत करने के लिए वैकल्पिक लक्ष्य मेटाडेटा |
--schema <name> | उपयोग करने के लिए वर्कफ़्लो स्कीमा |
--store <id> | OpenSpec रूट के रूप में उपयोग करने के लिए स्टोर id (एक स्टोर एक स्टैंडअलोन OpenSpec रेपो है जिसे आपने पंजीकृत किया है) |
--json | JSON आउटपुट करें |
उदाहरण (Examples):
bash
openspec new change add-billing-api
openspec new change add-billing-api --store team-context --jsonopenspec status
एक बदलाव के लिए आर्टिफैक्ट पूर्णता स्थिति प्रदर्शित करें।
openspec status [options]विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--change <id> | बदलाव का नाम (यदि छोड़ा जाता है तो प्रॉम्प्ट करता है) |
--schema <name> | स्कीमा ओवरराइड (बदलाव की कॉन्फ़िगरेशन से ऑटो-डिटेक्ट किया गया) |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Examples):
bash
# इंटरैक्टिव स्टेटस चेक
openspec status
# विशिष्ट बदलाव के लिए स्थिति
openspec status --change add-dark-mode
# एजेंट उपयोग के लिए JSON
openspec status --change add-dark-mode --jsonआउटपुट (पाठ/text):
Change: add-dark-mode
Schema: spec-driven
Progress: 2/4 artifacts complete
[x] proposal
[ ] design
[x] specs
[-] tasks (blocked by: design)आउटपुट (JSON):
json
{
"changeName": "add-dark-mode",
"schemaName": "spec-driven",
"isComplete": false,
"applyRequires": ["tasks"],
"artifacts": [
{"id": "proposal", "outputPath": "proposal.md", "status": "done"},
{"id": "design", "outputPath": "design.md", "status": "ready"},
{"id": "specs", "outputPath": "specs/**/*.md", "status": "done"},
{"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "missingDeps": ["design"]}
]
}openspec instructions
एक आर्टिफैक्ट बनाने या कार्य लागू करने के लिए समृद्ध निर्देश प्राप्त करें। इसका उपयोग AI एजेंटों द्वारा यह समझने के लिए किया जाता है कि आगे क्या बनाना है।
openspec instructions [artifact] [options]आर्ग्युमेंट्स (Arguments):
| आर्ग्युमेंट | आवश्यक | विवरण |
|---|---|---|
artifact | नहीं | आर्टिफैक्ट ID: proposal, specs, design, tasks, या apply |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--change <id> | बदलाव का नाम (गैर-इंटरैक्टिव मोड में आवश्यक) |
--schema <name> | स्कीमा ओवरराइड |
--json | JSON के रूप में आउटपुट करें |
विशेष मामला: टास्क कार्यान्वयन निर्देश प्राप्त करने के लिए apply का उपयोग आर्टिफैक्ट के रूप में करें।
उदाहरण (Examples):
bash
# अगले आर्टिफैक्ट के लिए निर्देश प्राप्त करें
openspec instructions --change add-dark-mode
# विशिष्ट आर्टिफैक्ट निर्देश प्राप्त करें
openspec instructions design --change add-dark-mode
# लागू/कार्यान्वयन निर्देश प्राप्त करें
openspec instructions apply --change add-dark-mode
# एजेंट उपभोग के लिए JSON
openspec instructions design --change add-dark-mode --jsonआउटपुट में शामिल है:
- आर्टिफैक्ट के लिए टेम्पलेट सामग्री
- कॉन्फ़िगरेशन से प्रोजेक्ट संदर्भ
- निर्भरता आर्टिफैक्ट्स से सामग्री
- कॉन्फ़िगरेशन से प्रति-आर्टिफैक्ट नियम
openspec templates
एक स्कीमा में सभी आर्टिफैक्ट्स के लिए हल किए गए टेम्पलेट पाथ प्रदर्शित करें।
openspec templates [options]विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--schema <name> | निरीक्षण करने के लिए स्कीमा (डिफ़ॉल्ट: spec-driven) |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Examples):
bash
# डिफ़ॉल्ट स्कीमा के लिए टेम्पलेट पाथ दिखाएँ
openspec templates
# कस्टम स्कीमा के लिए टेम्पलेट दिखाएँ
openspec templates --schema my-workflow
# प्रोग्रामेटिक उपयोग के लिए JSON
openspec templates --jsonआउटपुट (पाठ/text):
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.mdopenspec schemas
उनके विवरण और आर्टिफैक्ट फ्लो के साथ उपलब्ध वर्कफ़्लो स्कीमा की सूची दें।
openspec schemas [options]विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Example):
bash
openspec schemasआउटपुट:
Available schemas:
spec-driven (package)
डिफ़ॉल्ट spec-driven विकास वर्कफ़्लो
फ्लो: proposal → specs → design → tasks
my-custom (project)
इस प्रोजेक्ट के लिए कस्टम वर्कफ़्लो
फ्लो: research → proposal → tasksस्कीमा कमांड्स (Schema Commands)
कस्टम कार्यप्रवाह स्कीमा बनाने और प्रबंधित करने के लिए आदेश।
openspec schema init
एक नया प्रोजेक्ट-स्थानीय स्कीमा बनाएँ।
openspec schema init <name> [options]तर्क (Arguments):
| तर्क | आवश्यक | विवरण |
|---|---|---|
name | हाँ | स्कीमा का नाम (kebab-case) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--description <text> | स्कीमा का विवरण |
--artifacts <list> | अल्पविराम से अलग किए गए आर्टिफैक्ट IDs (डिफ़ॉल्ट: proposal,specs,design,tasks) |
--default | प्रोजेक्ट डिफ़ॉल्ट स्कीमा के रूप में सेट करें |
--no-default | डिफ़ॉल्ट के रूप में सेट करने के लिए प्रॉम्प्ट न करें |
--force | मौजूदा स्कीमा को ओवरराइट करें |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Examples):
bash
# इंटरैक्टिव स्कीमा निर्माण
openspec schema init research-first
# विशिष्ट आर्टिफैक्ट्स के साथ नॉन-इंटरैक्टिव
openspec schema init rapid \
--description "Rapid iteration workflow" \
--artifacts "proposal,tasks" \
--defaultयह क्या बनाता है (What it creates):
openspec/schemas/<name>/
├── schema.yaml # स्कीमा परिभाषा
└── templates/
├── proposal.md # प्रत्येक आर्टिफैक्ट के लिए टेम्पलेट
├── specs.md
├── design.md
└── tasks.mdopenspec schema fork
कस्टमाइज़ेशन के लिए किसी मौजूदा स्कीमा को अपने प्रोजेक्ट में कॉपी करें।
openspec schema fork <source> [name] [options]तर्क (Arguments):
| तर्क | आवश्यक | विवरण |
|---|---|---|
source | हाँ | कॉपी करने के लिए स्कीमा |
name | नहीं | नया स्कीमा नाम (डिफ़ॉल्ट: <source>-custom) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--force | मौजूदा गंतव्य को ओवरराइट करें |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Example):
bash
# इनबिल्ट spec-driven स्कीमा को फोर्क करना
openspec schema fork spec-driven my-workflowopenspec schema validate
एक स्कीमा की संरचना और टेम्पलेट्स को सत्यापित (validate) करता है।
openspec schema validate [name] [options]तर्क (Arguments):
| तर्क | आवश्यक | विवरण |
|---|---|---|
name | नहीं | सत्यापित करने के लिए स्कीमा (यदि छोड़ा गया तो सभी को सत्यापित किया जाता है) |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--verbose | विस्तृत सत्यापन चरण दिखाएँ |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Example):
bash
# एक विशिष्ट स्कीमा को सत्यापित करना
openspec schema validate my-workflow
# सभी स्कीमाओं को सत्यापित करना
openspec schema validateopenspec schema which
यह दिखाने के लिए कि कोई स्कीमा कहाँ से हल होती है (प्राथमिकता की डीबगिंग में उपयोगी)।
openspec schema which [name] [options]तर्क (Arguments):
| तर्क | आवश्यक | विवरण |
|---|---|---|
name | नहीं | स्कीमा का नाम |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--all | उनके स्रोतों के साथ सभी स्कीमाओं को सूचीबद्ध करें |
--json | JSON के रूप में आउटपुट करें |
उदाहरण (Example):
bash
# जाँच करना कि कोई स्कीमा कहाँ से आती है
openspec schema which spec-drivenआउटपुट:
spec-driven resolves from: package
Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-drivenस्कीमा प्राथमिकता (Schema precedence):
- प्रोजेक्ट:
openspec/schemas/<name>/ - उपयोगकर्ता (User):
~/.local/share/openspec/schemas/<name>/ - पैकेज: इनबिल्ट स्कीमा
कॉन्फ़िगरेशन कमांड्स (Configuration Commands)
openspec config
ग्लोबल OpenSpec कॉन्फ़िगरेशन को देखें और संशोधित करें।
openspec config <subcommand> [options]उप-कमांड्स (Subcommands):
| उप-कमांड | विवरण |
|---|---|
path | कॉन्फ़िग फ़ाइल का स्थान दिखाएँ |
list | सभी वर्तमान सेटिंग्स दिखाएँ |
get <key> | एक विशिष्ट मान प्राप्त करें |
set <key> <value> | एक मान सेट करें |
unset <key> | एक कुंजी हटाएँ |
reset | डिफ़ॉल्ट पर रीसेट करें |
edit | $EDITOR में खोलें |
profile [preset] | इंटरैक्टिव रूप से या प्रीसेट के माध्यम से कार्यप्रवाह प्रोफ़ाइल कॉन्फ़िगर करें |
उदाहरण (Examples):
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
# सभी कॉन्फ़िगरेशन रीसेट करें
openspec config reset --all --yes
# अपने एडिटर में कॉन्फ़िग संपादित करें
openspec config edit
# एक्शन-आधारित विज़ार्ड के साथ प्रोफ़ाइल कॉन्फ़िगर करें
openspec config profile
# तेज़ प्रीसेट: वर्कफ़्लो को कोर पर स्विच करें (डिलीवरी मोड बनाए रखता है)
openspec config profile coreopenspec config profile एक वर्तमान-स्थिति सारांश से शुरू होता है, फिर आपको चुनने देता है:
- डिलीवरी + कार्यप्रवाह बदलें
- केवल डिलीवरी बदलें
- केवल कार्यप्रवाह बदलें
- वर्तमान सेटिंग्स रखें (बाहर निकलें)
यदि आप वर्तमान सेटिंग्स रखते हैं, तो कोई परिवर्तन नहीं लिखे जाते और न ही अपडेट प्रॉम्प्ट दिखाया जाता है। यदि कोई कॉन्फ़िग परिवर्तन नहीं है लेकिन वर्तमान प्रोजेक्ट फ़ाइलें आपके ग्लोबल प्रोफ़ाइल/डिलीवरी के साथ असमान हैं, तो OpenSpec एक चेतावनी दिखाएगा और openspec update का सुझाव देगा। Ctrl+C दबाने से भी प्रवाह को साफ तौर पर रद्द (कोई स्टैक ट्रेस नहीं) कर दिया जाता है और कोड 130 के साथ बाहर निकल जाता है। कार्यप्रवाह चेकलिस्ट में, [x] का मतलब है कि वर्कफ़्लो ग्लोबल कॉन्फ़िग में चुना गया है। इन चयन को प्रोजेक्ट फ़ाइलों पर लागू करने के लिए, openspec update चलाएँ (या प्रोजेक्ट के अंदर प्रॉम्प्ट होने पर Apply changes to this project now? चुनें)।
इंटरैक्टिव उदाहरण:
bash
# केवल डिलीवरी अपडेट
openspec config profile
# चुनें: केवल डिलीवरी बदलें
# चुनें डिलीवरी: स्किल्स ही
# कार्यप्रवाह-केवल अपडेट
openspec config profile
# चुनें: केवल कार्यप्रवाह बदलें
# चेकलिस्ट में वर्कफ़्लो टॉगल करें, फिर पुष्टि करेंयूटिलिटी कमांड्स (Utility Commands)
openspec feedback
OpenSpec के बारे में प्रतिक्रिया सबमिट करें। एक GitHub इशू बनाएँ।
openspec feedback <message> [options]तर्क (Arguments):
| तर्क | आवश्यक | विवरण |
|---|---|---|
message | हाँ | प्रतिक्रिया संदेश |
विकल्प (Options):
| विकल्प | विवरण |
|---|---|
--body <text> | विस्तृत विवरण |
आवश्यकताएँ: GitHub CLI (gh) स्थापित और प्रमाणित होना चाहिए।
उदाहरण (Example):
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]उप-कमांड्स (Subcommands):
| उप-कमांड | विवरण |
|---|---|
generate [shell] | stdout पर कंप्लीशन स्क्रिप्ट आउटपुट करें |
install [shell] | आपके शेल के लिए कंप्लीशन स्थापित करें |
uninstall [shell] | स्थापित कंप्लीशन्स हटाएँ |
समर्थित शेल (Supported shells): bash, zsh, fish, powershell
उदाहरण (Examples):
bash
# कंप्लीशन्स स्थापित करना (शेल का पता लगाता है)
openspec completion install
# विशिष्ट शेल के लिए स्थापित करें
openspec completion install zsh
# मैन्युअल इंस्टॉलेशन के लिए स्क्रिप्ट जनरेट करना
openspec completion generate bash > ~/.bash_completion.d/openspec
# अनइंस्टॉल करना
openspec completion uninstallएग्जिट कोड्स (Exit Codes)
| कोड | अर्थ |
|---|---|
0 | सफलता (Success) |
1 | त्रुटि (Error) (सत्यापन विफलता, फ़ाइलें गुम होना, आदि।) |
एनवायरनमेंट वैरिएबल्स (Environment Variables)
| वेरिएबल | विवरण |
|---|---|
OPENSPEC_TELEMETRY | टेलीमेट्री को अक्षम करने के लिए 0 पर सेट करें |
DO_NOT_TRACK | टेलीमेट्री को अक्षम करने के लिए 1 पर सेट करें (मानक DNT सिग्नल) |
OPENSPEC_CONCURRENCY | बल्क सत्यापन के लिए डिफ़ॉल्ट समवर्तीता (डिफ़ॉल्ट: 6) |
EDITOR या VISUAL | openspec config edit के लिए एडिटर |
NO_COLOR | सेट होने पर रंग आउटपुट को अक्षम करें |
संबंधित दस्तावेज़ीकरण (Related Documentation)
- Commands - AI स्लैश कमांड्स (
/opsx:propose,/opsx:apply, आदि।) - Workflows - सामान्य पैटर्न और प्रत्येक कमांड का उपयोग कब करना है
- Customization - कस्टम स्कीमा और टेम्पलेट्स बनाएँ
- Getting Started - पहली बार सेटअप गाइड