CLI

openspec टर्मिनल कमांड्स।

कमांड्स

सेट अप

कमांड	यह क्या करता है
`openspec init`	प्रोजेक्ट में OpenSpec को इनिशियलाइज़ करें।
`openspec update`	OpenSpec की इंस्टॉल की गई निर्देश फ़ाइलों को अपडेट करें।
`openspec config`	वैश्विक कॉन्फ़िगरेशन देखें और बदलें।

परिवर्तन और स्पेक्स

कमांड	यह क्या करता है
`openspec list`	परिवर्तनों, या `--specs` के साथ स्पेक्स को सूचीबद्ध करें।
`openspec show`	किसी परिवर्तन या स्पेक को markdown या JSON के रूप में प्रिंट करें।
`openspec view`	स्पेक्स और परिवर्तनों का एक-स्क्रीन डैशबोर्ड।
`openspec validate`	संरचनात्मक समस्याओं के लिए परिवर्तनों और स्पेक्स की जाँच करें।
`openspec archive`	पूर्ण हो चुके परिवर्तन को आर्काइव में ले जाएँ और मुख्य स्पेक्स को अपडेट करें।

वर्कफ़्लो और स्कीमा

आपका एजेंट वर्कफ़्लो के दौरान इनमें से अधिकांश को चलाता है।

कमांड	यह क्या करता है
`openspec new`	एक नई परिवर्तन डायरेक्टरी बनाएँ।
`openspec status`	एक या प्रत्येक सक्रिय परिवर्तन के लिए आर्टिफैक्ट पूर्णता स्थिति।
`openspec instructions`	किसी आर्टिफैक्ट को बनाने, लागू करने, या आर्काइव करने के लिए निर्देश।
`openspec templates`	किसी स्कीमा के आर्टिफैक्ट्स के लिए रिज़ॉल्व किए गए टेम्पलेट पथ।
`openspec schemas`	उपलब्ध वर्कफ़्लो स्कीमा को सूचीबद्ध करें।
`openspec schema`	किसी स्कीमा की जाँच, फोर्क, या निर्माण करें (प्रायोगिक)।

मल्टी-रेपो (बीटा)

कमांड	यह क्या करता है
`openspec store`	स्टोर बनाएँ और प्रबंधित करें: आपकी मशीन पर पंजीकृत स्टैंडअलोन OpenSpec रेपो।
`openspec doctor`	रिज़ॉल्व किए गए OpenSpec रूट के लिए संबंध स्वास्थ्य की रिपोर्ट करें।
`openspec context`	रिज़ॉल्व किए गए OpenSpec रूट के लिए कार्यशील संदर्भ प्रिंट करें।
`openspec workset`	व्यक्तिगत कार्यशील दृश्यों को रचना करें, बनाए रखें, और खोलें।

उपयोगिताएँ

कमांड	यह क्या करता है
`openspec version`	इंस्टॉल किए गए संस्करण की रिपोर्ट करें और वैकल्पिक रूप से अपडेट की जाँच करें।
`openspec install`	स्टैंडअलोन `openspec` इंस्टॉल करें, जो Node.js के बिना चलता है।
`openspec feedback`	OpenSpec के बारे में फीडबैक सबमिट करें।
`openspec completion`	शेल कम्प्लीशन इंस्टॉल करें या जनरेट करें।

अप्रचलित

कमांड	यह क्या करता है
`openspec change`	परिवर्तनों के लिए show, list, और validate का संज्ञा रूप। CLI चेतावनी देता है और verb-first कमांड्स की ओर इशारा करता है।
`openspec spec`	स्पेक्स के लिए show, list, और validate का संज्ञा रूप, उसी चेतावनी के साथ।

प्रत्येक कमांड -h, --help लेता है। बेयर openspec कमांड भी ये लेता है:

-V, --version: CLI संस्करण प्रिंट करें।
--no-color: रंगीन आउटपुट अक्षम करें।## openspec init

प्रोजेक्ट में OpenSpec की प्रारंभिक शुरुआत करता है।

bash

openspec init                        # वर्तमान निर्देशक, इंटरैक्टिव टूल चयनकर्ता
openspec init --tools claude,cursor  # विशिष्ट टूल सेट अप करें, कोई प्रॉम्प्ट नहीं
openspec init --tools none           # केवल openspec/ संरचना, कोई टूल फाइलें नहीं

यदि --tools नहीं दिया जाता, तो init एक इंटरैक्टिव टर्मिनल में टूल चुनने के लिए आपसे पूछता है। यदि आप टर्मिनल के बाहर हैं, तो यह उसमें डिटेक्ट किए गए टूल का सेटअप करता है। यदि कोई डिटेक्ट नहीं होता, तो यह 1 exit code के साथ समाप्त हो जाता है और मान्य ids की सूची प्रदर्शित करता है।

केवल स्टोर वाले रिपॉज़िटरी

जब openspec/config.yaml में एक store: लाइन होती है और रिपॉज़िटरी में कोई लोकल स्पेस या परिवर्तन नहीं होते हैं, तो रिपॉज़िटरी रूट से init चलाएँ:

bash

# कोड रिपॉज़िटरी में Claude Code इंटीग्रेशन फाइलें इंस्टॉल करें
openspec init --tools claude

इंटीग्रेशन फाइलें: कोड रिपॉज़िटरी में लिखी जाती हैं।
openspec/config.yaml: बाइट-दर-बाइट सुरक्षित रखा जाता है।
openspec/specs/ और openspec/changes/: कोड रिपॉज़िटरी में नहीं बनाए जाते।

उप-निर्देशक (subdirectory) से init चलाएंगे तो 1 exit code देता है और बताता है कि रिपॉज़िटरी रूट से इसे चलाएँ। --language भी 1 exit code देता है क्योंकि भाषा बाह्य स्टोर की कॉन्फिगरेशन में होनी चाहिए। स्टोर रूट में init चलाएँ या उस कॉन्फिगरेशन को सीधे एडिट करें।

एर्गूमेंट्स

एर्गूमेंट	यह क्या है
`path`	इनिशियलाइज करने के लिए प्रोजेक्ट निर्देशक। डिफॉल्ट: वर्तमान निर्देशक। यदि मौजूद नहीं है तो बनाया जाता है।

ऑप्शंस

फ्लैग	प्रभाव
`--tools <tools>`	कॉमा-अलग टूल ids, `all`, या `none`। चयनकर्ता को छोड़ देता है। Ids Supported tools में सूचीबद्ध हैं।
`--language <language>`	नए प्रोजेक्ट कॉन्फिगरेशन में एक भाषा निर्देश जोड़ता है। जब रिपॉज़िटरी की `store:` लाइन बाह्य स्टोर की ओर इशारा करती है, तो इसे अस्वीकार किया जाता है।
`--force`	पूछे बिना पुराने OpenSpec लेआउट से फाइलें हटा देता है। अन्यथा इंटरैक्टिव रन सबसे पहले सफ़ाई की पुष्टि करता है।
`--profile <profile>`	इस रन के लिए ग्लोबल कॉन्फिग प्रोफ़ाइल का अधिनिर्धारण (override): `core` (मानक वर्कफ्लो सेट) या `custom` (ग्लोबल कॉन्फिग में सहेजे गए वर्कफ्लो)।
`--no-animation`	एनिमेटेड स्क्रीन की बजाय स्टैटिक वेलकम स्क्रीन दिखाता है।

आउटपुट

प्रत्येक चयनित टूल को OpenSpec के skills और commands अपनी अपनी निर्देशक में मिलते हैं:

▌ OpenSpec संरचना बनाई गई
✔ Claude Code के लिए सेटअप पूरा

OpenSpec Setup Complete

सृजित: Claude Code
6 skills और 6 commands in .claude/
Config: openspec/config.yaml (schema: spec-driven)

शुरू करने का तरीका:
  अपना पहला परिवर्तन शुरू करें: /opsx:propose "your idea"

नए commands के प्रभावी होने के लिए अपनी IDE रीस्टार्ट करें।

--tools none केवल openspec/config.yaml बनाता है। पहले से इनिशियलाइज़ किए गए प्रोजेक्ट पर, init इनस्टॉल की गई फाइलों को जगह पर (in place) रीराइट करता है और सारांश में Refreshed: Claude Code और Config: openspec/config.yaml (exists) पढ़ा जाता है।

Exit codes

0: सेटअप पूरा हुआ।
1: अमान्य --tools या --profile मान, कोई टूल डिटेक्ट नहीं होने और --tools न होने वाला गैर-इंटरैक्टिव रन, या अमान्य स्टोर-ओनली इन्वोकेशन।

openspec update

OpenSpec की इनस्टॉल की गई निर्देश फाइलें अपडेट करता है।

bash

openspec update             # उन टूल को रिफ्रेश करें जिनकी फाइलें CLI से पुरानी हैं
openspec update --force     # फाइलें रीराइट करें mesmo कि वे अप-टू-डेट हों
openspec update --dry-run   # दिखाए कि अपडेट क्या बदलेगा, और कुछ नहीं बदलेगा

update, init द्वारा कॉन्फिग किए गए टूल खोजता है और उनसे जनित (generated) फाइलें CLI के संस्करण से तुलना करता है। जब नया OpenSpec रिलीज़ मौजूद है, तो यह पहले CLI अपग्रेड करने का प्रस्ताव देता है, तब उन्नत संस्करण के साथ पुनः चलाता है। चек को छोड़ने के लिए OPENSPEC_NO_UPDATE_CHECK=1 सेट करें।

एर्गूमेंट्स

एर्गूमेंट	यह क्या है
`path`	अपडेट करने के लिए प्रोजेक्ट निर्देशक। डिफॉल्ट: वर्तमान निर्देशक।

ऑप्शंस

फ्लैग	प्रभाव
`--force`	प्रत्येक कॉन्फिग किए गए टूल की फाइलें रीराइट करे, भले ही वे अप-टू-डेट हों।
`--dry-run`	रिपोर्ट करे कि अपडेट में कौन-सी फाइलें जोड़ी, बदली या हटाई जाएँगी, और कुछ नहीं लिखे। कोई CLI अपग्रेड चेक नहीं, कोई प्रॉम्प्ट नहीं। `--force` के साथ मिलाकर जबरदस्ती अपडेट की प्रीव्यू करें।
`--json`	`--dry-run` के साथ, प्लान को JSON के रूप में प्रिंट करें। `--dry-run` के बिना यह 1 exit code के साथ समाप्त हो जाता है।

अपडेट की प्रीव्यू करना

--dry-run एक गैर-इंटरैक्टिव रन द्वारा किए जाने वाले अपडेट की योजना बनाता है: वही कोड पथ, जहाँ हर write और delete को रिकॉर्ड किया जाता है किए जाने के बजाय। हर फाइल जो वास्तविक अपडेट टच करेगी, सूचीबद्ध की जाती है, जिसमें शामिल हैं:

OpenSpec फाइलों को टूल के पूर्व निर्देशक से बाहर ले जाना (.kimi/ से .kimi-code/, .windsurf/ से .devin/, .codex/ और .agent/ से .agents/);
जब profiles से पहले की इंस्टॉल में profile मिल जाए तो ग्लोबल कॉन्फिग को सहेजना;
GitHub Copilot cloud agent फाइलें सिंक करना;
--force के साथ, केवल legacy artifacts में पाए गए टूल सेट अप करना और उन artifacts को साफ़ करना, जिसमें retired global Codex prompts शामिल हैं।

bash

openspec update --dry-run

2 फाइलें बदलेंगी:
  अपडेट  .claude/skills/openspec-propose/SKILL.md  (claude)
  जोड़ें  ~/.config/openspec/config.json  (openspec)

--dry-run --json वही प्लान एक JSON दस्तावेज़ के रूप में प्रिंट करता है:

json

{
  "changes": [
    { "path": ".claude/skills/openspec-propose/SKILL.md", "action": "update", "tool": "claude" },
    { "path": "~/.config/openspec/config.json", "action": "add", "tool": "openspec" }
  ],
  "notes": [],
  "failures": []
}

फील्ड	यह क्या रखती है
`changes[].path`	प्रोजेक्ट-सापेक्ष पथ। प्रोजेक्ट के बाहर की फाइल, जैसे ग्लोबल skill या ग्लोबल कॉन्फिग, आपके home directory से `~/...` के रूप में दिखाई देती है, या जब वह home से भी बाहर हो तो absolute path के रूप में।
`changes[].action`	`add`, `update`, या `delete`। जिस फाइल के नए bytes पुराने से मेल खाते हैं, उसे सूचीबद्ध नहीं किया जाता।
`changes[].tool`	कॉन्फिग किया गया टूल जिससे फाइल संबंधित है, जैसे `claude`। OpenSpec स्वयं से संबंधित फाइलें, ग्लोबल कॉन्फिग और legacy-artifact सफ़ाई, `openspec` हैं।
`notes[]`	`{ code, message }` किसी भी स्टेप के लिए जिस बारे में टर्मिनल उपयोगकर्ता से पूछा जाएगा। `legacy-tool-directories`: एक move जिसे इंटरैक्टिव रन पहले पूछता है; `changes` इसे की गई मानकर सूचीबद्ध करता है। `legacy-artifacts`: OpenSpec के पुराने लेआउट से फाइलें मिलीं, जैसे `openspec-proposal.md` slash commands या `AGENTS.md` में OpenSpec marker blocks। `--force` के बिना गैर-इंटरैक्टिव अपडेट उन्हें छूता नहीं है, इसलिए `changes` भी नहीं; `--dry-run --force` उनकी सफ़ाई की सूची देता है। साधारण रिफ्रेश के लिए खाली।
`failures[]`	`{ tool, error }` प्रत्येक टूल के लिए जिसमें वास्तविक अपडेट विफल होगा, जिसमें एक write शामिल है जिसे वह नहीं कर सकता: जहाँ फाइल होनी चाहिए वहाँ directory, जहाँ directory होनी चाहिए वहाँ फाइल, या write permission के बिना फाइल या फोल्डर। उस टूल के लिए, `changes` वहाँ रुक जाता है जहाँ वास्तविक अपडेट रुकता है; अन्य टूल अभी भी प्लान होते हैं। disk केवल write करते समय रिपोर्ट करने वाली विफलताएँ, जैसे space की कमी, पूर्वानुमानित नहीं की जा सकतीं।

प्लानिंग से पहले की कोई विफलता, जैसे OpenSpec directory का न होना, फिर भी बिल्कुल एक JSON दस्तावेज़ प्रिंट करती है: खाली प्लान और एक status array जिसमें severity, code (update_error), और message होता है। Exit code 1 होती है।

आउटपुट

जब हर टूल की फाइलें CLI संस्करण से मेल खाती हैं:

✓ सभी 1 टूल अप-टू-डेट हैं (v1.7.0)
  टूल: claude

फाइलों को फिर भी रिफ्रेश करने के लिए --force उपयोग करें।

जब किसी टूल की फाइलें पुराने CLI से आई हैं (या --force के साथ, जो Force updating 1 tool(s): claude प्रिंट करता है):

