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`	تثبيت أو إنشاء إكمالات shell.

مُهملة

الأمر	ماذا يفعل
`openspec change`	صيغة الاسم لأوامر show و list و validate للتغييرات. تحذر واجهة سطر الأوامر وتشير إلى الأوامر التي تبدأ بفعل.
`openspec spec`	صيغة الاسم لأوامر show و list و validate للمواصفات، مع نفس التحذير.

كل أمر يأخذ -h, --help. أمر openspec المجرد يأخذ أيضًا:

-V, --version: طباعة إصدار واجهة سطر الأوامر.
--no-color: تعطيل الإخراج الملون.

openspec init

يقوم بتهيئة OpenSpec في مشروع.

bash

openspec init                        # current directory, interactive tool picker
openspec init --tools claude,cursor  # set up specific tools, no prompts
openspec init --tools none           # openspec/ structure only, no tool files

بدون --tools، يطالبك init باختيار الأدوات في طرفية تفاعلية. خارج الطرفية التفاعلية، يقوم بإعداد الأدوات التي يكتشفها في المشروع. إذا لم يكتشف أي أدوات، يخرج بالرمز 1 ويسرد المعرفات الصالحة.

مستودعات التخزين فقط

عندما يحتوي openspec/config.yaml على سطر store: ولا يحتوي المستودع على مواصفات أو تغييرات محلية، قم بتشغيل init من جذر المستودع:

bash

# install Claude Code integration files in the code repo
openspec init --tools claude

ملفات التكامل: تُكتب في مستودع الكود.
openspec/config.yaml: يُحفظ كما هو بدون أي تغيير.
openspec/specs/ و openspec/changes/: لا تُنشأ في مستودع الكود.

تشغيل init من دليل فرعي يخرج بالرمز 1 ويخبرك بتشغيله من جذر المستودع. --language يخرج أيضاً بالرمز 1 لأن اللغة تنتمي إلى إعداد المتجر الخارجي. قم بتشغيل init في جذر المتجر أو عدّل ذلك الإعداد مباشرة.

المعاملات

المعامل	ما هو
`path`	دليل المشروع المراد تهيئته. الافتراضي: الدليل الحالي. يُنشأ إذا لم يكن موجوداً.

الخيارات

الخيار	التأثير
`--tools <tools>`	معرفات الأدوات مفصولة بفواصل، أو `all`، أو `none`. يتخطى الاختيار التفاعلي. المعرفات مدرجة في الأدوات المدعومة.
`--language <language>`	إضافة تعليمة لغة إلى إعداد مشروع جديد. يُرفض عندما يشير سطر `store:` في المستودع إلى متجر خارجي.
`--force`	إزالة الملفات من تخطيطات OpenSpec القديمة بدون سؤال. في التشغيل التفاعلي يتم التأكيد أولاً.
`--profile <profile>`	تجاوز ملف التعريف للإعداد العام لهذا التشغيل: `core` (مجموعة سير العمل القياسية) أو `custom` (سير العمل المحفوظ في الإعداد العام).
`--no-animation`	عرض شاشة ترحيب ثابتة بدلاً من المتحركة.

المخرجات

كل أداة مختارة تحصل على مهارات وأوامر OpenSpec في دليلها الخاص:

▌ OpenSpec structure created
✔ Setup complete for Claude Code

OpenSpec Setup Complete

Created: Claude Code
6 skills and 6 commands in .claude/
Config: openspec/config.yaml (schema: spec-driven)

Getting started:
  Start your first change: /opsx:propose "your idea"

Restart your IDE for the new commands to take effect.

--tools none ينشئ فقط openspec/config.yaml. في مشروع تمت تهيئته مسبقاً، يعيد init كتابة الملفات المثبتة في مكانها وتقرأ الملخص Refreshed: Claude Code مع Config: openspec/config.yaml (exists).

رموز الخروج

0: اكتمال الإعداد.
1: قيمة --tools أو --profile غير صالحة، أو تشغيل غير تفاعلي دون أدوات مكتشفة ودون --tools، أو استدعاء غير صالح لمستودع تخزين فقط.

openspec update

يحدّث ملفات التعليمات المثبتة لـ OpenSpec.

bash

openspec update             # refresh tools whose files are older than the CLI
openspec update --force     # rewrite files even when they're current
openspec update --dry-run   # list what an update would change, and change nothing

يبحث update عن الأدوات التي هيأها init ويقارن ملفاتها المولّدة بإصدار واجهة سطر الأوامر. عند وجود إصدار أحدث من OpenSpec، يعرض أولاً ترقية واجهة سطر الأوامر ثم يعيد التشغيل بالإصدار المُرقّى. اضبط OPENSPEC_NO_UPDATE_CHECK=1 لتخطي التحقق.

المعاملات

المعامل	ما هو
`path`	دليل المشروع المراد تحديثه. الافتراضي: الدليل الحالي.

الخيارات

الخيار	التأثير
`--force`	إعادة كتابة ملفات كل أداة مُهيأة حتى عندما تكون محدثة.
`--dry-run`	الإبلاغ عن كل ملف سيضيفه التحديث أو يغيره أو يحذفه، وعدم كتابة أي شيء. لا تحقق من ترقية واجهة سطر الأوامر، لا مطالبات. اجمع مع `--force` لمعاينة تحديث قسري.
`--json`	مع `--dry-run`، طباعة الخطة بصيغة JSON. بدون `--dry-run` يخرج بالرمز 1.

معاينة التحديث

--dry-run يخطط للتحديث كما يفعله التشغيل غير التفاعلي: نفس مسار الكود، مع تسجيل كل عملية كتابة وحذف بدلاً من تنفيذها. كل ملف لمسه التحديث الفعلي مدرج، بما في ذلك:

نقل ملفات OpenSpec من الدليل السابق للأداة (.kimi/ إلى .kimi-code/، .windsurf/ إلى .devin/، .codex/ و .agent/ إلى .agents/)؛
حفظ الإعداد العام عند الحصول على تثبيت من قبل ملفات التعريف؛
مزامنة ملفات وكيل GitHub Copilot السحابي؛
مع --force، إعداد الأدوات الموجودة فقط في العناصر القديمة وتنظيف تلك العناصر، بما في ذلك مطالبات Codex العامة المتقاعدة.

bash

openspec update --dry-run

2 file(s) would change:
  update  .claude/skills/openspec-propose/SKILL.md  (claude)
  add     ~/.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`	المسار نسبة إلى المشروع. الملف خارج المشروع، مثل مهارة عامة أو الإعداد العام، يُعرض من دليل المنزل بصيغة `~/...`، أو كمسار مطلق عندما يكون خارج المنزل أيضاً.