1 टूल अपडेट हो रहे हैं: claude (1.6.0 → 1.7.0)

✔ Claude Code अपडेट हुआ

✓ अपडेट: Claude Code (v1.7.0)
टूल: Claude Code

परिवर्तनों के प्रभावी होने के लिए अपनी IDE रीस्टार्ट करें।

OpenSpec के बिना वाले निर्देशक में, update अस्वीकार कर देता है:

✖ Error: OpenSpec directory नहीं मिला। पहले 'openspec init' चलाएँ।

Exit codes

0: फाइलें अपडेट हुईं, या सब कुछ पहले से अप-टू-डेट था।
1: path पर OpenSpec directory नहीं है, या अपडेट विफल रहा।

openspec config

ग्लोबल कॉन्फिगरेशन देखता और बदलता है।

bash

openspec config list                  # वर्तमान सेटिंग्स देखें
openspec config set delivery skills   # एक मान बदलें
openspec config profile               # इंटरैक्टिव वर्कफ्लो चयनकर्ता

सबकमांड	यह क्या करता है
`path`	कॉन्फिग फाइल की लोकेशन प्रिंट करता है।
`list`	सभी वर्तमान सेटिंग्स दिखाता है।
`get <key>`	एक मान प्रिंट करता है, raw और scriptable।
`set <key> <value>`	एक मान सेट करता है, इसका type coercing करता है।
`unset <key>`	एक key को हटाता है ताकि उसका डिफॉल्ट लागू हो।
`reset`	सभी कॉन्फिगरेशन को डिफॉल्ट रीसेट करता है।
`edit`	`$EDITOR` में कॉन्फिग फाइल खोलता है।
`profile [preset]`	डिलीवरी मोड और वर्कफ्लो कॉन्फिग करता है।

कॉन्फिग आपकी मशीन के लिए ग्लोबल है, JSON में स्टोर किया जाता है जहाँ config path इशारा करता है: यदि $XDG_CONFIG_HOME/openspec/config.json सेट है तो वह, वरना ~/.config/openspec/config.json (macOS, Linux) या %APPDATA%\openspec\config.json (Windows)। प्रत्येक सबकमांड --scope <scope> स्वीकार करता है, लेकिन आज केवल global काम करता है। कोई अन्य scope 1 exit code के साथ Error: Project-local config is not yet implemented के साथ समाप्त हो जाता है।

openspec config path

bash

openspec config path

/Users/you/.config/openspec/config.json

openspec config list

bash

openspec config list          # पठनीय सेटिंग्स plus profile सारांश
openspec config list --json   # raw config as JSON

ऑप्शंस

फ्लैग	प्रभाव
`--json`	कॉन्फिग object को JSON के रूप में प्रिंट करता है।

आउटपुट

प्रत्येक सेटिंग, तब एक profile सारांश जो मानों को explicit या default के रूप में मार्क करता है:

featureFlags: {}
profile: core
delivery: both

Profile settings:
  profile: core (default)
  delivery: both (default)
  workflows: propose, explore, apply, update, sync, archive (from core profile)

openspec config get

bash

openspec config get delivery

एर्गूमेंट्स

एर्गूमेंट	यह क्या है
`key`	पढ़ने के लिए key। Dots nested values तक पहुँचते हैं (`featureFlags.workspaces`)।

आउटपुट

नंगे (bare) मान, scripts के लिए तैयार। Objects compact JSON के रूप में प्रिंट होते हैं:

both

Exit codes

0: मान प्रिंट किया गया।
1: key का कोई मान नहीं है, और कुछ प्रिंट नहीं होता।

openspec config set

bash

openspec config set delivery skills
openspec config set featureFlags.workspaces true

एर्गूमेंट्स

एर्गूमेंट	यह क्या है
`key`	लिखने के लिए key, nested values के लिए dotted।
`value`	नया मान। `true`/`false` booleans बन जाते हैं, numeric strings numbers बन जाते हैं।

ऑप्शंस

फ्लैग	प्रभाव
`--string`	मान को string के रूप में स्टोर करता है, type coercion को छोड़ देता है।
`--allow-unknown`	ऐसे keys को अनुमति देता है जिन्हें schema नहीं जानता।

आउटपुट

Set featureFlags.workspaces = true

अज्ञात keys और अमान्य values कुछ भी सेव होने से पहले 1 exit code के साथ विफल हो जाते हैं:

Error: अमान्य configuration key "bogus.key"। अज्ञात top-level key "bogus"।
उपलब्ध keys देखने के लिए "openspec config list" का उपयोग करें।
इस चेक को बाईपास करने के लिए --allow-unknown पास करें।

Error: अमान्य configuration - delivery: अमान्य option: "both"|"skills"|"commands" में से एक की अपेक्षा थी

यदि कॉन्फिग फाइल मौजूद है लेकिन JSON object नहीं रखती, चाहे वह valid JSON ही न हो या उसकी root null या array जैसी कोई अन्य चीज़ हो, config set, config unset और config profile 1 exit code के साथ समाप्त हो जाते हैं और फाइल को अपरिवर्तित छोड़ देते हैं। इसे openspec config edit से ठीक करें, या openspec config reset --all से प्रतिस्थापित करें:

Error: /home/you/.config/openspec/config.json को parse नहीं किया जा सका, इसलिए इसे अपरिवर्तित रखा गया।
इसे "openspec config edit" से ठीक करें, या "openspec config reset --all" से रीसेट करें।

इसे ठीक होने तक, telemetry और update check बंद रहते हैं।

openspec config unset

bash

openspec config unset delivery

Key को हटाता है ताकि डिफॉल्ट फिर से लागू हो। built-in defaults वाले keys हमेशा set माने जाते हैं, इसलिए यह उनसे कभी set नहीं किया गया हो तो भी सफलता की रिपोर्ट करता है:

Unset delivery (reverted to default)

किसी भी मान के बिना key Key "featureFlags.nothere" was not set प्रिंट करता है। दोनों मामलों में 0 exit code होती है। parse नहीं होने वाली कॉन्फिग फाइल config set की तरह 1 exit code के साथ समाप्त हो जाती है।

openspec config reset

bash

openspec config reset --all      # पुष्टि के लिए पूछता है
openspec config reset --all -y   # कोई प्रॉम्प्ट नहीं

ऑप्शंस

फ्लैग	प्रभाव
`--all`	आवश्यक। सब कुछ रीसेट करें।
`-y, --yes`	पुष्टि प्रॉम्प्ट को छोड़ता है।

आउटपुट

Configuration reset to defaults

--all के बिना यह 1 exit code के साथ समाप्त हो जाता है और usage line प्रिंट करता है।

Exit codes

0: reset पूरा हुआ, या प्रॉम्प्ट पर आपने no उत्तर दिया।
1: --all नहीं है।
130: Ctrl-C से प्रॉम्प्ट रद्द किया गया।

openspec config edit

bash

openspec config edit

कॉन्फिग फाइल को $EDITOR (फिर से $VISUAL पर गिरने पर) में खोलता है, यदि गायब है तो पहले डिफॉल्ट्स के साथ इसे बनाता है। जब editor बंद होता है, तो फाइल को validate किया जाता है। अमान्य JSON या अमान्य config 1 exit code के साथ समाप्त होता है।

Editor value arguments और quoted paths का वहन कर सकती है, जैसे code --wait या "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" -w। इसे शेल के बिना शब्दों में विभाजित किया जाता है, इसलिए $VAR, ~ और ; literal रूप से पास किए जाते हैं। कोई भी editor जो शुरू नहीं हो सकता, या non-zero exit code के साथ समाप्त होता है, एक-लाइन error प्रिंट करता है और 1 exit code के साथ समाप्त होता है।

कोई editor configure नहीं किया गया हो तो 1 exit code के साथ समाप्त हो जाता है:

Error: कोई editor configure नहीं किया गया
आपके पसंदीदा editor के लिए EDITOR या VISUAL environment variable सेट करें
उदाहरण: export EDITOR=vim

openspec config profile

bash

openspec config profile        # इंटरैक्टिव चयनकर्ता (टर्मिनल की ज़रूरत है)
openspec config profile core   # core preset को सीधे लागू करें

एर्गूमेंट्स

एर्गूमेंट	यह क्या है
`preset`	वैकल्पिक preset नाम। केवल `core` मौजूद है। यह core workflows को चुनता है और आपकी delivery setting को बनाए रखता है।

यदि कोई preset नहीं है, तो इंटरैक्टिव चयनकर्ता आपकी वर्तमान delivery और workflows दिखाता है, आपको दोनों में से किसी एक या दोनों को बदलने देता है (delivery: both, केवल skills, या केवल commands; workflows: एक checkbox list), diff प्रिंट करता है, और OpenSpec project के भीतर openspec update चलाकर आपके लिए करने का प्रस्ताव करता है। टर्मिनल के बाहर यह 1 exit code के साथ समाप्त हो जाता है:

इंटरैक्टिव मोड आवश्यक है। `openspec config profile core` का उपयोग करें या environment/flags के माध्यम से config सेट करें।

आउटपुट

बदली हुई config projects तक तब तक नहीं पहुँचती जब तक वे update न करें:

Config अपडेट हुआ। लागू करने के लिए अपने projects में `openspec update` चलाएँ।

Exit codes

0: profile सेव हुआ, या आपने वर्तमान सेटिंग्स को बनाए रखा।
1: अज्ञात preset, कोई टर्मिनल नहीं, या प्रस्तावित openspec update विफल रहा।
130: Ctrl-C से चयनकर्ता रद्द किया गया।

openspec list

परिवर्तनों की सूची बनाता है, या --specs के साथ विनिर्देशों की।

bash

openspec list                    # active changes, most recently modified first
openspec list --archived         # archived changes
openspec list --all              # active and archived changes
openspec list --specs            # specs with requirement counts
openspec list --json             # machine-readable, includes the resolved root

पंक्तियाँ निर्धारित मूल के अंतर्गत openspec/changes/ और openspec/specs/ से आती हैं। डिफ़ॉल्ट परिवर्तन सूची openspec/changes/archive/ को छोड़ देती है।

विकल्प

फ़्लैग	प्रभाव
`--specs`	परिवर्तनों के बजाय विनिर्देशों की सूची बनाएं।
`--changes`	परिवर्तनों की सूची बनाएं। यह डिफ़ॉल्ट है।
`--archived`	केवल संग्रहीत परिवर्तनों की सूची बनाएं। `--specs` के साथ जोड़ा नहीं जा सकता।
`--all`	सक्रिय और संग्रहीत परिवर्तनों की सूची बनाएं। `--specs` के साथ जोड़ा नहीं जा सकता। `--archived` पर प्राथमिकता लेता है।
`--sort <order>`	`recent` (सबसे पहले अंतिम बार संशोधित) या `name`। डिफ़ॉल्ट: `recent`। विनिर्देश हमेशा नाम से क्रमबद्ध होते हैं।
`--json`	तालिका के बजाय JSON प्रिंट करें।
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय एक पंजीकृत भंडार को OpenSpec मूल के रूप में उपयोग करें।

आउटपुट

प्रति परिवर्तन एक पंक्ति: नाम, कार्य स्थिति, अंतिम बार संशोधित। स्थिति कॉलम No tasks, 2/5 tasks, या ✓ Complete पढ़ता है।

Changes:
  add-rate-limit     No tasks      just now

--all सक्रिय और संग्रहीत परिवर्तनों को अलग-अलग शीर्षकों के अंतर्गत समूहित करता है। प्रत्येक समूह चयनित क्रम का उपयोग करता है:

Changes:
  add-rate-limit     No tasks      just now

Archived Changes:
  2026-08-10-add-login     ✓ Complete    2d ago

Specs:
  api     requirements 1

--json कार्य गणनाएँ और no-tasks, in-progress, या complete की status जोड़ता है:

json