`changes[].action`	`add` أو `update` أو `delete`. الملف الذي تتطابق بايتاته الجديدة مع القديمة لا يُدرج.
`changes[].tool`	الأداة المُهيأة التي ينتمي إليها الملف، مثل `claude`. الملفات التي تنتمي إلى OpenSpec نفسه وليس لأداة معينة، كالإعداد العام وتنظيف العناصر القديمة، تكون `openspec`.
`notes[]`	`{ code, message }` لخطوة يُسأل عنها مستخدم الطرفية. `legacy-tool-directories`: نقل يسأله عنه التشغيل التفاعلي أولاً؛ `changes` يدرجكه كمنفذ. `legacy-artifacts`: تم العثور على ملفات من تخطيط OpenSpec القديم، مثل أوامر slash `openspec-proposal.md` أو كتل OpenSpec في `AGENTS.md`. بدون `--force` يترك التحديث غير التفاعليها كما هي، لذا لا يدرجها `changes` أيضاً؛ `--dry-run --force` يدرج تنظيفها. فارغ في التحديث العادي.
`failures[]`	`{ tool, error }` لكل أداة سيفشل التحديث الفعلي عليها، بما في ذلك كتابة لا يمكن إجراؤها: دليل حيث ينتمي ملف، ملف حيث ينتمي دليل، أو ملف أو مجلد بدون صلاحية كتابة. بالنسبة لتلك الأداة، يتوقف `changes` حيث يتوقف التحديث الفعلي؛ الأدوات الأخرى لا تزال مخططة. الأعطال التي يقررها القرص فقط أثناء الكتابة، مثل نفاد المساحة، لا يمكن التنبؤ بها.

عطيل قبل التخطيط، مثل عدم وجود دليل OpenSpec، لا يزال يطبع وثيقة JSON واحدة بالضبط: الخطة الفارغة بالإضافة إلى مصفوفة status تحتوي severity و code (update_error) و message. رمز الخروج هو 1.

المخرجات

عندما تتطابق ملفات كل أداة مع إصدار واجهة سطر الأوامر:

✓ All 1 tool(s) up to date (v1.7.0)
  Tools: claude

Use --force to refresh files anyway.

عندما تأتي ملفات أداة من إصدار أقدم من واجهة سطر الأوامر (أو مع --force، الذي يطبع Force updating 1 tool(s): claude بدلاً من ذلك):

Updating 1 tool(s): claude (1.6.0 → 1.7.0)

✔ Updated Claude Code

✓ Updated: Claude Code (v1.7.0)
Tools: Claude Code

Restart your IDE for changes to take effect.

في دليل بدون OpenSpec، يرفض update:

✖ Error: No OpenSpec directory found. Run 'openspec init' first.

رموز الخروج

0: تم تحديث الملفات، أو كل شيء محدث بالفعل.
1: لا يوجد دليل OpenSpec في المسار، أو فشل التحديث.

openspec config

عرض وتغيير الإعداد العام.

bash

openspec config list                  # see current settings
openspec config set delivery skills   # change one value
openspec config profile               # interactive workflow picker

الأمر الفرعي	ما يفعله
`path`	طباعة موقع ملف الإعداد.
`list`	عرض جميع الإعدادات الحالية.
`get <key>`	طباعة قيمة واحدة، خام وقابلة للسكربت.
`set <key> <value>`	تعيين قيمة، مع تحويل نوعها.
`unset <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 فقط يعمل حالياً. أي نطاق آخر يخرج بالرمز 1 مع 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          # readable settings plus profile summary
openspec config list --json   # raw config as JSON

الخيارات

الخيار	التأثير
`--json`	طباعة كائن الإعداد كـ JSON.

المخرجات

كل إعداد، ثم ملخص ملف التعريف الذي يميز القيم كصريحة أو افتراضية:

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`	المفتاح المراد قراءته. النقاط تصل للقيم المتداخلة (`featureFlags.workspaces`).

المخرجات

القيمة المجردة، جاهزة للسكربتات. الكائنات تُطبع كـ JSON مضغوط:

both

رموز الخروج

0: تمت طباعة القيمة.
1: المفتاح ليس له قيمة، ولا يُطبع شيء.

openspec config set

bash

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

المعاملات

المعامل	ما هو
`key`	المفتاح المراد كتابته، بنقاط للقيم المتداخلة.
`value`	القيمة الجديدة. `true`/`false` تصبح قيم منطقية، والسلاسل الرقمية تصبح أرقاماً.

الخيارات

الخيار	التأثير
`--string`	تخزين القيمة كسلسلة نصية، مع تخطي تحويل النوع.
`--allow-unknown`	السماح بالمفاتيح غير المعروفة في المخطط.

المخرجات

Set featureFlags.workspaces = true

المفاتيح غير المعروفة والقيم غير الصالحة تفشل بالرمز 1 قبل حفظ أي شيء:

Error: Invalid configuration key "bogus.key". Unknown top-level key "bogus".
Use "openspec config list" to see available keys.
Pass --allow-unknown to bypass this check.

Error: Invalid configuration - delivery: Invalid option: expected one of "both"|"skills"|"commands"

إذا كان ملف الإعداد موجوداً لكنه لا يحتوي كائن JSON، سواء لأنه ليس JSON صالحاً على الإطلاق أو لأن جذره شيء آخر مثل null أو مصفوفة، تخرج config set و config unset و config profile بالرمز 1 وتترك الملف دون تغيير. أصلحه بـ openspec config edit، أو استبدله بـ openspec config reset --all:

Error: /home/you/.config/openspec/config.json could not be parsed, so it was left unchanged.
Fix it with "openspec config edit", or reset it with "openspec config reset --all".

حتى يتم إصلاحه، تبقى القياسات والتحقق من التحديث معطلة.

openspec config unset

bash

openspec config unset delivery

يزيل المفتاح ليُطبق الافتراضي مجدداً. المفاتيح ذات الافتراضيات المدمجة تُحسب دائماً كمعينة، لذا يُبلغ بالنجاح حتى لو لم تضبطها قط:

Unset delivery (reverted to default)

المفتاح الذي ليس له قيمة على الإطلاق يطبع Key "featureFlags.nothere" was not set. كلا الحالتين تخرجان بالرمز 0. ملف الإعداد الذي لا يمكن تحليله يخرج بالرمز 1 بدلاً من ذلك، كما هو الحال في config set.

openspec config reset

bash

openspec config reset --all      # asks for confirmation
openspec config reset --all -y   # no prompt

الخيارات

الخيار	التأثير
`--all`	مطلوب. إعادة تعيين كل شيء.
`-y, --yes`	تخطي مطالبة التأكيد.