{
  "changes": [
    {
      "name": "add-rate-limit",
      "completedTasks": 0,
      "totalTasks": 0,
      "lastModified": "2026-08-11T13:44:40.171Z",
      "status": "no-tasks"
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

--archived या --all के साथ, प्रत्येक परिवर्तन ऑब्जेक्ट में एक archived बूलियन शामिल होता है। संयुक्त सरणी चयनित क्रम का उपयोग करती है। एक संग्रहीत परिवर्तन में अभी भी in-progress स्थिति हो सकती है जब उसकी ट्रैक की गई कार्य फ़ाइल में अनचेक किए गए कार्य हों। इनमें से किसी भी फ़्लैग के बिना, JSON आकार अपरिवर्तित रहता है।

एक खाली सूची No active changes found., No archived changes found., No changes found., या No specs found. प्रिंट करती है और फिर भी 0 के साथ बाहर निकलती है।

एक परिवर्तन openspec/changes/ के सीधे नीचे एक निर्देशिका है। विनिर्देशों के विपरीत, परिवर्तनों को नामस्थान फ़ोल्डर में नेस्ट नहीं किया जा सकता। एक फ़ोल्डर जैसे changes/mobile/ जो केवल एक परिवर्तन (changes/mobile/refresh-token/) को लपेटता है, not a change स्थिति के साथ सूचीबद्ध किया जाता है, उसके बाद एक चेतावनी जो नेस्टेड निर्देशिकाओं के नाम बताती है। --json उस प्रविष्टि को nested सरणी के साथ चिह्नित करता है और एक शीर्ष-स्तरीय warnings सरणी जोड़ता है। show, status, validate और archive उसी संदेश के साथ फ़ोल्डर को अस्वीकार करते हैं। इसे ठीक करने के लिए, परिवर्तन को ऊपर ले जाएं और नामस्थान को उसके नाम में मोड़ें:

bash

mv openspec/changes/mobile/refresh-token openspec/changes/mobile-refresh-token
rmdir openspec/changes/mobile

निकास कोड

0: सूची प्रिंट की गई, खाली होने पर भी।
1: कोई OpenSpec मूल नहीं मिला (प्रोजेक्ट के बाहर, कोई --store नहीं)।

openspec show

एक परिवर्तन या विनिर्देश को मार्कडाउन या JSON के रूप में प्रिंट करता है।

bash

openspec show add-rate-limit              # change: prints proposal.md
openspec show add-rate-limit --diff       # change: append requirement diffs
openspec show api                         # spec: prints spec.md
openspec show api --json --no-scenarios   # spec JSON without scenario text

नाम के बिना, show परिवर्तन या विनिर्देश पूछता है, फिर चुनने के लिए आइटम सूचीबद्ध करता है। एक इंटरैक्टिव टर्मिनल के बाहर यह 1 के साथ बाहर निकलता है और इसके बजाय सीधे रूपों को प्रिंट करता है।

तर्क

तर्क	यह क्या है
`item-name`	दिखाने के लिए परिवर्तन या विनिर्देश, फ़ोल्डर नाम से (`add-rate-limit`, `api`)।

विकल्प

फ़्लैग	प्रभाव
`--json`	कच्चे मार्कडाउन के बजाय संरचित JSON प्रिंट करें।
`--type <change\|spec>`	जब एक परिवर्तन और एक विनिर्देश एक नाम साझा करते हैं तो प्रकार चुनें।
`--no-interactive`	कभी संकेत न दें: एक लापता नाम एक त्रुटि बन जाता है।
`--deltas-only`	JSON, परिवर्तन: आउटपुट को डेल्टा तक सीमित करें। परिवर्तन JSON पहले से ही डेल्टा-केवल है, इसलिए आउटपुट सादे `--json` से मेल खाता है।
`--requirements-only`	`--deltas-only` के लिए अप्रचलित उपनाम। stderr पर चेतावनी देता है।
`--diff`	परिवर्तन: प्रति-आवश्यकता डेल्टा अंतर संलग्न करें। विनिर्देशों के लिए चेतावनी के साथ अनदेखा किया जाता है।
`--requirements`	JSON, विनिर्देश: आवश्यकता पाठ रखें, `scenarios` सरणियाँ खाली करें।
`--no-scenarios`	JSON, विनिर्देश: `--requirements` के समान आउटपुट।
`-r, --requirement <id>`	JSON, विनिर्देश: 1-आधारित स्थिति द्वारा एक आवश्यकता आउटपुट करें। `--requirements` के साथ जोड़ा नहीं जा सकता।
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय एक पंजीकृत भंडार को OpenSpec मूल के रूप में उपयोग करें।

जो फ़्लैग निर्धारित प्रकार पर लागू नहीं होते हैं, उन्हें stderr पर चेतावनी के साथ अनदेखा किया जाता है।

आउटपुट

टेक्स्ट मोड एक कच्चा पास-थ्रू है: एक परिवर्तन अपना proposal.md प्रिंट करता है, एक विनिर्देश अपना spec.md प्रिंट करता है।

# Add rate limiting
```## क्यों
अप्रमाणित क्लाइंट API के संसाधनों को समाप्त कर सकते हैं।

## क्या बदलता है
- सार्वजनिक API में प्रति-क्लाइंट रेट लिमिटिंग जोड़ें।

किसी change के लिए, `--diff` पहले प्रस्ताव प्रिंट करता है, फिर `Specifications Changed (diffs)` अनुभाग। ADDED requirements में उनका पूरा टेक्स्ट शामिल होता है। REMOVED requirements लेखक द्वारा दिए गए Reason और Migration को बनाए रखती हैं। RENAMED requirements FROM और TO दिखाती हैं। MODIFIED requirements मिलते हुए मुख्य requirement के विरुद्ध unified diff दिखाती हैं।

यदि कोई MODIFIED हेडर केस या व्हाइटस्पेस को समान करने के बाद ही मेल खाता है, तो आउटपुट में diff और यह चेतावनी दोनों शामिल होते हैं कि archive मिलान सटीक है। यदि मुख्य spec या requirement अनुपस्थित है, तो आउटपुट चेतावनी देता है और पूरा delta ब्लॉक प्रिंट करता है। बिना पाठ्य अंतर वाला MODIFIED ब्लॉक `(no textual changes)` प्रिंट करता है।

`--json` के साथ एक change delta-आकार का होता है:

```json
{
  "id": "add-rate-limit",
  "title": "Add rate limiting",
  "deltaCount": 1,
  "deltas": [
    {
      "spec": "api",
      "operation": "ADDED",
      "description": "Add requirement: The API SHALL limit each client to 100 requests per minute.",
      "requirement": {
        "name": "Rate limit",
        "text": "The API SHALL limit each client to 100 requests per minute.",
        "scenarios": [
          {
            "name": "Client exceeds the limit",
            "rawText": "- **WHEN** a client sends its 101st request within a minute\n- **THEN** the API responds 429"
          }
        ]
      },
      ...
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

प्रत्येक requirement अपना name रखता है, जो Requirement: के बाद का हेडर टेक्स्ट है। यह वह नाम है जिसके विरुद्ध archive MODIFIED, REMOVED और RENAMED प्रविष्टियों का मिलान करता है। प्रत्येक scenario अपना name रखता है, जो Scenario: के बाद का हेडर टेक्स्ट है। किसी भी हेडर पर अंत में आने वाला # रन नाम का हिस्सा नहीं होता।

--json --diff यह शीर्ष-स्तरीय आकार बनाए रखता है। एक MODIFIED delta में diff स्ट्रिंग, warning स्ट्रिंग, या दोनों प्राप्त करता है। अन्य ऑपरेशन अपरिवर्तित रहते हैं। खाली diff स्ट्रिंग का अर्थ है कि मुख्य और delta ब्लॉक पाठ्य रूप से समान हैं।

--json के साथ एक spec अपनी requirements को scenarios सहित सूचीबद्ध करता है। Requirements और scenarios में वही name फ़ील्ड होते हैं जो change JSON में होते हैं:

json

{
  "id": "api",
  "title": "api",
  "overview": "Public HTTP API behavior.",
  "requirementCount": 1,
  "requirements": [
    {
      "name": "Health endpoint",
      "text": "The API SHALL expose a health endpoint.",
      "scenarios": [
        {
          "name": "Health check succeeds",
          "rawText": "- **WHEN** a client requests GET /health\n- **THEN** the API responds 200"
        }
      ]
    }
  ],
  "metadata": {
    "version": "1.0.0",
    "format": "openspec"
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

अज्ञात नाम निकट मिलान सुझाता है: Unknown item 'does-not-exist'. Did you mean: add-rate-limit, api?। जो नाम एक change और एक spec दोनों से मेल खाता है, वह त्रुटि देता है और --type के लिए कहता है।

एग्जिट कोड

0: आइटम प्रिंट हुआ।
1: अज्ञात या अस्पष्ट नाम; टर्मिनल के बाहर कोई नाम न होना; सीमा से बाहर -r इंडेक्स; --requirements का -r के साथ संयोजन; या --diff के लिए delta या मुख्य spec पढ़ा नहीं जा सकना।

openspec view

specs और changes का एक-स्क्रीन डैशबोर्ड प्रिंट करता है।

bash

openspec view   # एक स्क्रीन में प्रोजेक्ट सारांश

view डैशबोर्ड को एक बार प्रिंट करता है और बाहर निकलता है। यह कोई कीस्ट्रोक नहीं पढ़ता। Changes task प्रगति के आधार पर समूहित होते हैं: Draft (अभी कोई task नहीं), Active (tasks जारी, प्रगति बार और प्रतिशत के साथ), Completed (हर task चेक किया गया)। Specs requirement गिनतियों के साथ सूचीबद्ध होते हैं, सबसे बड़े पहले।

विकल्प

फ़्लैग	प्रभाव
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय पंजीकृत store को OpenSpec root के रूप में उपयोग करें।

आउटपुट

OpenSpec Dashboard

════════════════════════════════════════════════════════════
Summary:
  ● Specifications: 1 specs, 1 requirements
  ● Draft Changes: 1
  ● Active Changes: 0 in progress
  ● Completed Changes: 0

Draft Changes
────────────────────────────────────────────────────────────
  ○ add-rate-limit

Specifications
────────────────────────────────────────────────────────────
  ▪ api                            1 requirement

════════════════════════════════════════════════════════════

Use openspec list --changes or openspec list --specs for detailed views

जब किसी change में tasks जारी हों, तो एक Task Progress सारांश पंक्ति दिखाई देती है।

प्रत्येक active change अपने task progress bar के नीचे अपना schema और artifact स्थितियाँ भी दिखाता है:

text

    └─ [spec-driven] proposal✓ specs→ design→ tasks✓

मार्कर	Artifact स्थिति
`✓`	इसका आउटपुट मौजूद है। मौजूदा tasks artifact पूर्ण माना जाता है, भले ही उसकी चेकलिस्ट अधूरी हो।
`→`	यह बनाने के लिए तैयार है।
कोई मार्कर नहीं	यह गायब dependency के कारण अवरुद्ध है।
`(skipped)`	change इसे छोड़ देता है।

यदि workflow लोड नहीं हो सकता, तो view चेतावनी प्रिंट करता है और उस change की task progress दिखाई देती रहती है। workflow को अलग से जाँचने के लिए openspec status --change <name> चलाएँ। openspec view --store <id> के बाद status को वही --store <id> पास करें।

एग्जिट कोड

0: डैशबोर्ड प्रिंट हुआ।
1: कोई OpenSpec root नहीं मिला (प्रोजेक्ट के बाहर, --store नहीं)।

openspec validate

changes और specs में संरचनात्मक समस्याओं की जाँच करता है।

bash

openspec validate add-rate-limit   # नाम से एक change या spec
openspec validate --all            # हर change और spec

बिना नाम और बिना bulk फ़्लैग के, validate आपको आइटम चुनने के लिए प्रॉम्प्ट करता है। इंटरैक्टिव टर्मिनल के बाहर यह 1 पर बाहर निकलता है और इसके बजाय bulk फ़्लैग प्रिंट करता है।

आर्ग्युमेंट

आर्ग्युमेंट	यह क्या है
`item-name`	validate करने के लिए change या spec, फ़ोल्डर नाम से (`add-rate-limit`, `api`)।

विकल्प

फ़्लैग	प्रभाव
`--all`	हर change और spec को validate करें।
`--changes`	हर change को validate करें।
`--specs`	हर spec को validate करें।
`--archived`	archived changes में task पूर्णता जाँचें, बिना उनके लागू spec deltas को validate किए।
`--strict`	चेतावनियों को विफलताओं के रूप में मानें।
`--type <change\|spec>`	जब एक change और एक spec का नाम समान हो, तो type चुनें।
`--json`	टेक्स्ट के बजाय संरचित रिपोर्ट प्रिंट करें।
`--report <mode>`	Bulk आउटपुट: `full` (डिफ़ॉल्ट) या `findings`। स्पष्ट bulk scope आवश्यक है।
`--concurrency <n>`	bulk रन में अधिकतम समानांतर validations। डिफ़ॉल्ट: `OPENSPEC_CONCURRENCY`, अन्यथा 6।
`--no-interactive`	कभी प्रॉम्प्ट न करें: गायब या अस्पष्ट नाम त्रुटि बन जाता है।
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय पंजीकृत store को OpenSpec root के रूप में उपयोग करें।

आउटपुट

Bulk रन प्रति आइटम एक status पंक्ति प्रिंट करते हैं, उसके बाद कोई भी findings, और totals के साथ समाप्त होते हैं:

✓ change/add-rate-limit
✓ spec/api
Totals: 2 passed, 0 failed (2 items)

Task checkbox संबंधी findings

प्रगति केवल चेकबॉक्स गिनती है और कुछ नहीं, इसलिए सादे बुलेट के रूप में लिखी गई task फ़ाइल शून्य tasks के रूप में पढ़ी जाती है: openspec list और openspec status कोई कार्य रिपोर्ट नहीं करते, और openspec archive के पास अधूरा के रूप में फ़्लैग करने के लिए कुछ नहीं होता। Validate प्रत्येक tracked task फ़ाइल पर एक WARNING रिपोर्ट करता है जो बिना चेकबॉक्स के कार्य सूचीबद्ध करती है:

text

⚠ [WARNING] tasks.md: This change counts as 0 tasks: no line in its tracked task files is a checkbox, so "openspec list" and "openspec status" report no work and "openspec archive" has nothing to flag as incomplete. Write each task as "- [ ] 1.1 Description".

यह चेतावनी केवल तब सक्रिय होती है जब change के पूरे tracked सेट में कोई भी चेकबॉक्स न हो। वास्तविक चेकलिस्ट के बगल में गद्य वाली एक फ़ाइल होने पर रिपोर्ट नहीं होती, और लेखन के बीच में मौजूद change उसी क्षण अपनी प्रगति बनाए रखता है जब एक भी चेकबॉक्स मौजूद हो। --strict चेतावनी को विफलता में बदल देता है। लाइन संख्या --json रिपोर्ट में होती है।

Fenced blocks, HTML comments, YAML front matter और indented code स्कैन नहीं किए जाते, इसलिए पेस्ट किया गया टर्मिनल नमूना कभी task सूची के रूप में नहीं समझा जाता।

Archive merge संबंधी findings

changes के लिए, validate वर्तमान मुख्य specs के विरुद्ध archive के merge builder को बिना फ़ाइलें लिखे चलाता है। यह merge विरोधों को, जैसे गायब MODIFIED लक्ष्य या विरोधी ADDED requirement, INFO के रूप में रिपोर्ट करता है:

text

ℹ [INFO] api/spec.md: Archive would refuse this delta: api MODIFIED failed for header "### Requirement: Rate limiting" - not found

ये findings तब भी दिखाई देती हैं जब validation पास हो जाती है, टेक्स्ट और JSON आउटपुट दोनों में। INFO कभी exit code नहीं बदलता, --strict के अंतर्गत भी नहीं: एक गायब लक्ष्य किसी sibling change का हो सकता है जिसे अभी archive नहीं किया गया है। मुख्य specs में पहले से sync किए गए Deltas archive के मौजूदा merge नियमों का पालन करते हैं।

यह जाँच archive के बाद वाले merged-spec validation या retirement जाँचों को नहीं चलाती। साफ़ रिपोर्ट यह गारंटी नहीं देती कि archive सफल होगा।

यदि merge preflight शुरू नहीं हो सकता, तो एक INFO finding कारण बताती है। मौजूदा validation findings और exit code अपरिवर्तित रहते हैं।

विफल होने वाला आइटम प्रत्येक समस्या और उसका समाधान सूचीबद्ध करता है:

Change 'add-rate-limit' has issues
✗ [ERROR] api/spec.md: ADDED "Rate limiting" must include at least one scenario
Next steps:
  - Ensure change has deltas in specs/: use headers ## ADDED/MODIFIED/REMOVED/RENAMED Requirements
  - Each requirement MUST include at least one #### Scenario: block
  - Debug parsed deltas: openspec show add-rate-limit --json --deltas-only

--json रन के लिए एक रिपोर्ट प्रिंट करता है:

json

{
  "items": [
    {
      "id": "add-rate-limit",
      "type": "change",
      "valid": true,
      "issues": [],
      "durationMs": 2
    }
  ],
  "summary": {
    "totals": {
      "items": 1,
      "passed": 1,
      "failed": 0
    },
    "byType": {
      "change": {
        "items": 1,
        "passed": 1,
        "failed": 0
      }
    }
  },
  "version": "1.0",
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

issues प्रविष्टियों में ERROR, WARNING, या INFO का level होता है।

एग्जिट कोड

0: हर validated आइटम पास हुआ, खाली bulk scope सहित।
1: कोई आइटम विफल हुआ, रिपोर्ट अनुरोध अमान्य है, openspec/config.yaml पढ़ा नहीं जा सकता या मान्य YAML नहीं है, या रन विफल हुआ (उदाहरण के लिए अज्ञात नाम या कोई OpenSpec root नहीं)। जिस config को पढ़ा या पार्स नहीं किया जा सकता वह किसी भी आइटम की जाँच से पहले रन रोक देता है; --json के साथ इसे unreadable_config या unparseable_config कोड वाली एकल status प्रविष्टि के रूप में रिपोर्ट किया जाता है।

--report full|findings

स्पष्ट bulk validation scope के लिए आउटपुट चुनता है:

full: हर आइटम। यह डिफ़ॉल्ट है। स्पष्ट --report full रिपोर्ट metadata जोड़े बिना मौजूदा आउटपुट आकार बनाए रखता है।
findings: केवल समस्याओं वाले आइटम, जिनमें चेतावनियों या सूचनाओं वाले पास होने वाले आइटम भी शामिल हैं। हर आइटम फिर भी validated होता है। Totals, strict-mode व्यवहार, और exit codes अपरिवर्तित रहते हैं।

bash

openspec validate --all --report findings
openspec validate --archived --report findings --json

स्कोप

फ़्लैग	Findings `report.scope`
`--all`	`all`
`--changes`	`changes`
`--specs`	`specs`
`--changes --specs`, या `--all` के साथ `--changes` या `--specs` में से कोई भी	`all`
`--archived`	`archived`

दोनों स्पष्ट report मोड positional item नाम, गायब bulk scope, या archive और active scopes के संयोजन को अस्वीकार करते हैं।

Findings टेक्स्ट आउटपुट

Human output: stdout Scope: <scope> (<count> items) प्रिंट करता है, फिर totals। बिना किसी issue-bearing आइटम के:

text

Scope: all (2 items)
No item findings.
Totals: 2 passed, 0 failed (2 items)

Issue-bearing आइटम लेबल, severity लेबल, paths, और messages stderr पर प्रिंट होते हैं। Active-scope विफलताएँ totals के बाद Details: rerun संकेत बनाए रखती हैं। मौजूदा root banner और progress आउटपुट रिपोर्ट से पहले आ सकते हैं।

Findings JSON आउटपुट

--report findings --json एक दस्तावेज़ प्रिंट करता है। इस उदाहरण में दो साफ़ आइटम हैं:

json

{
  "report": {
    "kind": "validation-findings",
    "version": "1.0",
    "scope": "all",
    "returnedItems": 0,
    "totalItems": 2
  },
  "itemFindings": [],
  "summary": {
    "totals": { "items": 2, "passed": 2, "failed": 0 },
    "byType": {
      "change": { "items": 1, "passed": 1, "failed": 0 },
      "spec": { "items": 1, "passed": 1, "failed": 0 }
    }
  },
  "root": { "path": "/Users/you/projects/my-app", "source": "nearest" }
}

report.kind और report.version: validation-findings आकार, संस्करण 1.0 की पहचान करते हैं। कोई शीर्ष-स्तरीय version या items नहीं है।
report.returnedItems और report.totalItems: क्रमशः लौटाए गए रिकॉर्ड और सभी validated आइटम की गिनती करते हैं।
itemFindings: पूर्ण आइटम रिकॉर्ड जिनका issues array गैर-खाली है। इसमें ERROR, WARNING, और INFO issues शामिल हैं। प्रत्येक रिकॉर्ड id, type, valid, issues, और durationMs बनाए रखता है। Archived आइटम type: "change" का उपयोग करते हैं।
summary: पूरे रन के totals और प्रति-type गिनतियाँ, लौटाए गए उपसमुच्चय की गिनतियाँ नहीं। खाली scope में शून्य totals होते हैं और 0 पर बाहर निकलता है।
root: पूर्ण रिपोर्ट के समान चयनित-root metadata।

Record संरक्षण: लौटाए गए आइटम अपनी पूर्ण-रिपोर्ट क्रम और आइटम या issues पर कोई भी additive फ़ील्ड बनाए रखते हैं। Filtering messages या locations को फिर से नहीं लिखती, जिनमें वैकल्पिक line और column फ़ील्ड शामिल हैं।

Command विफलताएँ: root-selection या item-discovery विफलताएँ मौजूदा status diagnostic बनाए रखती हैं और 1 पर बाहर निकलती हैं। वे पूर्ण findings रिपोर्ट या सफल खाली रिपोर्ट नहीं लौटातीं।

अमान्य report अनुरोध

दोनों स्पष्ट report मोड root selection या item discovery से पहले इन अनुरोधों को अस्वीकार करते हैं:

असमर्थित report मान, जिसमें खाली स्ट्रिंग भी शामिल है।
positional item नाम, भले ही bulk फ़्लैग के साथ हो।
कोई स्पष्ट bulk scope नहीं।
--archived का --all, --changes, या --specs के साथ संयोजन।

JSON मोड में, अस्वीकृत अनुरोध केवल एकल-तत्व status array के साथ 1 पर बाहर निकलता है। इसमें कोई root या report payload नहीं होता:

bash

openspec validate --all --report bogus --json

json

{
  "status": [
    {
      "severity": "error",
      "code": "invalid_validation_report_request",
      "message": "Unknown validation report 'bogus'.",
      "fix": "Use --report full|findings with --all, --changes, --specs, or --archived, without an item name. Do not combine archived and active scopes."
    }
  ]
}

Human mode त्रुटि को stderr पर प्रिंट करता है। बिना मान वाला केवल --report stderr पर Commander syntax error है, --json के साथ भी; यह इस diagnostic envelope का उपयोग नहीं करता।

पूर्ण रिपोर्ट को बाहरी रूप से फ़िल्टर करें

कस्टम JSON दृश्य के लिए, पूर्ण रिपोर्ट को jq या PowerShell से फ़िल्टर करें। ये script उदाहरण validation exit code को बनाए रखते हैं और command-error दस्तावेज़ों को अक्षुण्ण छोड़ते हैं।

jq के साथ Bash में:

bash

if validation_json=$(openspec validate --all --json); then
  validation_exit=0
else
  validation_exit=$?
fi
printf '%s\n' "$validation_json" |
  jq 'if has("items") then .items |= map(select(.issues | length > 0)) else . end'
exit "$validation_exit"

PowerShell में:

powershell

$validationJson = openspec validate --all --json
$validationExit = $LASTEXITCODE
$validationReport = $validationJson | ConvertFrom-Json
if ($validationReport.PSObject.Properties.Name -contains 'items') {
  $validationReport.items = @($validationReport.items | Where-Object { $_.issues.Count -gt 0 })
}
$validationReport | ConvertTo-Json -Depth 100
exit $validationExit

ये कस्टम दृश्य पूर्ण रिपोर्ट की keys बनाए रखते हैं लेकिन साफ़ आइटम छोड़ देते हैं। ये न तो पूर्ण full-v1 रिपोर्ट हैं और न ही संस्करणित --report findings आकार।

openspec archive

पूरा हो चुके change को archive में ले जाता है और मुख्य specs को अपडेट करता है।

bash

openspec archive add-rate-limit -y                # एक change archive करें, उसके deltas merge करें
openspec archive add-rate-limit -y --skip-specs   # specs को बिना छेड़े archive करें

बिना नाम देने पर, archive आपसे एक change चुनने के लिए कहता है। इंटरैक्टिव टर्मिनल के बाहर यह exit कोड 1 के साथ बंद हो जाता है और उसकी जगह दोबारा चलाने का कमांड प्रिंट करता है।

आर्ग्युमेंट्स

आर्ग्युमेंट	यह क्या है
`change-name`	Archive किया जाने वाला change, फ़ोल्डर नाम से (`add-rate-limit`)।

विकल्प

फ़्लैग	प्रभाव
`-y, --yes`	हर पुष्टि का उत्तर 'हाँ' देता है: spec अपडेट, अपूर्ण टास्क, छोड़ा गया validation।
`--skip-specs`	मुख्य specs को बिना छेड़े archive करता है (इंफ़्रास्ट्रक्चर, टूलिंग, या केवल दस्तावेज़ीकरण वाले changes)।
`--no-validate`	Validation छोड़ देता है। Archive पहले आपसे पुष्टि माँगता है, और `-y` उसका उत्तर दे देता है।
`--json`	टेक्स्ट की जगह संरचित परिणाम प्रिंट करता है। Spec अपडेट की पुष्टि के लिए `--yes` आवश्यक है।
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय किसी पंजीकृत store को OpenSpec root के रूप में उपयोग करता है।

आउटपुट

एक सफल रन task status बताता है, spec अपडेट का पूर्वावलोकन दिखाता है, उन्हें लागू करता है, और archive फ़ोल्डर का नाम बताता है:

Task status: ✓ Complete

Specs to update:
  api: update
Applying changes to openspec/specs/api/spec.md:
  + 1 added
Totals: + 1, ~ 0, - 0, → 0
Specs updated successfully.
Change 'add-rate-limit' archived as '2026-08-11-add-rate-limit'.

Change फ़ोल्डर पूरा का पूरा openspec/changes/archive/2026-08-11-add-rate-limit/ में चला जाता है, और उसके नाम के आगे आज की तारीख जुड़ जाती है। प्रत्येक delta अपनी मुख्य spec में merge हो जाता है: ऊपर वाली ADDED requirement openspec/specs/api/spec.md में जोड़ दी गई थी। -y के बिना, archive पूर्वावलोकन दिखाता है और अपडेट करने से पहले पूछता है। मना करने पर भी change archive हो जाता है और specs को वैसे ही छोड़ दिया जाता है।

--json --yes के साथ:

json

{
  "archive": {
    "change": "add-rate-limit",
    "archivedAs": "2026-08-11-add-rate-limit",
    "path": "/Users/you/projects/my-app/openspec/changes/archive/2026-08-11-add-rate-limit",
    "specsUpdated": true,
    "totals": {
      "added": 1,
      "modified": 0,
      "removed": 0,
      "renamed": 0
    }
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

Archive पहले change को validate करता है और विफल होने वाले change को archive करने से इनकार कर देता है:

Validation errors in change delta specs:
  ✗ ADDED "Rate limiting" must include at least one scenario

Validation failed. Please fix the errors before archiving.
To skip validation (not recommended), use --no-validate flag.

अपूर्ण टास्क चेतावनी देते हैं लेकिन रोकते नहीं। इंटरैक्टिव मोड में archive पूछता है कि जारी रखा जाए या नहीं, और -y खुद ही जारी रख देता है:

Task status: 1/2 tasks
Warning: 1 incomplete task(s) found. Continuing due to --yes flag.

एग्ज़िट कोड

0: change archive हो गया — spec अपडेट के साथ या बिना।
1: validation विफल हुआ, change का नाम अज्ञात है, या पुष्टि ज़रूरी थी और कोई उत्तर पढ़ा नहीं जा सका।

openspec new

एक नई change डायरेक्टरी बनाता है।

bash

openspec new change add-caching                                # केवल मेटाडेटा
openspec new change add-search --goal "Users can search docs"  # एक goal दर्ज करें

new का केवल एक subcommand है, new change <name>। यह openspec/changes/<name>/ बनाता है, जिसमें केवल एक .openspec.yaml मेटाडेटा फ़ाइल होती है:

yaml

schema: spec-driven
created: 2026-08-11

आर्टिफैक्ट (proposal, specs, design, tasks) यहाँ scaffold नहीं किए जाते। आप इन्हें बाद में लिखते हैं, और openspec status बताता है कि अगला कौन-सा है।

आर्ग्युमेंट्स

आर्ग्युमेंट	यह क्या है
`name`	Change के लिए फ़ोल्डर नाम (`add-caching`)।

विकल्प

फ़्लैग	प्रभाव
`--description <text>`	Change डायरेक्टरी में यह टेक्स्ट देकर एक `README.md` भी बनाता है।
`--goal <text>`	`.openspec.yaml` में एक `goal:` लाइन सेव करता है।
`--schema <name>`	Change के लिए workflow schema। डिफ़ॉल्ट: `spec-driven`, जो शिप होने वाला एकमात्र schema है।
`--json`	बनाए गए change को टेक्स्ट की जगह JSON के रूप में प्रिंट करता है।
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय किसी पंजीकृत store को OpenSpec root के रूप में उपयोग करता है।

आउटपुट

Created change 'add-caching' at openspec/changes/add-caching/
Schema: spec-driven
Next: openspec status --change add-caching

जब कोई openspec/ डायरेक्टरी नहीं मिली, तो new change उसी जगह एक बना देता है और इसकी सूचना देता है:

Created change 'add-caching' at openspec/changes/add-caching/
Schema: spec-driven
Next: openspec status --change add-caching

Note: no OpenSpec root was found here, so one was created at openspec/.
Run `openspec init` to finish setting this project up, or delete that directory if you meant a different project.

यह सूचना बाकी मानव-पठनीय आउटपुट के साथ stdout पर जाती है, और --json के साथ कभी नहीं दिखती।

--json के साथ, किसी ऐसे प्रोजेक्ट में जिसमें पहले से openspec/ मौजूद है:

json

{
  "change": {
    "id": "add-caching",
    "path": "/Users/you/projects/my-app/openspec/changes/add-caching",
    "metadataPath": "/Users/you/projects/my-app/openspec/changes/add-caching/.openspec.yaml",
    "schema": "spec-driven"
  },
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

जब कोई openspec/ डायरेक्टरी नहीं मिली और new change ने एक बनाया, तो JSON का ढाँचा वैसा ही रहता है। root.path वही डायरेक्टरी होती है जहाँ से आपने कमांड चलाया, और root.source में implicit दिखता है:

json

"root": {
  "path": "/Users/you/projects/my-app",
  "source": "implicit"
}

एग्ज़िट कोड

0: change बन गया।
1: change पहले से मौजूद है, या schema अज्ञात है।## openspec status

एक परिवर्तन या प्रत्येक सक्रिय परिवर्तन के लिए आर्टिफैक्ट पूर्णता स्थिति की रिपोर्ट करता है।

bash

openspec status --change add-rate-limit          # चेकलिस्ट दृश्य
openspec status --change add-rate-limit --json   # संरचित रिपोर्ट
openspec status --all                            # प्रत्येक सक्रिय परिवर्तन
openspec status --all --json                     # एक बैच रिपोर्ट

जब सक्रिय परिवर्तन मौजूद होते हैं, तो --change या --all में से बिल्कुल एक का उपयोग करें। इनमें से किसी के बिना, स्थिति 1 पर समाप्त होती है और उपलब्ध परिवर्तनों की सूची दिखाती है, भले ही केवल एक ही मौजूद हो:

text

✖ Error: Missing required option --change (or --all for every active change). Available changes:
  add-rate-limit

जब परियोजना में कोई सक्रिय परिवर्तन नहीं होता है, तो स्थिति No active changes. Create one with: openspec new change <name> प्रिंट करती है और दोनों फ्लैग के बिना भी 0 पर समाप्त होती है। --all --json के साथ, वही खाली अवस्था { "changes": [], "message": "No active changes.", "root": ... } होती है।

विकल्प

फ्लैग	प्रभाव
`--change <id>`	जिस परिवर्तन पर रिपोर्ट करनी है, फ़ोल्डर नाम द्वारा।
`--all`	प्रत्येक सक्रिय परिवर्तन की रिपोर्ट करें, नाम के अनुसार क्रमबद्ध। इसे `--change` के साथ संयोजित नहीं किया जा सकता।
`--schema <name>`	`openspec/config.yaml` से स्वतः पता लगाए गए स्कीमा को ओवरराइड करें। एक अज्ञात नाम त्रुटि है।
`--json`	टेक्स्ट के बजाय एक संरचित रिपोर्ट प्रिंट करें।
`--store <id>`	वर्तमान परियोजना के बजाय OpenSpec रूट के रूप में एक पंजीकृत स्टोर का उपयोग करें।

आउटपुट

स्कीमा के आर्टिफैक्ट्स की एक चेकलिस्ट: [x] पूरा हुआ, [ ] लिखने के लिए तैयार, [-] ब्लॉक किया गया जब तक कि इस पर निर्भर आर्टिफैक्ट्स मौजूद न हों।

Change: add-rate-limit
Schema: spec-driven
Change root: /Users/you/projects/my-app/openspec/changes/add-rate-limit
Progress: 2/4 artifacts complete

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

Next: openspec instructions design --change "add-rate-limit" --json

Next: लाइन उस एक कमांड का नाम बताती है जो परिवर्तन को आगे बढ़ाती है, इसलिए openspec status एक ताज़ा सत्र में वापस एक परिवर्तन चुनने के लिए पर्याप्त है। यह अगले तैयार आर्टिफैक्ट का नाम बताता है जब योजनाकरण अधूरा होता है, और एक बार जब सभी योजनाकरण आर्टिफैक्ट्स मौजूद हो जाते हैं तो openspec instructions apply का नाम बताता है:

[x] proposal
[x] specs
[x] design
[x] tasks

All planning artifacts complete!
Next: openspec instructions apply --change "add-rate-limit" --json

यह --store <id> वह समय ले जाता है जब हल किया गया रूट एक स्टोर होता है, और JSON nextSteps वाक्य के समान ही कमांड का नाम बताता है।

--json प्रति-आर्टिफैक्ट निर्भरताओं, हल किए गए फ़ाइल पथों, और एक सुझाए गए अगले कदम को जोड़ता है। काटा हुआ:

json

{
  "changeName": "add-rate-limit",
  "schemaName": "spec-driven",
  "isComplete": false,
  "nextSteps": [
    "Run openspec instructions design --change \"add-rate-limit\" --json before writing that artifact."
  ],
  "artifacts": [
    {
      "id": "proposal",
      "outputPath": "proposal.md",
      "status": "done",
      "requires": []
    },
    {
      "id": "design",
      "outputPath": "design.md",
      "status": "ready",
      "requires": [
        "proposal"
      ]
    },
    {
      "id": "tasks",
      "outputPath": "tasks.md",
      "status": "blocked",
      "requires": [
        "specs",
        "design"
      ],
      "missingDeps": [
        "design"
      ]
    }
  ]
}

--all --json के साथ, changes प्रत्येक परिवर्तन के लिए उसी स्थिति ऑब्जेक्ट को रखता है, प्रति-परिवर्तन root के बिना। चयनित रूट एन्वेलप पर एक बार दिखाई देता है। यह उदाहरण ऊपर दिखाए गए प्रति-परिवर्तन स्थिति क्षेत्रों को काटता है:

json

{
  "changes": [
    {
      "changeName": "add-rate-limit",
      "schemaName": "spec-driven",
      "artifacts": []
    }
  ],
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest"
  }
}

यदि एक परिवर्तन लोड नहीं हो पाता है, तो बैच जारी रहता है। इसके एंट्री में changeName और एक status डायग्नोस्टिक होता है जबकि अन्य एंट्रीज़ उपलब्ध रहती हैं। कमांड 1 पर समाप्त होता है, JSON मोड सहित, इसलिए CI अधूरी रिपोर्ट को सफल मानकर स्वीकार नहीं करता है। JSON आउटपुट अभी भी एक पार्स करने योग्य दस्तावेज़ रहता है।

एक्जिट कोड्स

0: प्रत्येक अनुरोधित स्थिति प्रिंट हुई; एक खाली --all रिपोर्ट भी 0 पर समाप्त होती है।
1: एक अनुरोधित परिवर्तन लोड करने में विफल रहा, --change या --all गायब है, दो फ्लैग्स को मिला दिया गया है, परिवर्तन मौजूद नहीं है, या स्कीमा ओवरराइड अज्ञात है।

openspec instructions

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

bash

openspec instructions proposal --change add-rate-limit   # एक आर्टिफैक्ट कैसे लिखें
openspec instructions apply --change add-rate-limit      # परिवर्तन को कैसे लागू करें
openspec instructions archive --change add-rate-limit    # संग्रहीत करने के लिए इनपुट

तर्क

तर्क	यह क्या है
`artifact`	स्कीमा से एक आर्टिफैक्ट आईडी (`proposal`, `specs`, `design`, `tasks` in `spec-driven`), या सुरक्षित शब्द `apply` और `archive`।

विकल्प

फ्लैग	प्रभाव
`--change <id>`	जिस परिवर्तन के लिए निर्देश जनरेट करने हैं। आवश्यक।
`--schema <name>`	स्कीमा को ओवरराइड करें। अन्यथा `config.yaml` से स्वतः पता लगाया जाता है।
`--json`	टेक्स्ट के बजाय एक संरचित ऑब्जेक्ट प्रिंट करें।
`--store <id>`	वर्तमान परियोजना के बजाय OpenSpec रूट के रूप में एक पंजीकृत स्टोर का उपयोग करें।

आउटपुट

आर्टिफैक्ट रूप एक निर्देश ब्लॉक प्रिंट करता है: कार्य, लिखने वाली फ़ाइल, इसे कैसे लिखें, आर्टिफैक्ट का टेम्पलेट, और इसे पूरा करने से क्या अनलॉक होता है।

<artifact id="proposal" change="add-rate-limit" schema="spec-driven">

<task>
Create the proposal artifact for change "add-rate-limit".
Initial proposal document outlining the change
</task>

<output>
Write to: /Users/you/projects/my-app/openspec/changes/add-rate-limit/proposal.md
</output>

<instruction>
Create the proposal document that establishes WHY this change is needed.
...

apply संदर्भ फ़ाइलों, कार्य प्रगति, और कार्यशील निर्देश को प्रिंट करता है:

## Apply: add-rate-limit
Schema: spec-driven

### Context Files
- proposal: /Users/you/projects/my-app/openspec/changes/add-rate-limit/proposal.md
- specs: /Users/you/projects/my-app/openspec/changes/add-rate-limit/specs/api/spec.md
- tasks: /Users/you/projects/my-app/openspec/changes/add-rate-limit/tasks.md

### Progress
1/3 complete

### Tasks
- [x] 1.1 Add rate limit middleware
- [ ] 1.2 Return 429 with Retry-After header
- [ ] 1.3 Add tests for burst traffic

### Instruction
Read context files, work through pending tasks, mark complete as you go.
Pause if you hit blockers or need clarification.

No project context or operation guidance configured.

जब आवश्यक आर्टिफैक्ट्स गायब होते हैं, तो apply ### ⚠️ Blocked रिपोर्ट करता है और उनका नाम बताता है। archive परिवर्तन का नाम plus कॉन्फ़िगरेशन से कोई भी परियोजना संदर्भ और परिचालन मार्गदर्शन प्रिंट करता है। यदि कोई कॉन्फ़िगर नहीं है, तो यह कहता है और कुछ नहीं।

--json के साथ, प्रत्येक रूप एक ऑब्जेक्ट लौटाता है। आर्टिफैक्ट रूप शुरू होता है:

json

{
  "changeName": "add-rate-limit",
  "artifactId": "proposal",
  "schemaName": "spec-driven",
  "changeDir": "/Users/you/projects/my-app/openspec/changes/add-rate-limit",
  ...

और outputPath, existingOutputPaths, पूर्ण instruction और template स्ट्रिंग्स, dependencies, unlocks, और root के साथ जारी रहता है। apply रूप contextFiles, progress, tasks, taskTrackingConfigured, state (blocked, ready, all_done), और instruction को धारण करता है।

प्रत्येक tasks एंट्री में id, description, done, sourcePath, और line होता है। sourcePath वह निरंतर पथ है जिस फ़ाइल ने कार्य प्रदान किया था। line उस फ़ाइल में कार्य चेकबॉक्स का एक-आधारित लाइन नंबर है।

taskTrackingConfigured हमेशा एक बूलियन होता है: true जब स्कीमा एक गैर-शून्य apply.tracks सेट करती है, भले ही कोई फ़ाइल मिले नहीं, और अन्यथा false। यदि एक मिला ट्रैकिंग फ़ाइल पढ़ी नहीं जा सकती, तो unavailableTrackingFiles में इसका निरंतर path और त्रुटि reason होता है। यह फ़ील्ड तब छोड़ दिया जाता है जब हर मिला फ़ाइल पढ़ी जा सकती है। पढ़ी जा सकने वाली फ़ाइलें अभी भी tasks और progress में योगदान देती हैं, लेकिन state all_done नहीं हो सकता जब तक कि हर मिला फ़ाइल पढ़ी न जाए।

एक्जिट कोड्स

0: निर्देश प्रिंट हुए।
1: अज्ञात आर्टिफैक्ट, अज्ञात परिवर्तन, अज्ञात स्कीमा, या गायब --change। प्रत्येक त्रुटि वैध मानों की सूची दिखाती है।

openspec templates

किसी स्कीमा के आर्टिफ़ैक्ट्स के लिए रिज़ॉल्व किए गए टेम्पलेट पाथ प्रिंट करता है।

bash

openspec templates          # डिफ़ॉल्ट स्कीमा: spec-driven
openspec templates --json   # आर्टिफ़ैक्ट ids से टेम्पलेट पाथ का मैप

विकल्प

फ़्लैग	प्रभाव
`--schema <name>`	रिज़ॉल्व करने के लिए स्कीमा। डिफ़ॉल्ट: `spec-driven`.
`--json`	आर्टिफ़ैक्ट ids से टेम्पलेट पाथ का JSON मैप प्रिंट करता है।

आउटपुट

Schema: spec-driven
Source: package

proposal:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/proposal.md
specs:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/spec.md
design:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/design.md
tasks:
  /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/tasks.md

Source बताता है कि स्कीमा कहाँ से रिज़ॉल्व हुआ: project (आपके प्रोजेक्ट में openspec/schemas/), user (एक ग्लोबल ओवरराइड), या package (CLI में अंतर्निहित)। project का user पर, और user का package पर प्राथमिकता होती है।

json

{
  "proposal": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/proposal.md",
    "source": "package"
  },
  "specs": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/spec.md",
    "source": "package"
  },
  "design": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/design.md",
    "source": "package"
  },
  "tasks": {
    "path": "/usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven/templates/tasks.md",
    "source": "package"
  }
}

एग्ज़िट कोड

0: पाथ प्रिंट हुए।
1: अज्ञात स्कीमा। एरर उपलब्ध स्कीमाओं की सूची दिखाता है।

openspec schemas

उपलब्ध वर्कफ़्लो स्कीमाओं की सूची दिखाता है।

bash

openspec schemas          # नाम, विवरण, आर्टिफ़ैक्ट क्रम
openspec schemas --json   # मशीन-पठनीय, एजेंट उपयोग के लिए

विकल्प

फ़्लैग	प्रभाव
`--json`	JSON के रूप में आउटपुट (एजेंट उपयोग के लिए)।

आउटपुट

Available schemas:

  spec-driven
    Default OpenSpec workflow - proposal → specs → design → tasks
    Artifacts: proposal → specs → design → tasks

आपके प्रोजेक्ट से आने वाली स्कीमाओं पर (project) लेबल होता है, और ग्लोबल ओवरराइड्स पर (user override) लेबल होता है।

json

[
  {
    "name": "spec-driven",
    "description": "Default OpenSpec workflow - proposal → specs → design → tasks",
    "artifacts": [
      "proposal",
      "specs",
      "design",
      "tasks"
    ],
    "source": "package"
  }
]

एग्ज़िट कोड

0: स्कीमाओं की सूची दिखाई गई।
1: स्कीमा सूची पढ़ी नहीं जा सकी।## openspec schema

किसी स्कीमा का निरीक्षण, फ़ोर्क या निर्माण करता है (प्रायोगिक)। हर सबकमांड पहले stderr पर Note: Schema commands are experimental and may change. प्रिंट करता है।

bash

openspec schema which spec-driven          # जहाँ से एक स्कीमा रिज़ॉल्व होता है
openspec schema fork spec-driven my-flow   # किसी स्कीमा को प्रोजेक्ट में कॉपी करता है
openspec schema init my-schema             # शुरू से एक स्कीमा बनाता है

सबकमांड	यह क्या करता है
`which`	दिखाता है कि कोई स्कीमा कहाँ से रिज़ॉल्व होता है।
`validate`	किसी स्कीमा की संरचना और टेम्पलेट की जाँच करता है।
`fork`	अनुकूलन के लिए किसी मौजूदा स्कीमा को प्रोजेक्ट में कॉपी करता है।
`init`	एक नया प्रोजेक्ट-लोकल स्कीमा बनाता है।

स्कीमा तीन स्थानों से रिज़ॉल्व होते हैं। पहला मिलान जीतता है:

स्रोत	स्थान
`project`	वर्तमान प्रोजेक्ट में `openspec/schemas/`।
`user`	`~/.local/share/openspec/schemas/` (`XDG_DATA_HOME` और Windows `%LOCALAPPDATA%` का सम्मान किया जाता है)।
`package`	CLI के साथ भेजे गए स्कीमा। `spec-driven` यहाँ होता है।

openspec schema which

दिखाता है कि CLI किसी स्कीमा की कौन-सी कॉपी उपयोग करेगा।

bash

openspec schema which spec-driven
openspec schema which --all        # हर स्कीमा, स्रोत के अनुसार समूहित

आर्ग्यूमेंट

आर्ग्यूमेंट	यह क्या है
`name`	खोजा जाने वाला स्कीमा। आवश्यक है, जब तक `--all` सेट न हो। दोनों के बिना, which 1 पर समाप्त होता है।

विकल्प

फ़्लैग	प्रभाव
`--all`	हर स्कीमा को उसके रिज़ॉल्यूशन स्रोत के साथ सूचीबद्ध करता है।
`--json`	रिज़ॉल्यूशन को JSON के रूप में प्रिंट करता है।

आउटपुट

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

जब कोई उच्च-प्राथमिकता कॉपी किसी दूसरी को छिपाती है, तो एक Shadows: अनुभाग छिपी हुई कॉपियाँ सूचीबद्ध करता है। --json के साथ:

json

{
  "name": "my-flow",
  "source": "project",
  "path": "/Users/you/projects/my-app/openspec/schemas/my-flow",
  "shadows": []
}

अज्ञात नाम होने पर यह 1 पर समाप्त होता है और उपलब्ध स्कीमा सूचीबद्ध करता है।

openspec schema validate

किसी स्कीमा की संरचना और टेम्पलेट की जाँच करता है।

bash

openspec schema validate spec-driven   # एक स्कीमा, किसी भी स्रोत से
openspec schema validate               # हर प्रोजेक्ट-लोकल स्कीमा

यह सत्यापित करता है कि schema.yaml मौजूद है और पार्स होता है, कि संरचना स्कीमा फ़ॉर्मेट से मेल खाती है, कि हर आर्टिफ़ैक्ट की टेम्पलेट फ़ाइल स्कीमा की templates/ डायरेक्टरी के भीतर मौजूद है, और निर्भरता ग्राफ़ में कोई चक्र या अज्ञात संदर्भ नहीं हैं, जिसमें apply.requires भी शामिल है। कोई apply.tracks मान जो किसी आर्टिफ़ैक्ट के generates मान के बिल्कुल बराबर नहीं है, एक warning: पंक्ति प्रिंट करता है लेकिन सत्यापन विफल नहीं करता, क्योंकि तब OpenSpec यह नहीं बता सकता कि वह फ़ाइल किस आर्टिफ़ैक्ट की प्रगति से संबंधित है।

विकल्प

फ़्लैग	प्रभाव
`--json`	टेक्स्ट के बजाय संरचित रिपोर्ट प्रिंट करता है।
`--verbose`	हर सत्यापन चरण प्रिंट करता है।

आउटपुट

✓ Schema 'spec-driven' is valid

नाम के बिना, हर प्रोजेक्ट स्कीमा को Validation Results: हेडर के अंतर्गत एक पंक्ति मिलती है। विफल स्कीमा अपनी समस्याएँ सूचीबद्ध करता है और रन 1 पर समाप्त होता है:

✗ Schema 'my-schema' has errors:
  error: Template file 'tasks.md' not found for artifact 'tasks'

openspec schema fork

किसी मौजूदा स्कीमा को प्रोजेक्ट में कॉपी करता है ताकि आप उसे अनुकूलित कर सकें।

bash

openspec schema fork spec-driven my-flow

आर्ग्यूमेंट

आर्ग्यूमेंट	यह क्या है
`source`	कॉपी किया जाने वाला स्कीमा, किसी भी स्रोत स्थान से।
`name`	कॉपी का नाम। Kebab-case (`my-workflow`)। डिफ़ॉल्ट: `<source>-custom`।

विकल्प

फ़्लैग	प्रभाव
`--force`	मौजूदा गंतव्य स्कीमा को ओवरराइट करता है।
`--json`	परिणाम को JSON के रूप में प्रिंट करता है।

आउटपुट

✔ Forked 'spec-driven' to 'my-flow'

Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven (package)
Destination: /Users/you/projects/my-app/openspec/schemas/my-flow

फ़ोर्क openspec/schemas/ में बनता है, और इसके schema.yaml का name: फ़ील्ड नए नाम पर फिर लिखा जाता है:

openspec/schemas/my-flow/
├── schema.yaml
└── templates/
    ├── design.md
    ├── proposal.md
    ├── spec.md
    └── tasks.md

मौजूदा गंतव्य एक त्रुटि है, जब तक आप --force न दें। ऐसा फ़ोर्क जो स्रोत का नाम बनाए रखता है, मूल को शैडो करता है।

openspec schema init

स्टार्टर टेम्पलेट के साथ एक नया प्रोजेक्ट-लोकल स्कीमा बनाता है।

bash

openspec schema init my-schema --description "Lightweight flow" --artifacts proposal,tasks

इंटरैक्टिव टर्मिनल में --description और --artifacts के बिना, init एक विवरण, आर्टिफ़ैक्ट चेकलिस्ट और स्कीमा को प्रोजेक्ट डिफ़ॉल्ट बनाने के लिए पूछता है। टर्मिनल के बाहर यह नीचे दिए डिफ़ॉल्ट उपयोग करता है।

आर्ग्यूमेंट

आर्ग्यूमेंट	यह क्या है
`name`	नए स्कीमा का नाम। Kebab-case (`my-workflow`)।

विकल्प

फ़्लैग	प्रभाव
`--description <text>`	स्कीमा विवरण। डिफ़ॉल्ट: `Custom workflow schema for <name>`।
`--artifacts <list>`	`proposal`, `specs`, `design`, `tasks` में से अल्पविराम से अलग किए गए आर्टिफ़ैक्ट ID। डिफ़ॉल्ट: सभी चार।
`--default`	मौजूदा `openspec/config.yaml` या `openspec/config.yml` में `schema: <name>` लिखता है। यदि दोनों में से कोई नहीं है तो `openspec/config.yaml` बनाता है। नए परिवर्तन इस स्कीमा का उपयोग करते हैं।
`--no-default`	डिफ़ॉल्ट के बारे में प्रॉम्प्ट छोड़ता है।
`--force`	समान नाम वाले मौजूदा स्कीमा को ओवरराइट करता है।
`--json`	परिणाम को JSON के रूप में प्रिंट करता है।

स्कीमा निर्माण और --default कॉन्फ़िग अपडेट एक ही संचालन हैं। यदि OpenSpec कॉन्फ़िग को सत्यापित या लिख नहीं सकता, तो यह कॉन्फ़िग और किसी भी मौजूदा स्कीमा को अपरिवर्तित छोड़ देता है।

आउटपुट

✔ Created schema 'my-schema'

Schema created at: /Users/you/projects/my-app/openspec/schemas/my-schema

Artifacts: proposal, tasks

डिस्क पर लेआउट:

openspec/schemas/my-schema/
├── schema.yaml
└── templates/
    ├── proposal.md
    └── tasks.md

schema.yaml चुने गए आर्टिफ़ैक्ट को उनकी निर्भरताओं के साथ जोड़ता है। जब tasks शामिल होता है तो उसे एक apply चरण भी मिलता है जो tasks.md को ट्रैक करता है। स्कीमा का उपयोग openspec new --schema my-schema के साथ करें।

openspec store

स्टोर बनाता है और प्रबंधित करता है: आपकी मशीन पर रजिस्टर किए गए स्टैंडअलोन OpenSpec रिपो।

bash

openspec store setup team-context --path ~/openspec/team-context   # बनाता है और रजिस्टर करता है
openspec store register ~/stores/design-system                     # मौजूदा चेकआउट रजिस्टर करता है
openspec store list                                                # देखें कि क्या रजिस्टर है

रजिस्ट्रेशन एक प्रति-मशीन रजिस्ट्री में होते हैं: ~/.local/share/openspec/stores/registry.yaml, या जब XDG_DATA_HOME सेट हो तो $XDG_DATA_HOME/openspec/stores/registry.yaml। हर सबकमांड --json लेता है ताकि टेक्स्ट के बजाय संरचित रिपोर्ट प्रिंट की जा सके। openspec store को अनुपस्थित या अज्ञात सबकमांड के साथ चलाने पर यह 1 पर समाप्त होता है और सबकमांड सूचीबद्ध करता है।

सबकमांड	यह क्या करता है
`setup [id]`	स्टोर फ़ोल्डर बनाता है और उसे रजिस्टर करता है।
`register [path]`	मौजूदा स्टोर फ़ोल्डर रजिस्टर करता है।
`unregister <id>`	रजिस्ट्रेशन भूलता है। फ़ोल्डर डिस्क पर बना रहता है।
`remove <id>`	रजिस्ट्रेशन भूलता है और फ़ोल्डर हटाता है।
`list` (alias `ls`)	रजिस्टर किए गए स्टोर सूचीबद्ध करता है।
`doctor [id]`	रजिस्टर किए गए स्टोर के लिए रजिस्ट्रेशन, मेटाडेटा और Git स्थिति की जाँच करता है।

openspec store setup

स्टोर फ़ोल्डर बनाता है और उसे रजिस्टर करता है।

bash

openspec store setup team-context --path ~/openspec/team-context

इंटरैक्टिव टर्मिनल में, setup अनुपस्थित नाम और स्थान के लिए पूछता है और कुछ भी बनाने से पहले पुष्टि करता है। इसके बाहर, अनुपस्थित नाम या --path देने पर 1 पर समाप्त होता है और पास करने के लिए फ़्लैग बताता है। रजिस्टर किए गए स्टोर के लिए setup फिर से चलाने पर Registry: already registered रिपोर्ट करता है।

जब --path किसी दूसरे Git रिपोज़िटरी के अंदर हो, तो setup store_setup_inside_git_repo के साथ 1 पर समाप्त होता है, क्योंकि वहाँ स्टोर आरंभ करने से एक रिपोज़िटरी दूसरे के अंदर बन जाएगी। --no-init-git कोई रिपोज़िटरी नहीं बनाता, इसलिए यह उस जाँच को छोड़ता है। इसका उपयोग तब करें जब आपकी होम डायरेक्टरी स्वयं एक Git रिपोज़िटरी हो, जैसे dotfiles रिपो, और आप स्टोर को ~/openspec/<id> पर रखना चाहते हों।

आर्ग्यूमेंट

आर्ग्यूमेंट	यह क्या है
`id`	स्टोर नाम। यह वही id बनता है जिसे आप `--store` को पास करते हैं।

विकल्प

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

आउटपुट

Store ready: team-context
Location: /Users/you/stores/team-context
OpenSpec root: ready
Registry: registered

Next: run normal OpenSpec commands against this store, for example:
  openspec new change <change-id> --store team-context
Share this store by committing and pushing it like any Git repo.

--json रिपोर्ट करता है कि क्या बनाया गया और कहाँ रजिस्टर किया गया:

json

{
  "store": {
    "id": "design-system",
    "root": "/Users/you/stores/design-system",
    "metadata_path": "/Users/you/stores/design-system/.openspec-store/store.yaml"
  },
  "registry": {
    "path": "/Users/you/.local/share/openspec/stores/registry.yaml",
    "registered": true,
    "already_registered": false
  },
  "git": {
    "is_repository": true,
    "initialized": true,
    "committed": true
  },
  "created_files": [
    "openspec/",
    "openspec/specs/",
    "openspec/changes/",
    "openspec/changes/archive/",
    "openspec/config.yaml",
    "openspec/specs/.gitkeep",
    "openspec/changes/archive/.gitkeep",
    ".openspec-store/store.yaml"
  ],
  "status": []
}

openspec store register

मौजूदा स्टोर फ़ोल्डर रजिस्टर करता है, उदाहरण के लिए किसी टीममेट का स्टोर जिसे आपने क्लोन किया है।

bash

openspec store register ~/stores/design-system

फ़ोल्डर में एक स्वस्थ openspec/ रूट होना चाहिए। .openspec-store/store.yaml मौजूद होने पर, register दर्ज id का पुनः उपयोग करता है। इसके बिना, register वह मेटाडेटा बनाने से पहले पूछता है। इंटरैक्टिव टर्मिनल के बाहर, इसके बजाय --yes पास करें। एक मशीन प्रति स्टोर id केवल एक चेकआउट रजिस्टर कर सकती है। उसी id के अंतर्गत दूसरा पथ, या दूसरे id के अंतर्गत वही पथ, 1 पर समाप्त होता है।

आर्ग्यूमेंट

आर्ग्यूमेंट	यह क्या है
`path`	रजिस्टर किया जाने वाला स्टोर फ़ोल्डर (`~` का विस्तार होता है)। आवश्यक।

विकल्प

फ़्लैग	प्रभाव
`--id <id>`	स्टोर id। डिफ़ॉल्ट मेटाडेटा या फ़ोल्डर नाम।
`--yes`	स्वस्थ OpenSpec रूट के लिए स्टोर पहचान मेटाडेटा बनाने की पुष्टि करता है।

आउटपुट

Store registered: design-system
Location: /Users/you/stores/design-system
OpenSpec root: ready
Registry: registered

--json वही दस्तावेज़ आकार प्रिंट करता है जो store setup --json करता है।

openspec store unregister

रजिस्ट्रेशन भूलता है। फ़ोल्डर डिस्क पर बना रहता है।

bash

openspec store unregister design-system

Unregistered store: design-system
Files kept at: /Users/you/stores/design-system

openspec store remove

रजिस्ट्रेशन भूलता है और फ़ोल्डर हटाता है।

bash

openspec store remove design-system --yes

इंटरैक्टिव रूप से, remove हटाने से पहले पूछता है। --json के साथ या इंटरैक्टिव टर्मिनल के बाहर, हटाने के लिए --yes आवश्यक है:

Error: Pass --yes to delete store files non-interactively.
Fix: openspec store remove design-system --yes

जब फ़ोल्डर में मेल खाने वाला स्टोर मेटाडेटा नहीं होता, या जब उसमें कोई दूसरा रजिस्टर किया गया स्टोर होता है (उदाहरण के लिए Git submodule के रूप में vendored स्टोर), तो remove 1 पर समाप्त होता है और कुछ भी हटाता नहीं है। उस स्थिति में त्रुटि store_remove_contains_registered_store होती है: पहले openspec store unregister <nested-id> चलाएँ, या फ़ाइलों को हटाए बिना स्टोर को भूलने के लिए openspec store unregister <id> चलाएँ।

विकल्प

फ़्लैग	प्रभाव
`--yes`	लोकल स्टोर फ़ोल्डर हटाने की पुष्टि करता है।

आउटपुट

Removed store: design-system
Deleted: /Users/you/stores/design-system

openspec store list

रजिस्टर किए गए स्टोर सूचीबद्ध करता है। ls एक उपनाम है।

bash

openspec store list

OpenSpec stores (2)

ID              Location
design-system   /Users/you/stores/design-system
team-context    /Users/you/stores/team-context

कुछ भी रजिस्टर न होने पर, list No stores registered. और आगे चलाने के लिए setup तथा register कमांड प्रिंट करता है।

openspec store doctor

रजिस्टर किए गए स्टोर के लिए रजिस्ट्रेशन, मेटाडेटा और Git स्थिति की जाँच करता है।

bash

openspec store doctor                # हर रजिस्टर किया गया स्टोर
openspec store doctor team-context  # एक स्टोर

आउटपुट

Store doctor

team-context
  Location: /Users/you/stores/team-context
  OpenSpec root: ok
  Metadata: ok
  Git: repository detected (commits: yes, uncommitted changes: no, remote: none)
  Issues: none

एग्ज़िट कोड

0: रिपोर्ट प्रिंट हुई, तब भी जब कोई स्टोर समस्याएँ रिपोर्ट करता हो।
1: रिपोर्ट नहीं चल सकी (उदाहरण के लिए अज्ञात स्टोर id)।

openspec doctor

रिज़ॉल्व किए गए OpenSpec रूट के लिए संबंध स्वास्थ्य की रिपोर्ट करता है।

bash

openspec doctor                       # nearest openspec/ root above your cwd
openspec doctor --store team-context  # a registered store as the root

Doctor केवल-पढ़ने योग्य है: यह कभी क्लोन, सिंक या मरम्मत नहीं करता। यह रिपोर्ट करता है कि रूट स्वस्थ है या नहीं और openspec/config.yaml में घोषित प्रत्येक संदर्भ इस मशीन पर रिज़ॉल्व होता है या नहीं। जब आपके cwd के ऊपर कोई रूट न हो और --store भी न दिया गया हो, तो यह 1 के साथ बाहर निकलता है और आपके पंजीकृत स्टोरों के नाम बताता है।

विकल्प

फ़्लैग	प्रभाव
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय एक पंजीकृत स्टोर को OpenSpec रूट के रूप में उपयोग करें।
`--json`	स्वास्थ्य रिपोर्ट को JSON के रूप में प्रिंट करें।

आउटपुट

Doctor

Root
  Location: /Users/you/projects/my-app
  OpenSpec root: ok

References
  - team-context: ok (/Users/you/stores/team-context)

--store के साथ, रूट स्टोर होता है और रिपोर्ट में एक स्टोर पंक्ति जुड़ती है:

Using OpenSpec root: team-context (/Users/you/stores/team-context)
Doctor

Root
  Location: /Users/you/stores/team-context
  OpenSpec root: ok
  Store: team-context (metadata ok)

References
  (none declared)

json

{
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest",
    "healthy": true,
    "status": []
  },
  "store": null,
  "references": [
    {
      "store_id": "team-context",
      "root": "/Users/you/stores/team-context",
      "status": []
    }
  ],
  "status": []
}

निकास कोड

0: रिपोर्ट प्रिंट हुई, जिसमें समस्याएँ सूचीबद्ध होने पर भी शामिल है।
1: कोई रूट रिज़ॉल्व नहीं हुआ (आपके cwd के ऊपर कोई openspec/ नहीं और कोई --store नहीं), या अज्ञात --store id।

openspec context

रिज़ॉल्व किए गए OpenSpec रूट के लिए कार्यशील संदर्भ प्रिंट करता है: रूट के साथ-साथ openspec/config.yaml में घोषित प्रत्येक संदर्भित स्टोर, प्रत्येक के साथ एक फ़ेच कमांड।

bash

openspec context                       # nearest openspec/ root above your cwd
openspec context --store team-context  # a registered store as the root
openspec context --json                # agent brief

इस मशीन पर रिज़ॉल्व न होने वाले संदर्भ Not available on this machine अनुभाग में आते हैं, प्रत्येक के साथ एक समाधान होता है।

विकल्प

फ़्लैग	प्रभाव
`--store <id>`	वर्तमान प्रोजेक्ट के बजाय एक पंजीकृत स्टोर को OpenSpec रूट के रूप में उपयोग करें।
`--json`	एजेंट ब्रीफ़ को JSON के रूप में प्रिंट करें।
`--code-workspace <path>`	सेट के लिए VS Code वर्कस्पेस फ़ाइल भी लिखें।
`--force`	मौजूदा `--code-workspace` फ़ाइल को ओवरराइट करें।

आउटपुट

Working context for my-app (/Users/you/projects/my-app)

OpenSpec root
  my-app  /Users/you/projects/my-app

Referenced stores
  team-context  /Users/you/stores/team-context
    Fetch: openspec show <spec-id> --type spec --store team-context

--store के साथ, स्टोर ही पूरा सेट होता है:

Using OpenSpec root: team-context (/Users/you/stores/team-context)
Working context for team-context (/Users/you/stores/team-context)

OpenSpec root
  team-context  /Users/you/stores/team-context

No references declared; the working set is this root alone.

json

{
  "root": {
    "path": "/Users/you/projects/my-app",
    "source": "nearest",
    "role": "openspec_root"
  },
  "members": [
    {
      "role": "referenced_store",
      "id": "team-context",
      "path": "/Users/you/stores/team-context",
      "fetch": "openspec show <spec-id> --type spec --store team-context",
      "status": []
    }
  ],
  "status": []
}

वर्कस्पेस फ़ाइल लिखना

--code-workspace आपके द्वारा दिए गए पथ पर एक VS Code वर्कस्पेस फ़ाइल लिखता है: रूट के लिए एक फ़ोल्डर, और प्रत्येक उपलब्ध संदर्भित स्टोर के लिए एक ref:<id> फ़ोल्डर। अनुपलब्ध संदर्भ छोड़ दिए जाते हैं और सारांश पंक्ति में उनके नाम दिए जाते हैं, Wrote /Users/you/projects/my-app/openspec.code-workspace (2 folders)। सारांश stderr पर प्रिंट होता है, इसलिए --json का stdout एक ही JSON दस्तावेज़ रहता है। मौजूदा फ़ाइल होने पर 1 के साथ बाहर निकलता है, जब तक आप --force पास न करें।

json

{
  "folders": [
    {
      "name": "my-app",
      "path": "/Users/you/projects/my-app"
    },
    {
      "name": "ref:team-context",
      "path": "/Users/you/stores/team-context"
    }
  ]
}

निकास कोड

0: रिपोर्ट प्रिंट हुई।
1: कोई रूट रिज़ॉल्व नहीं हुआ (आपके cwd के ऊपर कोई openspec/ नहीं और कोई --store नहीं), या --code-workspace लेखन अस्वीकृत हुआ।## openspec workset

व्यक्तिगत कार्य दृश्यों को संयोजित करता है, रखता है और खोलता है। एक वर्कसेट फ़ोल्डरों की एक सहेजी गई, नामित सूची है जिनके साथ आप मिलकर काम करते हैं।

bash

openspec workset create checkout --member ~/projects/checkout-api --member web=~/projects/checkout-web
openspec workset list
openspec workset remove checkout --yes

उपकमांड	यह क्या करता है
`create [name]`	आपके द्वारा चुने गए फ़ोल्डरों का एक नामित कार्य दृश्य बनाएँ और सहेजें।
`list`, `ls`	सहेजे गए वर्कसेट्स उनके सदस्यों के साथ दिखाएँ।
`open <name>`	किसी सहेजे गए वर्कसेट को अपने टूल में खोलें (संपादक विंडो या एजेंट सत्र)।
`remove <name>`	किसी सहेजे गए वर्कसेट को हटाएँ (सदस्य फ़ोल्डर कभी नहीं छुए जाते)।

एक वर्कसेट पूरी तरह स्थानीय है:

इसकी स्थिति एक फ़ोल्डर में रहती है: ~/.local/share/openspec/worksets/ ($XDG_DATA_HOME/openspec/worksets/ जब सेट हो; %LOCALAPPDATA%\openspec\worksets\ Windows पर)।
सदस्य फ़ोल्डरों में कुछ भी नहीं लिखा जाता, और कुछ भी कमिट या साझा नहीं किया जाता।
उस एक फ़ोल्डर को हटाने से हर निशान मिट जाता है।

openspec workset create

फ़ोल्डरों का एक नामित कार्य दृश्य सहेजता है।

bash

openspec workset create checkout \
  --member ~/projects/checkout-api \
  --member web=~/projects/checkout-web

इंटरैक्टिव टर्मिनल में, create उन चीज़ों के लिए प्रॉम्प्ट करता है जो फ़्लैग प्रदान नहीं करते: नाम, एक-एक करके फ़ोल्डर, एक टूल, फिर अभी वर्कसेट खोलने का प्रस्ताव। उसके बाहर, गायब नाम या सदस्य एक त्रुटि है। पहले से सहेजा गया नाम हमेशा त्रुटि होता है। पहले इसे हटाएँ।

तर्क

तर्क	यह क्या है
`name`	वर्कसेट का नाम। Kebab-case: लोअरकेस अक्षर, संख्याएँ, एकल हाइफ़न। इंटरैक्टिव टर्मिनल के बाहर आवश्यक।

विकल्प

फ़्लैग	प्रभाव
`--member <member>`	`<path>` या `<name>=<path>` के रूप में सदस्य फ़ोल्डर, दोहराने योग्य। पहला प्राथमिक है। पथ एक मौजूदा फ़ोल्डर होना चाहिए, और लेबल डिफ़ॉल्ट रूप से फ़ोल्डर के अपने नाम पर होता है।
`--tool <id>`	इस वर्कसेट को खोलने के लिए पसंदीदा टूल। अंतर्निर्मित आईडी: `code` (VS Code), `cursor` (Cursor)। `claude` और `codex` अस्थायी रूप से अक्षम हैं।
`--json`	सहेजे गए वर्कसेट को JSON के रूप में प्रिंट करें।

आउटपुट

Saved workset 'checkout' (2 members) to your machine.
Open it any time with: openspec workset open checkout

openspec workset list

उनके सदस्यों के साथ सहेजे गए वर्कसेट्स दिखाता है, नाम के अनुसार क्रमबद्ध।

bash

openspec workset list   # alias: ls

विकल्प

फ़्लैग	प्रभाव
`--json`	वर्कसेट्स को JSON के रूप में प्रिंट करें।

आउटपुट

प्रति वर्कसेट एक ब्लॉक: नाम, उसका टूल जब उसका कोई हो, फिर प्रति सदस्य एक name path पंक्ति। कुछ भी सहेजा नहीं गया होने पर, list No worksets saved. Create one with: openspec workset create प्रिंट करता है।

checkout
  checkout-api  /Users/you/projects/checkout-api
  web           /Users/you/projects/checkout-web
checkout-tool  (opens in VS Code)
  checkout-api  /Users/you/projects/checkout-api

--json के साथ:

json

{
  "worksets": [
    {
      "name": "checkout",
      "members": [
        {
          "name": "checkout-api",
          "path": "/Users/you/projects/checkout-api"
        },
        {
          "name": "web",
          "path": "/Users/you/projects/checkout-web"
        }
      ]
    }
  ],
  "status": []
}

openspec workset open

आपके टूल में सहेजा गया वर्कसेट खोलता है। संपादक टूल्स (code, cursor) को एक जनरेट की गई .code-workspace फ़ाइल मिलती है। एक विंडो खुलती है और कमांड लौटता है। CLI एजेंट टूल्स (claude, codex) हर सदस्य संलग्न करके इस टर्मिनल पर कब्जा कर लेते। वे अस्थायी रूप से अक्षम हैं जब तक कि वह प्रवाह फिर से काम न करे, इसलिए वर्कसेट अभी IDE में खुलते हैं।

bash

openspec workset open checkout                # saved tool, or a prompt
openspec workset open checkout --tool cursor  # this tool just this once

तर्क

तर्क	यह क्या है
`name`	खोलने के लिए वर्कसेट।

विकल्प

फ़्लैग	प्रभाव
`--tool <id>`	केवल इस एक बार के लिए इस टूल के साथ खोलें।

--tool के बिना और कोई सहेजा गया टूल नहीं होने पर, open आपसे एक इंस्टॉल किया गया टूल चुनने के लिए प्रॉम्प्ट करता है। इंटरैक्टिव टर्मिनल के बाहर यह इसके बजाय 1 से बाहर निकलता है।

एक सदस्य फ़ोल्डर जो अब मौजूद नहीं है, उसे चेतावनी के साथ छोड़ दिया जाता है। जब प्राथमिक गायब हो, तो अगला बचा हुआ सदस्य इस खोलने के लिए प्राथमिक बन जाता है। जब कोई सदस्य फ़ोल्डर मौजूद नहीं है, तो खोलना विफल हो जाता है।
--json अस्वीकार कर दिया जाता है: open टर्मिनल को टूल को सौंप देता है और इसमें JSON मोड नहीं है।
जब लॉन्च विफल हो जाता है, तो त्रुटि मैनुअल मार्ग के साथ समाप्त होती है: वर्कस्पेस फ़ाइल का पथ और सदस्य सूची।

एग्जिट कोड

टूल को दर्पण करता है: कमांड टूल के अपने एग्जिट कोड के साथ बाहर निकलता है, और एक सिग्नल 128+n बन जाता है (Ctrl-C के बाद 130)।
1: अज्ञात वर्कसेट, कोई सदस्य फ़ोल्डर उपलब्ध नहीं, या कोई उपयोग करने योग्य टूल नहीं।

openspec workset remove

सहेजे गए वर्कसेट और उसकी जनरेट की गई .code-workspace फ़ाइल को हटाता है। सदस्य फ़ोल्डर कभी नहीं छुए जाते।

bash

openspec workset remove checkout --yes

इंटरैक्टिव टर्मिनल में, remove वर्कसेट दिखाता है और आपसे पुष्टि करने के लिए कहता है। --json के साथ, या टर्मिनल के बाहर, इसे --yes की आवश्यकता होती है और उसके बिना 1 से बाहर निकलता है।

विकल्प

फ़्लैग	प्रभाव
`--yes`	गैर-इंटरैक्टिव रूप से हटाने की पुष्टि करें।
`--json`	हटाने को JSON के रूप में प्रिंट करें।

आउटपुट

Removed workset 'checkout'. Member folders were not touched.

openspec version

चल रहे OpenSpec संस्करण और इस कॉपी को कैसे इंस्टॉल किया गया, की रिपोर्ट करता है।

bash

openspec version                 # local version and install details
openspec version --json          # structured local report
openspec version --check         # also check the registry for an update
openspec version --check --json  # structured local and update report

--check के बिना, यह कमांड स्थानीय है और किसी रजिस्ट्री से संपर्क नहीं करता। यह OpenSpec प्रोजेक्ट के बाहर काम करता है। मौजूदा openspec --version फ़्लैग सबसे छोटा रूप बना रहता है और केवल खाली संस्करण नंबर प्रिंट करता है।

विकल्प

फ़्लैग	प्रभाव
`--json`	टेक्स्ट के बजाय एक संस्करणयुक्त JSON दस्तावेज़ प्रिंट करें।
`--check`	नए रिलीज़ के लिए कॉन्फ़िगर की गई रजिस्ट्री जांचें।

आउटपुट

वैश्विक npm इंस्टॉल के लिए:

text

OpenSpec 1.13.2 (npm, global)

इंस्टॉल दायरा global, project, npx जैसे अशाश्वत रनर के लिए temporary, एक चेकआउट के लिए source, या standalone install के लिए standalone है। OpenSpec अनुमान लगाने के बजाय विवरणों को छोड़ देता है जिन्हें वह पहचान नहीं सकता।

--json अज्ञात विवरणों को स्पष्ट null मानों के रूप में रखता है:

json

{
  "schemaVersion": 1,
  "version": "1.13.2",
  "install": {
    "location": "/opt/homebrew/lib/node_modules/@fission-ai/openspec",
    "packageManager": "npm",
    "scope": "global"
  }
}

--check के साथ, उपलब्ध अपडेट नवीनतम संस्करण और एक कमांड जोड़ता है जब OpenSpec उस इंस्टॉल के लिए एक सुरक्षित कमांड पहचान सके:

text

OpenSpec 1.13.2 (npm, global)
Update available: 1.14.0
  npm install -g @fission-ai/openspec@latest

json

{
  "schemaVersion": 1,
  "version": "1.13.2",
  "install": {
    "location": "/opt/homebrew/lib/node_modules/@fission-ai/openspec",
    "packageManager": "npm",
    "scope": "global"
  },
  "update": {
    "status": "available",
    "latest": "1.14.0",
    "command": "npm install -g @fission-ai/openspec@latest",
    "canSelfUpgrade": true
  }
}

अपडेट स्थिति मान:

स्थिति	अर्थ
`available`	रजिस्ट्री ने चल रहे संस्करण से नया एक सुरक्षित संस्करण लौटाया।
`current`	जांच पूरी हुई और कोई नया संस्करण नहीं मिला।
`disabled`	एक मौजूदा गोपनीयता या अपडेट-जांच सेटिंग ने रजिस्ट्री एक्सेस को रोक दिया। `latest` `null` है।
`offline`	रजिस्ट्री अनुपलब्ध थी या एक अनुपयोगी प्रतिक्रिया लौटाई। `latest` `null` है।

स्टैंडअलोन इंस्टॉल के लिए, अपडेट कमांड openspec install है।

DO_NOT_TRACK, टेलीमेट्री ऑप्ट-आउट, OPENSPEC_NO_UPDATE_CHECK, CI पहचान, और अस्वीकृत गैर-HTTPS रजिस्ट्री ओवरराइड जांच को अक्षम कर देते हैं। अक्षम और ऑफ़लाइन जांच अभी भी 0 से बाहर निकलती हैं क्योंकि अपडेट उपलब्धता सलाहकार है। यह कमांड कभी भी OpenSpec को अपग्रेड नहीं करता; canSelfUpgrade केवल इस बात की रिपोर्ट करता है कि क्या मौजूदा openspec update पथ इस कॉपी को सुरक्षित रूप से अपग्रेड कर सकता है।

एग्जिट कोड

0: स्थानीय रिपोर्ट प्रिंट हुई, अक्षम या ऑफ़लाइन अपडेट जांच सहित।
1: कमांड सिंटैक्स अमान्य था, जैसे असमर्थित --upgrade विकल्प।

openspec install

स्टैंडअलोन openspec को इंस्टॉल करता है। स्विच करने के लिए इसे npm या Homebrew इंस्टॉल से चलाएँ, या उसे उसी जगह अपग्रेड करने के लिए स्टैंडअलोन इंस्टॉल से चलाएँ।

bash

openspec install          # नवीनतम रिलीज़
openspec install 1.15.0   # कोई विशिष्ट रिलीज़

यह इंस्टॉल स्क्रिप्ट चलाता है, जो उस नवीनतम रिलीज़ को चुनती है जिसकी सभी फ़ाइलें अटैच होती हैं, और आपकी मशीन के लिए फ़ाइल चुनकर उसे उस रिलीज़ के SHA256SUMS के विरुद्ध जाँचती है:

पैकेज मैनेजर से: ~/.local/bin (Windows: %LOCALAPPDATA%\Programs\openspec) में इंस्टॉल करता है और पुरानी कॉपी हटाने वाला कमांड प्रिंट करता है, जैसे npm uninstall -g @fission-ai/openspec। यह वह कॉपी स्वयं कभी नहीं हटाता।
स्टैंडअलोन इंस्टॉल से: चल रही फ़ाइल को उसी जगह, उसी नाम के साथ बदल देता है।

इसके बाद यह बताता है कि openspec अब कौन-सी कॉपी चला रहा है, क्योंकि आपके PATH पर पहले आने वाली पैकेज-मैनेजर कॉपी तब तक चलती रहती है जब तक आप उसे हटा नहीं देते।

आर्ग्युमेंट

आर्ग्युमेंट	यह क्या है
`version`	इंस्टॉल की जाने वाली रिलीज़, जैसे `1.15.0`। वैकल्पिक; डिफ़ॉल्ट रूप से नवीनतम।

OPENSPEC_INSTALL_DIR और OPENSPEC_INSTALL_NAME से कोई अन्य फ़ोल्डर या फ़ाइल नाम चुना जा सकता है।

एक्ज़िट कोड

0: इंस्टॉल हो गया।
1: दिया गया वर्शन कोई रिलीज़ वर्शन नहीं है, या डाउनलोड या इंस्टॉल विफल हो गया। आपकी वर्तमान कॉपी वैसी ही रहती है।

openspec feedback

OpenSpec के बारे में फ़ीडबैक सबमिट करता है।

bash

openspec feedback "Validate output is hard to scan"
openspec feedback "Archive fails on Windows" --body "Steps: init, propose, archive. Error: EPERM."

CLI आपका संदेश आपके gh CLI के ज़रिए Fission-AI/OpenSpec रिपो पर GitHub issue के रूप में दर्ज करता है। शीर्षक Feedback: <message> हो जाता है। बॉडी बग फ़ॉर्म की हेडिंग्स का उपयोग करती है: आपका संदेश What happened के अंतर्गत, आपका --body टेक्स्ट Details के अंतर्गत, और एक Minimal steps to reproduce सेक्शन जो आपसे स्टेप्स जोड़ने को कहता है, क्योंकि CLI उन्हें स्वयं नहीं भर सकता। एक फ़ुटर CLI वर्शन, प्लेटफ़ॉर्म और टाइमस्टैम्प जोड़ता है। issue को feedback लेबल मिलता है। यदि रिपो वह लेबल परिभाषित नहीं करती, तो CLI उसके बिना पुनः प्रयास करता है और यह भी बताता है।

आर्ग्युमेंट

आर्ग्युमेंट	यह क्या है
`message`	एक-पंक्ति का सारांश। issue का शीर्षक बन जाता है। आवश्यक।

विकल्प

फ़्लैग	प्रभाव
`--body <text>`	issue बॉडी में जोड़ा जाने वाला विस्तृत विवरण।

आउटपुट

सफलता की स्थिति में:

✓ Feedback submitted successfully!
Issue URL: https://github.com/Fission-AI/OpenSpec/issues/1234

gh इंस्टॉल न होने पर, या gh लॉग इन न होने पर, कुछ भी सबमिट नहीं होता। CLI आपका फ़ॉर्मेट किया हुआ फ़ीडबैक --- FORMATTED FEEDBACK --- मार्करों के बीच प्रिंट करता है, फिर एक लिंक देता है जो बग रिपोर्ट फ़ॉर्म खोलता है — जिसमें शीर्षक, what happened (आपका संदेश और --body टेक्स्ट), CLI वर्शन, और environment (प्लेटफ़ॉर्म और Node वर्शन) पहले से भरे होते हैं। फ़ॉर्म का शेष भाग आप ब्राउज़र में पूरा करते हैं। लॉग इन न होने की स्थिति में To auto-submit in the future: gh auth login भी जोड़ा जाता है।

एक्ज़िट कोड

0: issue बन गया, या मैनुअल-सबमिशन फ़ॉलबैक चला (कोई gh नहीं, या gh लॉग इन नहीं)।
1: कोई संदेश नहीं दिया गया।
gh का अपना कोड: प्रमाणीकरण के बाद gh विफल हुआ (नेटवर्क, रेट लिमिट, issues डिसेबल्ड)। CLI पहले आपका फ़ीडबैक और मैनुअल-सबमिशन URL दोबारा प्रिंट करता है।

openspec completion

शेल completion इंस्टॉल या जेनरेट करता है।

bash

openspec completion install        # आपका शेल पहचानें, इंस्टॉल करें, कॉन्फ़िग जोड़ें
openspec completion generate zsh   # स्क्रिप्ट को stdout पर प्रिंट करें

समर्थित शेल: zsh, bash, fish, powershell। हर सबकमांड एक वैकल्पिक शेल आर्ग्युमेंट लेता है। इसे छोड़ दें तो CLI वातावरण से आपका शेल पहचान लेता है।

सबकमांड	यह क्या करता है
`generate [shell]`	completion स्क्रिप्ट को stdout पर प्रिंट करता है।
`install [shell]`	स्क्रिप्ट लिखता है और आपकी शेल स्टार्टअप फ़ाइल कॉन्फ़िगर करता है।
`uninstall [shell]`	स्क्रिप्ट और कॉन्फ़िग ब्लॉक हटाता है।

Nix से इंस्टॉल करने पर, completion पहले से मौजूद रहते हैं: flake पैकेज Bash, Fish, और Zsh स्क्रिप्ट मानक स्थानों पर शिप करता है, इसलिए install की आवश्यकता नहीं होती (इंस्टॉलेशन)।

openspec completion generate

स्क्रिप्ट प्रिंट करता है और कुछ भी लिखता नहीं।

#compdef openspec

# OpenSpec CLI के लिए Zsh completion स्क्रिप्ट
# ऑटो-जेनरेटेड - इसे मैन्युअल रूप से संपादित न करें

_openspec() {
  local context state line
  typeset -A opt_args
...

openspec completion install

स्क्रिप्ट लिखता है और आपकी शेल कॉन्फ़िग संपादित करता है। कॉन्फ़िग में किए गए बदलाव # OPENSPEC:START और # OPENSPEC:END मार्करों के बीच होते हैं। मौजूदा स्क्रिप्ट को पहले बैक अप किया जाता है (.backup-<timestamp> कॉपी)।

शेल	स्क्रिप्ट स्थान	संपादित कॉन्फ़िग
zsh	`~/.zsh/completions/_openspec`	`$ZDOTDIR/.zshrc` जब `ZDOTDIR` एक पूर्ण पथ हो, अन्यथा `~/.zshrc`
bash	`~/.local/share/bash-completion/completions/openspec`	`~/.bashrc`
fish	`~/.config/fish/completions/openspec.fish`	कोई नहीं: fish इसे ऑटो-लोड कर लेता है।
powershell	आपकी प्रोफ़ाइल के बगल में `OpenSpecCompletion.ps1`	`$PROFILE`

Oh My Zsh इंस्टॉल होने पर, स्क्रिप्ट इसके बजाय $ZSH_CUSTOM/completions/_openspec में जाती है (डिफ़ॉल्ट ~/.oh-my-zsh/custom/completions/_openspec)।

सापेक्ष या ~-उपसर्ग वाला ZDOTDIR नज़रअंदाज़ किया जाता है, और इसके बजाय ~/.zshrc संपादित किया जाता है। स्क्रिप्ट पहले से वर्तमान होने पर भी, install दोबारा चलाने से ब्लॉक उस .zshrc में जुड़ जाता है जिसे zsh पढ़ता है।

विकल्प

फ़्लैग	प्रभाव
`--verbose`	इंस्टॉल किया गया पथ, कोई बैकअप पथ, और कौन-सी कॉन्फ़िग फ़ाइल संपादित हुई — यह भी प्रिंट करता है।

आउटपुट

✓ Completion script installed and .zshrc configured successfully

Restart your shell or run: exec zsh

openspec completion uninstall

स्क्रिप्ट और मार्क किए गए कॉन्फ़िग ब्लॉक को हटाता है। आपकी कॉन्फ़िग को छूने से पहले पुष्टि माँगता है (डिफ़ॉल्ट: No)।

zsh के लिए, यह उस .zshrc को साफ़ करता है जिसे install संपादित करता है, और साथ ही ~/.zshrc को भी, यदि कोई पुराना इंस्टॉल वहाँ ZDOTDIR के अंतर्गत ब्लॉक छोड़ गया हो। यदि कोई ब्लॉक हटाया नहीं जा सकता, तो uninstall फ़ाइल का नाम बताता है और एक्ज़िट कोड 1 के साथ बाहर निकलता है।

विकल्प

फ़्लैग	प्रभाव
`-y, --yes`	पुष्टि के प्रॉम्प्ट छोड़ देता है।

आउटपुट

✓ Completion script removed from /Users/you/.zsh/completions/_openspec. Removed OpenSpec configuration from ~/.zshrc

एक्ज़िट कोड

0: स्क्रिप्ट जेनरेट, इंस्टॉल, या हटाई गई। रद्द किया गया uninstall भी एक्ज़िट कोड 0 के साथ बाहर निकलता है।
1: शेल समर्थित नहीं है या पहचाना नहीं गया, या कोई install या uninstall चरण विफल हुआ।

openspec change

show, list, और validate का डिप्रिकेटेड संज्ञा-रूप। हर रन में चेतावनी दिखाई जाती है और क्रिया-प्रथम (verb-first) कमांड की ओर संकेत दिया जाता है, और फिर भी कमांड चल जाती है:

Warning: The "openspec change ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec list", "openspec validate --changes").
Warning: "openspec change list" is deprecated. Use "openspec list".
add-rate-limit

डिप्रिकेटेड	इसके बजाय उपयोग करें
`openspec change show <name>`	`openspec show <name>`
`openspec change list`	`openspec list`
`openspec change validate <name>`	`openspec validate <name>` (सभी चेंज के लिए: `openspec validate --changes`)

फ़्लैग्स का दस्तावेज़ीकरण क्रिया-प्रथम सेक्शन में किया गया है।

openspec spec

show, list, और validate का डिप्रिकेटेड संज्ञा-रूप। हर रन में चेतावनी दिखाई जाती है और क्रिया-प्रथम कमांड की ओर संकेत दिया जाता है, और फिर भी कमांड चल जाती है:

Warning: The "openspec spec ..." commands are deprecated. Prefer verb-first commands (e.g., "openspec show", "openspec validate --specs").
api

डिप्रिकेटेड	इसके बजाय उपयोग करें
`openspec spec show <id>`	`openspec show <id>`
`openspec spec list`	`openspec list --specs`
`openspec spec validate <id>`	`openspec validate <id>` (सभी स्पेक के लिए: `openspec validate --specs`)

फ़्लैग्स का दस्तावेज़ीकरण क्रिया-प्रथम सेक्शन में किया गया है।

CLI ​

कमांड्स ​

openspec update ​

openspec config ​

openspec config path ​

openspec config list ​

openspec config get ​

openspec config set ​

openspec config unset ​

openspec config reset ​

openspec config edit ​

openspec config profile ​

openspec list ​

openspec show ​

openspec view ​

openspec validate ​

--report full|findings ​

Findings टेक्स्ट आउटपुट ​

Findings JSON आउटपुट ​

अमान्य report अनुरोध ​

पूर्ण रिपोर्ट को बाहरी रूप से फ़िल्टर करें ​

openspec archive ​

openspec new ​

openspec instructions ​

openspec templates ​

openspec schemas ​

openspec schema which ​

openspec schema validate ​

openspec schema fork ​

openspec schema init ​

openspec store ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

openspec doctor ​

openspec context ​

openspec workset create ​

openspec workset list ​

openspec workset open ​

openspec workset remove ​

openspec version ​

openspec install ​

openspec feedback ​

openspec completion ​

openspec completion generate ​

openspec completion install ​

openspec completion uninstall ​

openspec change ​

openspec spec ​

CLI

कमांड्स

openspec update

openspec config

openspec config path

openspec config list

openspec config get

openspec config set

openspec config unset

openspec config reset

openspec config edit

openspec config profile

openspec list

openspec show

openspec view

openspec validate

--report full|findings

Findings टेक्स्ट आउटपुट

Findings JSON आउटपुट

अमान्य report अनुरोध

पूर्ण रिपोर्ट को बाहरी रूप से फ़िल्टर करें

openspec archive

openspec new

openspec instructions

openspec templates

openspec schemas

openspec schema which

openspec schema validate

openspec schema fork

openspec schema init

openspec store

openspec store setup

openspec store register

openspec store unregister

openspec store remove

openspec store list

openspec store doctor

openspec doctor

openspec context

openspec workset create

openspec workset list

openspec workset open

openspec workset remove

openspec version

openspec install

openspec feedback

openspec completion

openspec completion generate

openspec completion install

openspec completion uninstall

openspec change

openspec spec