المخرجات

Configuration reset to defaults

بدون --all يخرج بالرمز 1 ويطبع سطر الاستخدام.

رموز الخروج

0: تمت إعادة التعيين، أو أجبت بلا عند المطالبة.
1: --all مفقود.
130: تم إلغاء المطالبة بـ Ctrl-C.

openspec config edit

bash

openspec config edit

يفتح ملف الإعداد في $EDITOR (مع الرجوع إلى $VISUAL)، وينشئه بالافتراضيات أولاً إذا كان مفقوداً. عند إغلاق المحرر، يتم التحقق من الملف. JSON غير صالح أو إعداد غير صالح يخرجان بالرمز 1.

قيمة المحرر قد تحمل معاملات ومسارات مقتبسة، مثلاً code --wait أو "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" -w. تُقسم إلى كلمات بدون shell، لذا يتم تمرير $VAR و ~ و ; حرفياً. المحرر الذي لا يمكن بدؤه، أو الذي يخرج برمز غير صفري، يطبع خطأً من سطر واحد ويخرج بالرمز 1.

بدون محرر مُهيأ يخرج بالرمز 1:

Error: No editor configured
Set the EDITOR or VISUAL environment variable to your preferred editor
Example: export EDITOR=vim

openspec config profile

bash

openspec config profile        # interactive picker (needs a terminal)
openspec config profile core   # apply the core preset directly

المعاملات

المعامل	ما هو
`preset`	اسم الإعداد المسبق الاختياري. `core` فقط موجود. يختار سير العمل الأساسي ويحتفظ بإعداد التسليم الخاص بك.

بدون إعداد مسبق، يعرض منتقي تفاعلي وضع التسليم وسير العمل الحاليين، يتيح لك تغيير أحدهما أو كليهما (التسليم: كلاهما، أو المهارات فقط، أو الأوامر فقط؛ سير العمل: قائمة اختيار)، يطبع الفرق، وداخل مشروع OpenSpec يعرض تشغيل openspec update لك. خارج الطرفية يخرج بالرمز 1:

Interactive mode required. Use `openspec config profile core` or set config via environment/flags.

المخرجات

الإعداد المُغير لا يصل للمشاريع حتى تحدثه:

Config updated. Run `openspec update` in your projects to apply.

رموز الخروج

0: تم حفظ ملف التعريف، أو احتفظت بالإعدادات الحالية.
1: إعداد مسبق غير معروف، لا طرفية، أو فشل 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 عدد المهام وحالة status بقيم no-tasks أو in-progress أو complete:

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

يطبع تغييراً أو مواصفة، بصيغة markdown أو 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 منظَّم بدلاً من markdown الخام.
`--type <change\|spec>`	تحديد النوع عندما يتشارك تغيير ومواصفة نفس الاسم.
`--no-interactive`	عدم المطالبة أبداً: الاسم المفقود يصبح خطأ.
`--deltas-only`	JSON، تغيير: تقييد المخرجات بالتغييرات (deltas). JSON التغيير مقيد بالتغييرات بالفعل، لذا تتطابق المخرجات مع `--json` العادي.
`--requirements-only`	اسم مستعار مُهمَل لـ `--deltas-only`. يُصدر تحذيراً على stderr.
`--diff`	تغيير: إلحاق فروق التغييرات (diffs) لكل متطلب. يُتجاهل مع تحذير للمواصفات.
`--requirements`	JSON، مواصفة: الإبقاء على نص المتطلبات وتفريغ مصفوفات `scenarios`.
`--no-scenarios`	JSON، مواصفة: نفس مخرجات `--requirements`.
`-r, --requirement <id>`	JSON، مواصفة: إخراج متطلب واحد حسب الترتيب المعتمد على 1. لا يمكن دمجه مع `--requirements`.
`--store <id>`	استخدام مخزن مُسجَّل كجذر OpenSpec بدلاً من المشروع الحالي.

الخيارات التي لا تنطبق على النوع المُحلَّل تُتجاهل مع تحذير على stderr.

المخرجات

وضع النص هو تمرير خام: التغيير يطبع proposal.md الخاص به، والمواصفة تطبع spec.md الخاص بها.

# Add rate limiting

Why

يمكن للعملاء غير الموثقين استنزاف واجهة برمجة التطبيقات.

What Changes

Add per-client rate limiting to the public API.


في حالة التغيير، يطبع `--diff` الاقتراح أولاً، ثم قسم `Specifications Changed (diffs)`. تتضمن المتطلبات المضافة (ADDED) نصها الكامل. تحتفظ المتطلبات المحذوفة (REMOVED) بالسبب المكتوب (Reason) والترحيل (Migration). تعرض المتطلبات المُعاد تسميتها (RENAMED) من (FROM) وإلى (TO). تعرض المتطلبات المُعدّلة (MODIFIED) diff موحد مقابل المتطلب الرئيسي المطابق.

إذا تطابق عنوان MODIFIED فقط بعد طي حالة الأحرف أو المسافات البيضاء، يتضمن الإخراج كلاً من الـ diff وتحذيراً بأن المطابقة في الأرشيف دقيقة. إذا كان spec الرئيسي أو المتطلب مفقوداً، يحذر الإخراج ويطبع كتلة الـ delta الكاملة. كتلة MODIFIED بدون فرق نصي تطبع `(no textual changes)`.

التغيير مع `--json` يأخذ شكل 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"
  }
}

يحمل كل متطلب name الخاص به، وهو نص العنوان بعد Requirement:. هذا هو الاسم الذي يطابق به الأرشيف إدخالات MODIFIED وREMOVED وRENAMED. يحمل كل سيناريو name الخاص به، وهو نص العنوان بعد Scenario:. مجموعة علامات # الختامية على أي من العنوانين ليست جزءاً من الاسم.

يحتفظ --json --diff بشكله العام. يكتسب delta من نوع MODIFIED إما سلسلة diff أو سلسلة warning أو كليهما. العمليات الأخرى لا تتغير. سلسلة diff فارغة تعني أن كتلتي spec الرئيسي وdelta متطابقتان نصياً.

spec مع --json يسرد متطلباته مع السيناريوهات. تحمل المتطلبات والسيناريوهات نفس حقول name كما في 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?. الاسم الذي يطابق تغييراً وspec معاً يُحدث خطأ ويطلب --type.

رموز الخروج

0: تمت طباعة العنصر.
1: اسم غير معروف أو غامض، لا يوجد اسم خارج وحدة طرفية، فهرس -r خارج النطاق، --requirements مجتمعة مع -r، أو تعذر قراءة delta أو spec رئيسي لـ --diff.

openspec view

يطبع لوحة تحكم بملء الشاشة للـ specs والتغييرات.

bash

openspec view   # ملخص المشروع في شاشة واحدة

view يطبع لوحة التحكم مرة واحدة ثم يخرج. لا يقرأ أي ضغطات مفاتيح. تتجمّع التغييرات حسب تقدم المهام: مسودة (لا مهام بعد)، نشطة (مهام قيد التنفيذ، مع شريط تقدم ونسبة مئوية)، مكتملة (كل المهام محددة). تُسرد الـ specs مع أعداد المتطلبات، الأكبر أولاً.

الخيارات

Flag	Effect
`--store <id>`	Use a registered store as the OpenSpec root instead of the current project.

الإخراج

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

يظهر سطر ملخص Task Progress عندما يكون لدى أي تغيير مهام قيد التنفيذ.

يعرض كل تغيير نشط أيضاً حالات المخطط (schema) والنتائج (artifact) أسفل شريط تقدم المهام:

text

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

Marker	Artifact state
`✓`	Its output exists. An existing tasks artifact is done even when its checklist is unfinished.
`→`	It is ready to create.
No marker	It is blocked by a missing dependency.
`(skipped)`	The change skips it.

إذا تعذر تحميل سير العمل، يطبع view تحذيراً ويُبقي تقدم مهام ذلك التغيير مرئياً. شغّل openspec status --change <name> لفحص سير العمل بشكل منفصل. بعد openspec view --store <id>، مرّر نفس --store <id> إلى status.

رموز الخروج

0: تمت طباعة لوحة التحكم.
1: لم يتم العثور على جذر OpenSpec (خارج المشروع، لا يوجد --store).

openspec validate

يتحقق من التغييرات والـ specs بحثاً عن مشاكل هيكلية.

bash

openspec validate add-rate-limit   # تغيير أو spec واحد، بالاسم
openspec validate --all            # كل تغيير وspec

بدون اسم وبدون علامة شاملة، يطلب validate منك اختيار عناصر. خارج وحدة طرفية تفاعلية يخرج برمز 1 ويطبع علامات التحقق الشامل بدلاً من ذلك.

الوسائط

Argument	What it is
`item-name`	The change or spec to validate, by folder name (`add-rate-limit`, `api`).

الخيارات

Flag	Effect
`--all`	Validate every change and spec.
`--changes`	Validate every change.
`--specs`	Validate every spec.
`--archived`	Check task completion in archived changes, without validating their applied spec deltas.
`--strict`	Treat warnings as failures.
`--type <change\|spec>`	Pick the type when a change and a spec share a name.
`--json`	Print a structured report instead of text.
`--report <mode>`	Bulk output: `full` (default) or `findings`. Requires an explicit bulk scope.
`--concurrency <n>`	Max parallel validations in bulk runs. Default: `OPENSPEC_CONCURRENCY`, else 6.
`--no-interactive`	Never prompt: a missing or ambiguous name becomes an error.
`--store <id>`	Use a registered store as the OpenSpec root instead of the current project.

الإخراج

تُطبع في عمليات التحقق الشامل سطر حالة واحد لكل عنصر، يليه أي نتائج، وتنتهي بالإجماليات:

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

نتائج خانات المهام

تتحقق أعداد التقدم من خانات الاختيار فقط ولا شيء آخر، لذا فإن ملف مهام مكتوب كنقاط عادية يُقرأ كصفر مهام: يُقرّ openspec list وopenspec status بعدم وجود عمل، وليس لدى openspec archive ما يشير إليه كغير مكتمل. يُقرّ validate بتحذير 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".

يُطلق التحذير فقط عندما لا تحتوي المجموعة المتتبَعة بأكملها للتغيير على أي خانة اختيار على الإطلاق. ملف نثري واحد بجانب قائمة تحقق حقيقية لا يتم الإبلاغ عنه، والتغيير قيد التأليف يحتفظ بتقدمه حالما توجد خانة اختيار واحدة. --strict يحوّل التحذير إلى فشل. رقم السطر موجود في تقرير --json.

الكتل المُسيّجة (Fenced blocks)، وتعليقات HTML، وYAML front matter، والكود المُزاح لا يتم فحصها، لذا لا يُساء أبداً فهم عيّنة طرفية مُلصقة كقائمة مهام.

نتائج دمج الأرشيف

بالنسبة للتغييرات، يُشغّل validate باني الدمج الخاص بالأرشيف مقابل الـ specs الرئيسية الحالية بدون كتابة ملفات. يُقرّ عن تعارضات الدمج، مثل هدف MODIFIED مفقود أو متطلب ADDED متضارب، كـ INFO:

text

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

تظهر هذه النتائج حتى عندما ينجح التحقق، في كلا الإخراجين النصي وJSON. INFO لا يغيّر أبداً رمز الخروج، بما في ذلك تحت --strict: قد ينتمي الهدف المفقود إلى تغيير شقيق لم يُؤرشف بعد. تتبع الـ deltas المُزامَنة بالفعل في الـ specs الرئيسية قواعد الدمج الحالية للأرشيف.

هذا التحقق لا يُشغّل التحقق اللاحق للـ merged-spec أو فحوصات التقاعد الخاصة بالأرشيف. التقرير النظيف لا يضمن نجاح الأرشيف.

إذا تعذّر بدء الفحص المسبق للدمج، تُفسّر نتيجة INFO السبب. تبقى نتائج التحقق الحالية ورمز الخروج دون تغيير.

العنصر الفاشل يسرد كل مشكلة والحل:

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 مستوى level من ERROR أو WARNING أو INFO.

رموز الخروج

0: كل عنصر تم التحقق منه نجح، بما في ذلك نطاق شامل فارغ.
1: فشل عنصر، أو طلب تقرير غير صالح، أو تعذر قراءة openspec/config.yaml أو أنه ليس YAML صالحاً، أو فشل التشغيل (على سبيل المثال اسم غير معروف أو لا يوجد جذر OpenSpec). الإعدادات التي لا يمكن قراءتها أو تحليلها توقف التشغيل قبل فحص أي عنصر؛ مع --json يتم الإبلاغ عنها كإدخال status واحد برمز unreadable_config أو unparseable_config.

--report full|findings

يحدد إخراج نطاق تحقق شامل صريح:

full: كل عنصر. هذا هو الافتراضي. --report full الصريح يحتفظ بشكل الإخراج الحالي دون إضافة بيانات وصفية للتقرير.
findings: العناصر ذات المشكلات فقط، بما في ذلك العناصر الناجحة مع تحذيرات أو معلومات. لا يزال يتم التحقق من كل عنصر. الإجماليات وسلوك الوضع الصارم ورموز الخروج لا تتغير.

bash

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

النطاقات

Flags	Findings `report.scope`
`--all`	`all`
`--changes`	`changes`
`--specs`	`specs`
`--changes --specs`, or `--all` with either flag	`all`
`--archived`	`archived`

كلا وضعي التقرير الصريحين يرفضان اسم عنصر موضعي، أو نطاقاً شاملاً مفقوداً، أو نطاق أرشيف مُدمجاً مع نطاق نشط.

إخراج النتائج النصي

الإخراج البشري: يطبع stdout Scope: <scope> (<count> items)، ثم الإجماليات. بدون عناصر ذات مشكلات:

text

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

تُطبع تسميات العناصر ذات المشكلات، وتسميات الخطورة، والمسارات، والرسائل إلى stderr. تفشل نطاقات النشاط في الاحتفاظ بتلميح إعادة التشغيل Details: بعد الإجماليات. قد يسبق التقرير شريط الجذر وإخراج التقدم الحاليان.

إخراج النتائج 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: يعدّان السجلات المُرجَعة وجميع العناصر المُتحقَّق منها على التوالي.
itemFindings: سجلات العناصر الكاملة التي تحتوي مصفوفة issues فيها على قيم غير فارغة. تتضمن مشكلات ERROR وWARNING وINFO. يحتفظ كل سجل بـ id وtype وvalid وissues وdurationMs. العناصر المؤرشفة تستخدم type: "change".
summary: إجماليات التشغيل الكامل والأعداد لكل نوع، وليست أعداد المجموعة المُرجَعة الفرعية. النطاق الفارغ له إجماليات صفرية ويخرج برمز 0.
root: نفس بيانات الجذر المُختار الوصفية كما في التقرير الكامل.

حفظ السجلات: تحتفظ العناصر المُرجَعة بترتيبها في التقرير الكامل وأي حقول إضافية على العناصر أو المشكلات. التصفية لا تعيد كتابة الرسائل أو المواقع، بما في ذلك حقول line وcolumn الاختيارية.

فشل الأوامر: تحتفظ أعطال اختيار الجذر أو اكتشاف العناصر بتشخيص status الحالي وتخرج برمز 1. لا تُرجع تقرير نتائج مكتمل أو تقريراً فارغاً ناجحاً.

طلبات التقارير غير الصالحة

كلا وضعي التقرير الصريحين يرفضان هذه الطلبات قبل اختيار الجذر أو اكتشاف العناصر:

قيمة تقرير غير مدعومة، بما في ذلك سلسلة فارغة.
اسم عنصر موضعي، حتى مع علامة شاملة.
لا يوجد نطاق شامل صريح.
--archived مُدمجاً مع --all أو --changes أو --specs.

في وضع JSON، الطلب المرفوض يخرج برمز 1 مع مصفوفة status أحادية العنصر فقط. لا يحتوي على root أو حمولة تقرير:

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."
    }
  ]
}

الوضع البشري يطبع الخطأ إلى stderr. --report مجرد بدون قيمة هو خطأ في بناء Commander على stderr، بما في ذلك مع --json؛ لا يستخدم مُغلّف التشخيص هذا.

تصفية تقرير كامل خارجياً

لعرض JSON مخصص، صفِّ التقرير الكامل باستخدام jq أو PowerShell. تحافظ أمثلة السكربتات هذه على رمز خروج التحقق وترك مستندات أخطاء الأوامر كما هي.

في Bash مع jq:

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

تحتفظ هذه العروض المخصصة بمفاتيح التقرير الكامل لكنها تحذف العناصر النظيفة. إنها ليست تقارير full-v1 كاملة ولا شكل --report findings المُصدّر.

openspec archive

ينقل التغيير المكتمل إلى الأرشيف ويحدّث المواصفات الرئيسية.

bash

openspec archive add-rate-limit -y                # archive one change, merge its deltas
openspec archive add-rate-limit -y --skip-specs   # archive without touching the specs

بدون اسم، يطالبك الأرشيف باختيار تغيير. خارج الطرفية التفاعلية، يخرج بالرمز 1 ويطبع أمر إعادة التشغيل بدلاً من ذلك.

الوسائط

الوسيط	ما هو
`change-name`	التغيير المراد أرشفته، باسم المجلد (`add-rate-limit`).

الخيارات

العلم	التأثير
`-y, --yes`	الإجابة بنعم على كل تأكيد: تحديثات المواصفات، المهام غير المكتملة، التخطي من التحقق.
`--skip-specs`	الأرشفة دون المساس بالمواصفات الرئيسية (البنية التحتية، أو الأدوات، أو التغييرات المخصصة للتوثيق فقط).
`--no-validate`	تخطي التحقق. يسألك الأرشيف للتأكيد أولاً، و `-y` يجيب عليه.
`--json`	طباعة نتيجة منظمة بدلاً من النص. يتطلب `--yes` لتأكيد تحديثات المواصفات.
`--store <id>`	استخدام مخزن مسجّل كجذر لـ OpenSpec بدلاً من المشروع الحالي.

المخرجات

يُبلغ التشغيل الناجح عن حالة المهام، ويعاين تحديثات المواصفات، ويطبقها، ويسمّي مجلد الأرشيف:

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'.

ينتقل مجلد التغيير بالكامل إلى openspec/changes/archive/2026-08-11-add-rate-limit/، مع إضافة تاريخ اليوم كبادئة لاسمه. تندمج كل دلتا في مواصفتها الرئيسية: المتطلب المُضاف أعلاه أُلحق بـ openspec/specs/api/spec.md. بدون -y، يعرض الأرشيف المعاينة ويسأل قبل التحديث. الرفض لا يزال يؤرشف التغيير ويترك المواصفات كما هي.

مع --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"
  }
}

يتحقق الأرشيف من التغيير أولاً ويرفض التغيير الفاشل:

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.

المهام غير المكتملة تُنذر ولكنها لا تمنع. تفاعلياً، يسأل الأرشيف عما إذا كان ينبغي الاستمرار، و-y يستمر تلقائياً:

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

رموز الخروج

0: تمت أرشفة التغيير، مع أو بدون تحديثات المواصفات.
1: فشل التحقق، أو اسم التغيير غير معروف، أو كان هناك حاجة لتأكيد ولم يمكن قراءة إجابة.

openspec new

ينشئ مجلد تغيير جديد.

bash

openspec new change add-caching                                # metadata only
openspec new change add-search --goal "Users can search docs"  # record a goal

يحتوي new على أمر فرعي واحد، وهو new change <name>. ينشئ openspec/changes/<name>/ الذي يحتوي على ملف بيانات وصفية .openspec.yaml واحد:

yaml

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

لا يتم إنشاء المخرجات (الاقتراح، المواصفات، التصميم، المهام) هنا. تكتبها لاحقاً، ويخبرك openspec status بأيّها التالي.

الوسائط

الوسيط	ما هو
`name`	اسم المجلد للتغيير (`add-caching`).

الخيارات

العلم	التأثير
`--description <text>`	ينشئ أيضاً ملف `README.md` في مجلد التغيير بهذا النص.
`--goal <text>`	يخزّن سطر `goal:` في `.openspec.yaml`.
`--schema <name>`	مخطط سير العمل للتغيير. الافتراضي: `spec-driven`، وهو المخطط الوحيد المتوفر.
`--json`	طباعة التغيير المنشأ بصيغة JSON بدلاً من النص.
`--store <id>`	استخدام مخزن مسجّل كجذر لـ OpenSpec بدلاً من المشروع الحالي.

المخرجات

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: تم إنشاء التغيير.
1: التغيير موجود بالفعل، أو المخطط غير معروف.

openspec status

يُقر بحالة اكتمال المخرجات لتغيير واحد أو لكل التغييرات النشطة.

bash

openspec status --change add-rate-limit          # checklist view
openspec status --change add-rate-limit --json   # structured report
openspec status --all                            # every active change
openspec status --all --json                     # one batch report

عند وجود تغييرات نشطة، استخدم واحدًا فقط من --change أو --all. بدون أي منهما، يخرج status بالرمز 1 ويسرد التغييرات المتاحة، حتى عندما يكون هناك تغيير واحد فقط:

text

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

عندما لا يكون هناك تغييرات نشطة في المشروع، يطبع status الرسالة 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> كلما كان الجذر المحلول مخزنًا، ويذكر نفس الأمر الذي في جملة nextSteps في JSON.

يضيف --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   # how to write one artifact
openspec instructions apply --change add-rate-limit      # how to implement the change
openspec instructions archive --change add-rate-limit    # inputs for archiving

الوسائط

الوسيطة	الوصف
`artifact`	معرف مخرج من المخطط (`proposal`, `specs`, `design`, `tasks` في `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 اسم التغيير بالإضافة إلى أي سياق مشروع وإرشادات تشغيل من الإعدادات. عندما لا يكون شيء مُعدًا يذكر ذلك ولا شيء أكثر.

مع --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 هو رقم السطر المعتمد على 1 لخانة اختيار المهمة في ذلك الملف.

taskTrackingConfigured هو دائمًا قيمة منطقية: true عندما يحدد المخطط قيمة غير صفرية لـ apply.tracks، حتى لو لم يطابق أي ملف، وfalse بخلاف ذلك. إذا تعذرت قراءة ملف تتبع مطابق، يحتوي unavailableTrackingFiles على path المطلق وreason الخطأ. يُحذف هذا الحقل عندما تكون كل الملفات المطابقة قابلة للقراءة. تساهم الملفات القابلة للقراءة في tasks وprogress، لكن state لا يمكن أن تكون all_done حتى تُقرأ كل الملفات المطابقة.

رموز الخروج

0: تمت طباعة التعليمات.
1: مخرج غير معروف، أو تغيير غير معروف، أو مخطط غير معروف، أو --change مفقود. يذكر كل خطأ القيم الصالحة.

قوالب openspec

يطبع مسارات القوالب المُحلَّلة للمُخرَجات الخاصة بمخطط العمل.

bash

openspec templates          # المخطط الافتراضي: spec-driven
openspec templates --json   # خريطة مُعرِّفات المُخرَجات إلى المسارات

الخيارات

الخيار	الأثر
`--schema <name>`	المخطط المراد تحليله. الافتراضي: `spec-driven`.
`--json`	طباعة خريطة 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 (مدمج في واجهة سطر الأوامر). أولوية المشروع على المستخدم، وأولوية المستخدم على الحزمة.

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

يسرد مخططات سير العمل المتاحة.

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

يفحص، أو ينسخ، أو ينشئ مخططًا (تجريبي). كل أمر فرعي يطبع أولاً Note: Schema commands are experimental and may change. على stderr.

bash

openspec schema which spec-driven          # where a schema resolves from
openspec schema fork spec-driven my-flow   # copy a schema into the project
openspec schema init my-schema             # create a schema from scratch

الأمر الفرعي	وظيفته
`which`	عرض المصدر الذي يُحلّ منه المخطط.
`validate`	التحقق من بنية المخطط والقوالب الخاصة به.
`fork`	نسخ مخطط موجود إلى المشروع لتخصيصه.
`init`	إنشاء مخطط محلي جديد للمشروع.

تُحلّ المخططات من ثلاثة مواقع. أول مطابقة تفوز:

المصدر	الموقع
`project`	`openspec/schemas/` في المشروع الحالي.
`user`	`~/.local/share/openspec/schemas/` (يتم احترام `XDG_DATA_HOME` وWindows `%LOCALAPPDATA%`).
`package`	المخططات المرفقة مع واجهة سطر الأوامر. `spec-driven` موجود هنا.

openspec schema which

يعرض أي نسخة من المخطط ستستخدمها واجهة سطر الأوامر.

bash

openspec schema which spec-driven
openspec schema which --all        # every schema, grouped by source

المعاملات

المعامل	ماهيته
`name`	المخطط المطلوب البحث عنه. مطلوب ما لم يتم تعيين `--all`. بدون أي منهما، يخرج الأمر بترميز 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   # one schema, from any source
openspec schema validate               # every project-local schema

يتحقق من وجود 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/، ويُعاد كتابة حقل name: في schema.yaml الخاص بها إلى الاسم الجديد:

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`. الافتراضي: الكل.
`--default`	يكتب `schema: <name>` في `openspec/config.yaml` أو `openspec/config.yml` الموجود. ينشئ `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   # create and register
openspec store register ~/stores/design-system                     # register an existing checkout
openspec store list                                                # see what's registered

تعيش التسجيلات في سجل خاص بالجهاز: ~/.local/share/openspec/stores/registry.yaml، أو $XDG_DATA_HOME/openspec/stores/registry.yaml عند تعيين XDG_DATA_HOME. كل أمر فرعي يأخذ --json لطباعة تقرير منظم بدلاً من نص. تشغيل openspec store مع أمر فرعي مفقود أو غير معروف يخرج بترميز 1 ويسرد الأوامر الفرعية.

الأمر الفرعي	وظيفته
`setup [id]`	إنشاء مجلد مخزن وتسجيله.
`register [path]`	تسجيل مجلد مخزن موجود.
`unregister <id>`	نسيان التسجيل. المجلد يبقى على القرص.
`remove <id>`	نسيان التسجيل وحذف المجلد.
`list` (اسم مستعار `ls`)	سرد المخازن المسجلة.
`doctor [id]`	فحص التسجيل والبيانات الوصفية وحالة Git للمخازن المسجلة.

openspec store setup

ينشئ مجلد مخزن ويسجله.

bash

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

في طرفية تفاعلية، يطالب setup باسم وموقع مفقودين ويؤكد قبل إنشاء أي شيء. خارجها، يخرج الأمر بترميز 1 مع الاسم أو --path المفقود ويعرض العلامة المطلوبة. إعادة تشغيل setup لمخزن مسجل تُقرّر Registry: already registered.

يخرج setup بترميز 1 مع store_setup_inside_git_repo عندما يكون --path داخل مستودع Git آخر، لأن تهيئة المخزن هناك سيتداخل مع مستودع آخر. --no-init-git لا ينشئ أي مستودع، لذا يتخطى ذلك الفحص. استخدمه لإبقاء مخزن في ~/openspec/<id> عندما يكون مجلد المنزل نفسه مستودع Git، مثل مستودع dotfiles.

المعاملات

المعامل	ماهيته
`id`	اسم المخزن. يصبح المعرف الذي تمرره إلى `--store`.

الخيارات

العلامة	الأثر
`--path <path>`	المجلد الذي يجب أن يعيش فيه المخزن (`~` يتم توسيعه).
`--init-git`	تهيئة مستودع Git مع commit أولي. الافتراضي.
`--no-init-git`	تخطي كل إجراءات Git: لا تهيئة ولا commit أولي.
`--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 استخدام المعرف المسجل. بدونه، يسأل register قبل إنشاء تلك البيانات الوصفية. خارج الطرفية التفاعلية، مرّر --yes بدلاً من ذلك. يمكن للجهاز تسجيل استنساخ واحد لكل معرف مخزن. مسار ثانٍ تحت نفس المعرف، أو نفس المسار تحت معرف ثانٍ، يخرج بترميز 1.

المعاملات

المعامل	ماهيته
`path`	مجلد المخزن المراد تسجيله (`~` يتم توسيعه). مطلوب.

الخيارات

العلامة	الأثر
`--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

يخرج remove بترميز 1 ولا يحذف شيئًا عندما يفتقر المجلد إلى بيانات تعريف المخزن المطابقة، أو عندما يحتوي على مخزن مسجل آخر (مثل مخزن مُضمّن كـ Git submodule). في تلك الحالة الخطأ هو 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                # every registered store
openspec store doctor team-context  # one store

المخرجات

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: تعذّر تشغيل التقرير (على سبيل المثال معرف مخزن غير معروف).

openspec doctor

يُقرّر صحة العلاقات لجذر OpenSpec المُحلَّل.

bash

openspec doctor                       # أقرب جذر openspec/ أعلى مسار العمل الحالي
openspec doctor --store team-context  # مخزن مسجل يُستخدم كجذر

Doctor للقراءة فقط: لا يقوم بالاستنساخ أو المزامنة أو الإصلاح أبدًا. يُقرّر ما إذا كان الجذر سليمًا وما إذا كانت كل مرجع مُصرَّح به في openspec/config.yaml يُحلّ على هذه الآلة. عند عدم وجود جذر أعلى مسار العمل الحالي وعدم وجود --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: لم يُحلّ أي جذر (لا يوجد openspec/ أعلى مسار العمل الحالي ولا --store)، أو معرّف --store غير معروف.

openspec context

يطبع سياق العمل لجذر OpenSpec المُحلَّل: الجذر بالإضافة إلى كل مخزن مُشار إليه ومُصرَّح به في openspec/config.yaml، كل منهم مع أمر جلب.

bash

openspec context                       # أقرب جذر openspec/ أعلى مسار العمل الحالي
openspec context --store team-context  # مخزن مسجل يُستخدم كجذر
openspec context --json                # موجز الوكيل

المراجع التي لا تُحلّ على هذه الآلة تُدرج في قسم 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: لم يُحلّ أي جذر (لا يوجد openspec/ أعلى مسار العمل الحالي ولا --store)، أو تم رفض كتابة --code-workspace.

openspec workset

يُنشئ ويحفظ ويفتح طرق عمل شخصية. 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`	عرض worksets المحفوظة مع أعضائها.
`open <name>`	فتح workset محفوظ في أداتك (نافذة محرر أو جلسة وكيل).
`remove <name>`	حذف workset محفوظ (مجلدات الأعضاء لا تُمس أبداً).

workset محلي بالكامل:

حالته تعيش في مجلد واحد: ~/.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 كل ما لم توفره الأعلام: الاسم، والمجلدات واحداً تلو الآخر، والأداة، ثم يعرض فتح workset الآن. خارجها، يُعدّ الاسم أو العضو المفقود خطأً. الاسم المحفوظ مسبقاً هو دائماً خطأ. احذفه أولاً.

المعاملات

المعامل	وصفه
`name`	اسم workset. بصيغة kebab-case: أحرف صغيرة وأرقام وواصلات مفردة. مطلوب خارج الطرفية التفاعلية.

الخيارات

العلم	التأثير
`--member <member>`	مجلد عضو بصيغة `<path>` أو `<name>=<path>`، قابل للتكرار. الأول هو الأساسي. يجب أن يكون المسار مجلداً موجوداً، ويُشتق الاسم الوصفي من اسم المجلد نفسه افتراضياً.
`--tool <id>`	الأداة المفضلة لفتح workset بها. المعرفات المدمجة: `code` (VS Code)، `cursor` (Cursor). `claude` و`codex` معطّلان مؤقتاً.
`--json`	طباعة workset المحفوظ بصيغة JSON.

المخرجات

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

openspec workset list

يعرض worksets المحفوظة مع أعضائها، مرتبة حسب الاسم.

bash

openspec workset list   # alias: ls

الخيارات

العلم	التأثير
`--json`	طباعة worksets بصيغة JSON.

المخرجات

كتلة واحدة لكل workset: الاسم، والأداة إذا كانت محددة، ثم صف 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

يفتح workset محفوظاً في أداتك. أدوات المحرر (code, cursor) تحصل على ملف .code-workspace مُنشأ. تُفتح نافذة ويعود الأمر. أدوات وكيل CLI (claude, codex) كانت ستستولي على هذه الطرفية مع إرفاق كل الأعضاء. هي معطّلة مؤقتاً أثناء إعادة صياغة هذا التدفق، لذا تُفتح worksets في بيئة تطوير حالياً.

bash

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

المعاملات

المعامل	وصفه
`name`	workset المراد فتحه.

الخيارات

العلم	التأثير
`--tool <id>`	الفتح بهذه الأداة مرة واحدة فقط.

بدون --tool وبدون أداة محفوظة، يطلب open اختيار أداة مثبتة. خارج الطرفية التفاعلية يخرج بالرمز 1 بدلاً من ذلك.

مجلد العضو الذي لم يعد موجوداً يُتخطى مع تحذير. عندما يكون الأساسي مفقوداً، يصبح أقرب عضو باقٍ هو الأساسي لهذا الفتح. عندما لا يوجد أي مجلد عضو، يفشل الفتح.
--json مرفوض: open يسلّم الطرفية إلى الأداة وليس له وضع JSON.
عند فشل الإطلاق، ينتهي الخطأ بالمسار اليدوي: مسار ملف workspace وقائمة الأعضاء.

رموز الخروج

يطابق الأداة: يخرج الأمر برمز خروج الأداة نفسه، وتصبح الإشارة 128+n (130 بعد Ctrl-C).
1: workset غير معروف، لا يوجد مجلد عضو متاح، أو لا توجد أداة قابلة للاستخدام.

openspec workset remove

يحذف workset محفوظاً وملف .code-workspace المُنشأ الخاص به. مجلدات الأعضاء لا تُمس أبداً.

bash

openspec workset remove checkout --yes

في طرفية تفاعلية، يعرض remove workset ويطلب التأكيد. مع --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 أو temporary لمشغّل عابر مثل npx، أو source لفحص checkout، أو 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."

ترفع واجهة سطر الأوامر رسالتك كقضية على مستودع Fission-AI/OpenSpec عبر واجهة gh الخاصة بك. يصبح العنوان Feedback: <message>. يستخدم النص الرئيسي عناوين نموذج البلاغ: رسالتك تحت What happened، ونص --body تحت Details، وقسم Minimal steps to reproduce يطلب منك إضافة الخطوات، لأن واجهة سطر الأوامر لا تستطيع ملءها. يضيف تذييل إصدار واجهة سطر الأوامر والمنصة والطابع الزمني. تحصل القضية على وسم feedback. إذا لم يكن المستودع يحدد هذا الوسم، تعيد واجهة سطر الأوامر المحاولة بدونه وتوضح ذلك.

المعاملات

المعامل	ما هو
`message`	ملخص من سطر واحد. يصبح عنوان القضية. مطلوب.

الخيارات

العلم	التأثير
`--body <text>`	وصف أطول يُضاف إلى نص القضية.

المخرجات

عند النجاح:

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

بدون تثبيت gh، أو مع gh غير مسجّل الدخول، لا يتم إرسال أي شيء. تطبع واجهة سطر الأوامر ملاحظاتك المنسّقة بين علامات --- FORMATTED FEEDBACK ---، ثم رابطاً يفتح نموذج الإبلاغ مع العنوان وما حدث (رسالتك ونص --body) وإصدار واجهة سطر الأوامر والبيئة (المنصة وإصدار Node) معبّأة. تكمل بقية النموذج في المتصفح. يضيف مسار عدم تسجيل الدخول To auto-submit in the future: gh auth login.

رموز الخروج

0: تم إنشاء القضية، أو تم تشغيل البديل اليدوي للإرسال (لا يوجد gh، أو gh غير مسجّل الدخول).
1: لم يتم تقديم رسالة.
رمز gh الخاص: فشل gh بعد المصادقة (الشبكة، حد المعدل، القضايا معطّلة). تعيد واجهة سطر الأوامر طباعة ملاحظاتك ورابط الإرسال اليدوي أولاً.

openspec completion

يثبّت أو يولّد إكمال الصدفة.

bash

openspec completion install        # اكتشاف صدفتك، التثبيت، تهيئة الإعداد
openspec completion generate zsh   # طباعة السكربت إلى stdout

الأصداف المدعومة: zsh، bash، fish، powershell. يأخذ كل أمر فرعي معامل صدفة اختياري. إذا حذفته، تكتشف واجهة سطر الأوامر صدفتك من البيئة.

الأمر الفرعي	ما يفعله
`generate [shell]`	طباعة سكربت الإكمال إلى stdout.
`install [shell]`	كتابة السكربت وتهيئة ملف بدء تشغيل الصدفة.
`uninstall [shell]`	إزالة السكربت وكتلة الإعداد.

مع التثبيت عبر Nix، الإكمالات موجودة بالفعل: توفّر حزمة flake سكربتات Bash و Fish و Zsh في المواقع القياسية، لذا لا حاجة لـ install (التثبيت).

openspec completion generate

يطبع السكربت ولا يكتب شيئاً.

#compdef openspec

# سكربت إكمال Zsh لواجهة سطر أوامر OpenSpec
# مولّد تلقائياً - لا تحرره يدوياً

_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

يزيل السكربت وكتلة الإعداد الموسومة. يطلب الإذن قبل التعديل على إعداداتك (الافتراضي: لا).

بالنسبة لـ zsh، ينظّف .zshrc الذي يحرّره install، وأيضاً ~/.zshrc عندما يترك تثبيت قديم كتلة هناك تحت ZDOTDIR. إذا تعذّرت إزالة كتلة، يسمي uninstall الملف ويخرج بالرمز 1.

الخيارات

العلم	التأثير
`-y, --yes`	تخطّي مطالبات التأكيد.

المخرجات

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

رموز الخروج

0: تم توليد السكربت أو تثبيته أو إزالته. إلغاء إلغاء التثبيت يخرج أيضاً بالرمز 0.
1: الصدفة غير مدعومة أو لم يتم اكتشافها، أو فشلت خطوة تثبيت أو إلغاء تثبيت.

openspec change

صيغة الاسم المهملة من show و list و validate. كل تشغيل يحذّر ويشير إلى الأوامر ذات الفعل أولاً، ثم يعمل على أي حال:

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 init ​

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 ​

Why ​

What Changes ​

openspec view ​

openspec validate ​

--report full|findings ​

إخراج النتائج النصي ​

إخراج النتائج JSON ​

طلبات التقارير غير الصالحة ​

تصفية تقرير كامل خارجياً ​

openspec archive ​

openspec new ​

openspec status ​

openspec instructions ​

قوالب openspec ​

مخططات openspec ​

openspec schema ​

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 ​

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 init

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

Why

What Changes

openspec view

openspec validate

--report full|findings

إخراج النتائج النصي

إخراج النتائج JSON

طلبات التقارير غير الصالحة

تصفية تقرير كامل خارجياً

openspec archive

openspec new

openspec status

openspec instructions

قوالب openspec

مخططات openspec

openspec schema

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

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