مرجع سطر الأوامر

يوفر سطر أوامر OpenSpec (openspec) أوامر طرفية لإعداد المشروع والتحقق منه وفحص الحالة والإدارة. وتكمّل هذه الأوامر أوامر AI المائلة (مثل /opsx:propose) الموثّقة في الأوامر.

الملخص

الفئة	الأوامر	الغرض
الإعداد	`init`, `update`	تهيئة وتحديث OpenSpec في مشروعك
المخازن (مستودعات OpenSpec المستقلة)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	إدارة المخازن — مستودعات OpenSpec المستقلة التي قمت بتسجيلها
الصحة	`doctor`	تقرير صحة العلاقة للجذر المُحلّ
سياق العمل	`context`	تجميع مجموعة العمل (الجذر + المخازن المرجعية)
مجموعات العمل الشخصية	`workset create`, `workset list`, `workset open`, `workset remove`	الحفاظ على العروض المحلية الشخصية وفتحها في أداتك
التصفح	`list`, `view`, `show`	استكشاف التغييرات والمواصفات
التحقق	`validate`	فحص التغييرات والمواصفات بحثًا عن مشكلات
دورة الحياة	`archive`	إنهاء التغييرات المكتملة
سير العمل	`new change`, `status`, `instructions`, `templates`, `schemas`	دعم سير عمل قائم على المخرجات
المخططات	`schema init`, `schema fork`, `schema validate`, `schema which`	إنشاء وإدارة سير عمل مخصص
الإعدادات	`config`	عرض وتعديل الإعدادات
أدوات مساعدة	`feedback`, `completion`	التغذية الراجعة والتكامل مع shell

أوامر المستخدم البشري مقابل أوامر الوكلاء

صُممت معظم أوامر واجهة سطر الأوامر (CLI) للاستخدام البشري في الطرفية. تدعم بعض الأوامر أيضًا الاستخدام بواسطة الوكلاء/البرامج النصية عبر إخراج JSON.

أوامر مخصصة للبشر فقط

هذه الأوامر تفاعلية ومصممة للاستخدام في الطرفية:

الأمر	الغرض
`openspec init`	تهيئة المشروع (مطالبات تفاعلية)
`openspec view`	لوحة تحكم تفاعلية
`openspec workset open <name>`	فتح مجموعة عمل محفوظة (نافذة محرر أو جلسة وكيل طرفية)
`openspec config edit`	فتح الإعدادات في المحرر
`openspec feedback`	إرسال ملاحظات عبر GitHub
`openspec completion install`	تثبيت إكمال الأوامر للطرفية

أوامر متوافقة مع الوكلاء

تدعم هذه الأوامر إخراج --json للاستخدام البرمجي من قبل وكلاء الذكاء الاصطناعي والبرامج النصية:

الأمر	الاستخدام البشري	الاستخدام بواسطة الوكيل
`openspec list`	تصفح التغييرات/المواصفات	`--json` للبيانات المنظمة
`openspec show <item>`	قراءة المحتوى	`--json` للتحليل
`openspec validate`	التحقق من المشكلات	`--all --json` للتحقق الجماعي
`openspec status`	عرض تقدم الأصناف	`--json` للحالة المنظمة
`openspec instructions`	الحصول على الخطوات التالية	`--json` لتعليمات الوكيل
`openspec templates`	إيجاد مسارات القوالب	`--json` لتحديد المسار
`openspec schemas`	قائمة المخططات المتاحة	`--json` لاكتشاف المخطط؛ `--store <id>` لتحديد جذر مسجل
`openspec store setup <id>`	إنشاء وتسجيل مخزن محلي	`--json` مع مدخلات صريحة لإخراج إعداد منظم
`openspec store register <path>`	تسجيل مخزن موجود	`--json` لإخراج تسجيل منظم
`openspec store unregister <id>`	نسيان تسجيل مخزن محلي	`--json` لإخراج تنظيف منظم
`openspec store remove <id>`	حذف مجلد مخزن مسجل محليًا	`--yes --json` للحذف غير التفاعلي
`openspec store list`	تصفح المخازن المسجلة	`--json` للتسجيلات المنظمة
`openspec store doctor`	فحص إعداد المخزن المحلي	`--json` للتشخيص المنظم
`openspec new change <id>`	إنشاء بنية تغيير محلية للمستودع	`--json`، بالإضافة إلى `--store <id>` لاستخدام مخزن مسجل كجذر OpenSpec
`openspec workset create [name]`	تكوين عرض عمل شخصي	`--member <path> --json` للتكوين غير التفاعلي
`openspec workset list`	تصفح مجموعات العمل المحفوظة	`--json` للعروض المنظمة
`openspec workset remove <name>`	حذف عرض محفوظ	`--yes --json` للإزالة غير التفاعلية

الخيارات العامة

تعمل هذه الخيارات مع جميع الأوامر:

الخيار	الوصف
`--version`, `-V`	إظهار رقم الإصدار
`--no-color`	تعطيل إخراج الألوان
`--help`, `-h`	عرض المساعدة للأمر

أوامر الإعداد

`openspec init`

تهيئة OpenSpec في مشروعك. ينشئ بنية المجلدات ويضبط تكاملات أدوات الذكاء الاصطناعي.

السلوك الافتراضي يستخدم الإعدادات العامة الافتراضية: ملف التعريف core، التسليم both، سير العمل propose, explore, apply, update, sync, archive.

openspec init [path] [options]

استخدم --language <language> لإضافة تعليمة لغة إلى ملف openspec/config.yaml لمشروع جديد. بالنسبة لمشروع موجود، عدّل حقل context في الإعدادات لضمان عدم قيام OpenSpec باستبدال الإرشادات الخاصة بالمشروع.

الوسائط:

الوسيط	مطلوب	الوصف
`path`	لا	الدليل الهدف (الافتراضي: الدليل الحالي)

الخيارات:

الخيار	الوصف
`--tools <list>`	تكوين أدوات الذكاء الاصطناعي بشكل غير تفاعلي. استخدم `all` أو `none` أو قائمة مفصولة بفواصل
`--language <language>`	كتابة الأصناف بهذه اللغة عند إنشاء إعدادات جديدة
`--force`	التنظيف التلقائي للملفات القديمة دون طلب تأكيد
`--profile <profile>`	تجاوز ملف التعريف العام لهذه الجلسة من `openspec init` (`core` أو `custom`)
`--no-animation`	إظهار شاشة ترحيب ثابتة بدلاً من المتحركة
`--copilot-cloud`	إعداد ملفات وكيل ترميز السحابة من GitHub Copilot دون طلب تأكيد
`--no-copilot-cloud`	تخطي ملفات وكيل ترميز السحابة من GitHub Copilot دون طلب تأكيد

--profile custom يستخدم سير العمل المحدد حاليًا في الإعدادات العامة (openspec config profile).

يتم أيضًا تخطي الرسوم المتحركة الترحيبية عند تعيين متغير البيئة OPENSPEC_NO_ANIMATION (أي قيمة، بما في ذلك فارغة)، أو عند تعيين NO_COLOR إلى قيمة غير فارغة، أو عند تفعيل تفضيل تقليل الحركة لنظام التشغيل (تقليل الحركة في macOS، تعطيل رسوم متحركة في GNOME).

معرفات الأدوات المدعومة (--tools) — كما يتم قبول windsurf كاسم بديل لـ devin: amazon-q, antigravity, auggie, bob, claude, cline, command-code, codeartsagent, codex, devin, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, minimax-code, vibe, oh-my-pi, opencode, pi, codeassistant, qoder, qwen, rovodev, roocode, trae, zed, zcode, agents

هذه القائمة تعكس AI_TOOLS في src/core/config.ts. راجع الأدوات المدعومة لمعرفة مسارات المهارات والأوامر لكل أداة.

أمثلة:

bash

# تهيئة تفاعلية
openspec init

# التهيئة في دليل محدد
openspec init ./my-project

# غير تفاعلي: تكوين لـ Claude وCursor
openspec init --tools claude,cursor

# غير تفاعلي: تكوين مهارات MiniMax Code العامة
openspec init --tools minimax-code

# تكوين لجميع الأدوات المدعومة
openspec init --tools all

# تجاوز ملف التعريف لهذه الجلسة
openspec init --profile core

# تخطي الطلبات والتنظيف التلقائي للملفات القديمة
openspec init --force

ما ينشئه:

openspec/
├── specs/              # مواصفاتك (مصدر الحقيقة)
├── changes/            # التغييرات المقترحة
└── config.yaml         # إعدادات المشروع

.claude/skills/         # مهارات Claude Code (إذا تم تحديد claude)
.cursor/skills/         # مهارات Cursor (إذا تم تحديد cursor)
.cursor/commands/       # أوامر Cursor OPSX (إذا كان التسليم يشمل الأوامر)
.agents/skills/         # مهارات مشتركة للأدوات المتوافقة مع AGENTS.md (إذا تم تحديد agents)
... (إعدادات أدوات أخرى)

`openspec update`

تحديث ملفات تعليمات OpenSpec بعد ترقية CLI. يعيد إنشاء ملفات تكوين أدوات الذكاء الاصطناعي باستخدام ملف التعريف العام الحالي وسير العمل المحدد وطريقة التسليم.

openspec update [path] [options]

الوسائط:

الوسيط	مطلوب	الوصف
`path`	لا	الدليل الهدف (الافتراضي: الدليل الحالي)

الخيارات:

الخيار	الوصف
`--force`	فرض التحديث حتى عندما تكون الملفات محدثة بالفعل

مثال:

bash

# تحديث ملفات التعليمات بعد ترقية npm
npm install -g @fission-ai/openspec@latest
openspec update

قم بترقية الحزمة أولاً. يتم إنشاء ملفات التعليمات بواسطة CLI المثبت، لذا فإن تشغيل openspec update على تثبيت قديم يُظهر كل شيء محدثًا دون إضافة سير العمل الذي توفره الإصدارات الأحدث.

لجعل ذلك مرئيًا، يستعلم openspec update من سجل npm عما إذا كان هناك إصدار أحدث من CLI قد تم نشره. عندما يكون إصدارك متأخرًا، فإنه يعرض ترقية:

text

يتوفر إصدار أحدث من OpenSpec CLI (v1.6.0 → v1.7.0).
  التشغيل من: /usr/local/lib/node_modules/@fission-ai/openspec
? الترقية إلى v1.7.0 الآن؟ (Y/n)

إذا أجبت بنعم، يقوم بتشغيل npm install -g @fission-ai/openspec@latest ثم يعيد تشغيل التحديث باستخدام CLI الجديد بحيث يتم تطبيق سير العمل الجديد في نفس الأمر. يؤكد الترقية من خلال سؤال النسخة المثبتة من الملف الثنائي بدلاً من الوثوق برمز خروج npm، لذا إذا كان تثبيت آخر سابق في PATH الخاصة بك لا يزال يجيب، فإنه يخبرك بذلك بدلاً من ادعاء النجاح. إذا أجبت بـ "لا"، فإنه يطبع الأمر ويقوم بالتحديث باستخدام CLI الموجود لديك. Ctrl-C يوقف الأمر.

يظهر العرض فقط في طرفية تفاعلية، وفقط عندما يملك npm التثبيت — وهي الحالة الوحيدة التي يعالجها npm install -g بالفعل. كل شيء آخر يحصل على الأمر المطابق لطريقة تثبيته بدلاً من ذلك:

طريقة تثبيت OpenSpec	ما تحصل عليه
تثبيت npm عالمي	المطالبة، ويتم تشغيل الترقية لك — في طرفية تفاعلية؛ الإخراج عبر أنبوب يحصل على الأمر المطبوع بدلاً من ذلك
تثبيت عالمي عبر pnpm أو bun أو yarn أو volta	الأمر الخاص بذلك المدير: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest`, أو `volta install …@latest`
تبعية للمشروع	ملاحظة لتحديث التبعية، لأن مدير الحزم الخاص بها يملك ملف القفل
ذاكرة تخزين مؤقتة لـ `npx` / `dlx`	`npx @fission-ai/openspec@latest update` — هذا الأمر هو التحديث، لذا ليست هناك خطوة ثانية
استنساخ git	لا شيء — نسختك هي ما يقوله الفرع

عندما يُطبع أي شيء، فإنه يسمي الدليل الذي تم تحميل CLI قيد التشغيل منه — وهو الشيء الذي يجب التحقق منه عندما تقوم بالترقية ولكن هناك شل قديم لا يزال يمتلك PATH الخاصة بك.

يستعلم السجل من npm_config_registry عندما يصدّره npm، وhttps://registry.npmjs.org خلاف ذلك. لا يقرأ أي .npmrc: السماح لمحتوى الملف باختيار المكان الذي يذهب إليه الطلب الصادر هو تدفق يستحق تجنبه، كما أن .npmrc الخاص بمشروع يسافر مع المستودع. على مرآة خاصة، صدّر npm_config_registry — أو عيّن OPENSPEC_NO_UPDATE_CHECK لتخطي الفحص تمامًا. يتم تخطي الفحص عندما يكون CI مضبوطًا على أي شيء عدا قيمة إيقاف صريحة (false, 0, no, off, أو فارغة)، تحت NODE_ENV=test، وعندما يتم تعيين OPENSPEC_NO_UPDATE_CHECK (أي قيمة) أو DO_NOT_TRACK=1 أو OPENSPEC_TELEMETRY=0. يتم تشغيله قبل التحديث ويمكن أن يؤخره بمقدار 1.5 ثانية كحد أقصى — يستسلم بعد ذلك حتى عندما تسقط الشبكة الحزم بصمت، ويبقى صامتًا عندما يكون السجل غير قابل للوصول.

كيف يتم تحديد "محدث": تسجل ملفات المهارات الإصدار الذي أنشأها، لذا يقارن OpenSpec ذلك مع CLI المثبت. لا تحمل ملفات الأوامر طابع إصدار، لذا لأداة لديها أوامر ولكن لا مهارات (تسليم commands)، يقارن OpenSpec محتويات الملف مع ما سيولده الآن — التعديلات على هذه الملفات تُعتبر انحرافًا ويتم استبدالها. مع تسليم skills أو both، يتم فحص الإصدار المسجل فقط، لذا يتم ترك ملف معدّل يدويًا لا يزال إصداره مطابقًا كما هو؛ استخدم --force لإعادة كتابته. في كلتا الحالتين، الملفات المولدة هي ملك OpenSpec — احتفظ بتعليماتك الخاصة في مكان آخر.

المخازن (مستودعات OpenSpec المستقلة)

إصدار تجريبي. المخازن والميزات المبنية عليها (المراجع، سياق العمل، مجموعات العمل) جديدة؛ قد تتغير أشكال أسماء الأوامر، والخيارات، وتنسيقات الملفات، ومخرجات JSON بين الإصدارات. للحصول على دليل موجه بالمشكلة أولاً، راجع دليل المخازن.

المخزن هو مستودع OpenSpec مستقل قمت بتسجيله على هذا الجهاز — على سبيل المثال مستودع تخطيط أو مستودع عقود. تسجيل المخزن يسمح للأوامر العادية (list, show, status, validate, new change, archive, ...) بالعمل فيه من أي مكان عبر تمرير --store <id>.

`openspec store setup`

إنشاء وتسجيل مخزن محلي. عند عدم تمرير أي وسائط في الطرفية، يقوم OpenSpec بإرشاد المستخدم خلال الإعداد. يجب على الوكلاء والبرامج النصية تمرير المدخلات الصريحة واستخدام --json.

bash

openspec store setup [id] [options]

الخيارات:

الخيار	الوصف
`--path <path>`	المجلد حيث يجب أن يعيش المخزن (على سبيل المثال `~/openspec/<id>`)
`--remote <url>`	تسجيل الريبو البعيد الأساسي في ملف `store.yaml` الخاص بالمخزن الجديد
`--init-git`	تهيئة مستودع Git مع commit أولي (افتراضي)
`--no-init-git`	تخطي جميع عمليات Git: لا تهيئة ولا commit أولي
`--json`	إخراج JSON

يجب أن تمرر عمليات التشغيل غير التفاعلية (--json، البرامج النصية، الوكلاء) كل من معرف المخزن و--path. في الطرفية التفاعلية، يطالب الإعداد بتحديد الموقع مع اقتراح قابل للتحرير في مكان مرئي يملكه المستخدم (على سبيل المثال ~/openspec/<id>)؛ لا يختار افتراضيًا دليل البيانات المُدار من OpenSpec.

أمثلة:

bash

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

`openspec store register`

تسجيل مجلد مخزن محلي موجود. خلال فترة إصدار المخازن التجريبي، يمكن تسجيل جذر قبل وجود أي تغييرات، أو تطبيق مواصفات، أو أرشفة تغييرات؛ في هذه الحالة قد تكون openspec/changes/ وopenspec/specs/ وopenspec/changes/archive/ غائبة حتى تقوم الأوامر العادية بإنشائها. المستودع المقتصر على الإعدادات الذي يعرّف store: <id> يظل مؤشرًا لمخزن آخر ولا يُسجل كجذر مخزن إلا إذا تمت إزالة هذا المؤشر.

bash

openspec store register [path] [options]

الخيارات:

الخيار	الوصف
`--id <id>`	معرف المخزن؛ الافتراضي هو بيانات المخزن أو اسم المجلد
`--yes`	تأكيد إنشاء بيانات تعريف هوية المخزن لجذر OpenSpec سليم
`--json`	إخراج JSON

`openspec store unregister`

نسيان تسجيل مخزن محلي دون حذف الملفات.

bash

openspec store unregister <id> [--json]

استخدم هذا عندما يتم نقل مخزن أو استنساخه في مكان آخر، أو عندما لا ينبغي أن يظهر بعد الآن بواسطة OpenSpec على هذا الجهاز.

`openspec store remove`

نسيان تسجيل مخزن محلي وحذف مجلده المحلي.

bash

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

يعرض remove المجلد المحدد قبل الحذف في الطرفية التفاعلية. يجب على الوكلاء والبرامج النصية والمتصلين عبر JSON تمرير --yes لتأكيد الحذف. يرفض OpenSpec حذف مجلد لا يحتوي على بيانات تعريف مخزن مطابقة.

`openspec store list`

سرد المخازن المسجلة محليًا.

bash

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

`openspec store doctor`

التحقق من تسجيل المخزن المحلي وبيانات التعريف ووجود Git.

bash

openspec store doctor [id] [--json]

الـ Doctor تشخيصي فقط؛ يبلغ عن الجذور المفقودة، وعدم تطابق بيانات التعريف، وحالة السجل المحلي غير الصالحة دون تعديل المخزن.

الإشارة إلى المخازن من مشروع

يمكن لمستودع مشروع أن يعلن عن المخازن التي يعتمد عليها عمله في openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

منذ ذلك الحين، يحمل مخرجات openspec instructions في ذلك المستودع (سواءً لكل قطعة أو سطوح apply، أوضاع JSON والبشرية) فهرسًا لمواصفات كل مخزن مرجعي — معرّفات المواصفات، ملخص من سطر واحد من قسم الغرض من كل مواصفة، وأمر الجلب (openspec show <spec-id> --type spec --store <id>). يتم بناء الفهرس مباشرةً من النسخة المسجلة في كل تشغيل؛ لا يتم نسخ محتوى المواصفات أبدًا إلى المخرجات.

المراجع سياق للقراءة فقط. لا تغيّر أبدًا مكان عمل الأوامر: يبقى العمل في جذر المستودع الخاص به، والكتابة إلى مخزن مرجعي تبقى إجراءً صريحًا عبر --store. المرجع الذي لا يمكن حله (على سبيل المثال، مخزن غير مسجل على هذا الجهاز) ينخفض إلى تحذير في الفهرس مع الإصلاح المحدد، ولا تزال التعليمات تُنشأ. يبلّغ openspec doctor عن صحة المراجع في مكان واحد.

تسجيل مصدر استنساخ مخزن

يمكن للمخزن تسجيل مصدر الاستنساخ الأساسي في ملف هويته المُسجل، بحيث لا يتوقف دليل الاستخدام عند "سجل المخزن":

bash

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

يتم وضع الريبو البعيد في .openspec-store/store.yaml داخل الـ commit الأولي، لذا كل استنساخ يُنشأ وهو يعرفه. لمخزن موجود، قم بتحرير store.yaml يدويًا ثم قم بالـ commit. يعرض store doctor الريبو البعيد المسجل (وأصل Git الملاحظ في النسخة المحلية)؛ وإرشادات المشاركة في الإعداد/التسجيل تسميه؛ ويسجل register أصل النسخة المحلية في السجل المحلي للجهاز.

يمكن لإعلان المرجع أن يحمل مصدر الاستنساخ أيضًا، بحيث يحصل زميل لا يملك المخزن بعد على إصلاح كامل قابل للصق (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

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

تسجيل الريبو البعيد ليس مزامنة: لا يقوم OpenSpec أبدًا بالاستنساخ أو السحب أو الدفع من تلقاء نفسه.

إعلان مخزن افتراضي

يمكن لمستودع تمت خارجية تخطيطه بالكامل — دون openspec/specs/ أو openspec/changes/ محلية — أن يعلن مخزنه مرة واحدة بدلاً من تمرير --store في كل أمر:

yaml

# openspec/config.yaml (the only file under openspec/)
store: team-context

ثم تُحل الأوامر العادية تلقائيًا إلى المخزن المعلن؛ يبلّغ شعار الجذر وكتلة root في JSON بـ source: "declared" مع معرف المخزن، وما تزال التلميحات المطبوعة تحمل --store <id>. الإعلان هو احتياطي، وليس تجاوزًا: --store الصريح يربح دائمًا، والدليل الذي يحتوي مجلدات تخطيط حقيقية يتجاهل المؤشر (مع تحذير). لتحويل مستودع مؤشر إلى جذر OpenSpec محلي، قم بإزالة سطر store: وشغّل openspec init — يرفض init إنشاء الهيكل بينما الإعلان موجود.

يوجد متغير على مستوى الجهاز يغطي كل مستودع دفعة واحدة: openspec config set defaultStore <id> (انظر الإعداد). يتم استشارته فقط بعد فشل --store والجذر المحلي ومؤشر المشروع في الحل؛ ثم يبلّغ شعار الجذر وكتلة root في JSON بـ source: "global_default".

الفحص (صحة العلاقات)

سؤال واحد للقراءة فقط، في مكان واحد: هل جذر OpenSpec سليم، وهل المتاجر التي يشير إليها متاحة على هذا الجهاز؟

bash

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

يفصل التقرير صحة الجذر، وصحة البيانات الوصفية للمتجر (بما في ذلك ملاحظة عند اختلاف المسار البعيد المسجل عن أصل السحب، وملاحظة عندما يتخلف تخزين المتجر عن آخر مرجع تتبع للسحب)، وصحة المراجع (تظهر نفس تعليمات التشخيص، مع إصلاحات نسخ للمراجع غير المحلولة). يتم الخروج بالكود 0 لأي نتائج صحية بأي شدة — حيث يقرأ الوكلاء مصفوفات status؛ ويتم الخروج بالكود 1 فقط عند فشل الأوامر (لا جذر، متجر غير معروف). لا يقوم الفحص أبدًا بالاستنساخ أو المزامنة أو الإصلاح. للحصول على المجموعة المُجمَّعة نفسها بدلاً من صحتها، استخدم openspec context.

سياق العمل (المجموعة المُجمَّعة)

كل ما يتعلق بهذا العمل من خلال إعلانات OpenSpec، في مجموعة عمل واحدة: جذر OpenSpec والمتاجر التي يشير إليها.

bash

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

يكون الملخص JSON قابلاً للاستهلاك من قبل الوكلاء (يحمل كل متجر مُشار إليه متاح وصفة الجلب الخاصة به؛ ويحمل الأعضاء غير المحلولين نفس تعليمات الإصلاح وعرض الفحص). بالإضافة إلى ذلك، يكتب الخيار --code-workspace ملف مساحة عمل VS Code يحتوي على الجذر بالإضافة إلى المتاجر المُشار إليها المتاحة (مجلدات ref:<id>) — الكتابة الوحيدة التي يقوم بها هذا الأمر، ويُرفض بدون --force إذا كان الملف موجودًا. يتم الإبلاغ عن الأعضاء غير المتاحين، دون تخمين.

"سياق العمل" هو المجموعة المُجمَّعة؛ حقل context: في openspec/config.yaml هو خلفية المشروع التي تُحقن في التعليمات — شيئان مختلفان. يجيب openspec doctor عما إذا كانت المجموعة سليمة؛ بينما يجيب openspec context عن ماهية المجموعة.

مجموعات العمل الشخصية

بيتا. مجموعات العمل هي جزء من سطح الإصدار التجريبي الجديد؛ قد تتغير الأوامر والخيارات وتنسيقات الملفات بين الإصدارات. للاطلاع على الدليل، انظر دليل المتاجر.

مجموعة العمل هي عرض شخصي مسمى للمجلدات التي تعمل عليها معًا — جذر تخطيط بالإضافة إلى أي شيء آخر تختاره — يُحفظ على جهازك ويعاد فتحه بالاسم في أداتك. إنها محلية بحتة: لا تُحفظ مطلقًا، ولا تُشارك، ولا تُشتق من الإعلانات، وإزالة واحدة لا تمس مجلدات الأعضاء أبدًا.

bash

openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--yes] [--json]

يقوم create بتشغيل تدفق توجيه قصير (أو يأخذ خيارات --member بشكل غير تفاعلي؛ العضو الأول هو الأساسي — تبدأ الجلسات هناك). open يُطلق الأداة المختارة: المحررات (VS Code، Cursor) تفتح نافذة تحتوي على كل عضو وتعود؛ وكلاء سطر الأوامر (Claude Code، codex) يستولون على هذه الطرفية كجلسة مع جميع الأعضاء المرفقة وبدون موجه محدد مسبقًا، وتنتهي عند الخروج. يتم تخطي مجلد العضو المفقود عند الفتح مع ملاحظة؛ والباقي يُفتح. يمكن تجاوز تفضيل الأداة المحفوظة لكل فتح باستخدام --tool.

دعم أداة جديدة هو تكوين، وليس برمجة. كل أداة هي أحد نمطي تشغيل — workspace-file (تُطلق بملف .code-workspace المُنشأ) أو attach-dirs (علامة إرفاق واحدة لكل عضو) — ويضيف مفتاح openers في config.json العمومي (افتحه باستخدام openspec config edit) أدوات أو يعدل الأدوات المضمنة حسب الحقول:

json

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

تعيش جميع حالة مجموعة العمل تحت مجلد worksets/ في دليل البيانات العمومي (المشاهدات المحفوظة بالإضافة إلى ملفات <name>.code-workspace المُنشأة، والتي تُنشأ من جديد عند كل فتح)؛ حذف هذا المجلد يزيل كل أثر.

أوامر التصفح

`openspec list`

سرد التغييرات أو المواصفات في مشروعك.

openspec list [options]

الخيارات:

الخيار	الوصف
`--specs`	سرد المواصفات بدلاً من التغييرات
`--changes`	سرد التغييرات (الافتراضي)
`--sort <order>`	الفرز حسب `recent` (الأحدث، الافتراضي) أو `name`
`--json`	الإخراج بصيغة JSON

أمثلة:

bash

# سرد جميع التغييرات النشطة
openspec list

# سرد جميع المواصفات
openspec list --specs

# إخراج JSON للاستخدام في السكربتات
openspec list --json

الناتج (نصي):

التغييرات:
  add-dark-mode     لا مهام         للتو

`openspec view`

عرض لوحة تفاعلية لاستعراض المواصفات والتغييرات.

openspec view

يفتح واجهة مبنية على الطرفية للتنقل بين مواصفات مشروعك وتغييراته.

`openspec show`

عرض تفاصيل تغيير أو مواصفة.

openspec show [item-name] [options]

الوسائط:

الوسيط	مطلوب	الوصف
`item-name`	لا	اسم التغيير أو المواصفة (يطلب إذا تم حذفه)

الخيارات:

الخيار	الوصف
`--type <type>`	تحديد النوع: `change` أو `spec` (يتم الاكتشاف التلقائي إذا كان غير ملتبس)
`--json`	الإخراج بصيغة JSON
`--no-interactive`	تعطيل المطالبات

خيارات خاصة بالتغييرات:

الخيار	الوصف
`--deltas-only`	عرض المواصفات الدلتا فقط (وضع JSON)

خيارات خاصة بالمواصفات:

الخيار	الوصف
`--requirements`	عرض المتطلبات فقط، استبعاد السيناريوهات (وضع JSON)
`--no-scenarios`	استبعاد محتوى السيناريوهات (وضع JSON)
`-r, --requirement <id>`	عرض متطلب محدد بالفهرس المبني على 1 (وضع JSON)

أمثلة:

bash

# اختيار تفاعلي
openspec show

# عرض تغيير معين
openspec show add-dark-mode

# عرض مواصفة معينة
openspec show auth --type spec

# إخراج JSON للتحليل
openspec show add-dark-mode --json

أوامر التحقق

`openspec validate`

تحقق من التغييرات والمواصفات بحثًا عن مشاكل بنيوية، وافحص متطلبات التغيير المُعدَّلة مقابل المواصفات الرئيسية التي ستحل محلها.

openspec validate [item-name] [options]

يفشل التغيير الذي لا يحتوي على أي فروقات في المواصفات في التحقق ما لم يُصرّح ملف .openspec.yaml الخاص به بـ skip_specs: true (للإعادة الهيكلة البحتة، أو الأدوات، أو أعمال التوثيق — راجع وصفة 5).

الحجج:

الحجة	إلزامية	الوصف
`item-name`	لا	عنصر محدد للتحقق منه (يطلب إدخالًا إذا حُذف)

الخيارات:

الخيار	الوصف
`--all`	تحقق من جميع التغييرات والمواصفات
`--changes`	تحقق من جميع التغييرات
`--specs`	تحقق من جميع المواصفات
`--archived`	تحقق من أن جميع التغييرات المؤرشفة مكتملة مهامها (للتحقق قبل الالتزام)
`--type <type>`	حدد النوع عند وجود غموض في الاسم: `change` أو `spec`
`--strict`	فعّل وضع التحقق الصارم
`--json`	أخرج النتائج بصيغة JSON
`--concurrency <n>`	الحد الأقصى للتحققات المتوازية (الافتراضي: 6، أو متغير البيئة `OPENSPEC_CONCURRENCY`)
`--no-interactive`	عطّل طلبات الإدخال

--archived نطاق مستقل بذاته: لا يتحقق من فروقات المواصفات (لأنها طُبِّقت وقت الأرشفة)، بل يتحقق من أن جميع التغييرات تحت changes/archive/ مُعلَّمة جميع مربعات tasks.md الخاصة بها، وينتهي بأكبر من صفر إذا وجدت مربعات غير مُعلَّمة. هذا يلتقط التغييرات التي أُرشفت مع أعمال غير مكتملة — مفيد في خطاف ما قبل الالتزام.

أمثلة:

bash

# Interactive validation
openspec validate

# Validate a specific change
openspec validate add-dark-mode

# Validate all changes
openspec validate --changes

# Validate everything with JSON output (for CI/scripts)
openspec validate --all --json

# Strict validation with increased parallelism
openspec validate --all --strict --concurrency 12

# Fail if any archived change still has unchecked tasks
openspec validate --archived

المخرجات (نص):

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

1 warning found

المخرجات (JSON):

json

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

أوامر دورة الحياة

`openspec archive`

أرشف تغيير مكتمل وادمج مواصفات الفروقات في المواصفات الرئيسية.

openspec archive [change-name] [options]

الحجج:

الحجة	إلزامية	الوصف
`change-name`	لا	التغيير المراد أرشفته (يطلب إدخالًا إذا حُذف؛ إلزامي عندما لا يمكن الرد على الطلب)

الخيارات:

الخيار	الوصف
`-y, --yes`	تخطي طلبات التأكيد. إلزامي عندما لا يمكن الرد عليها — وكيل ذكاء اصطناعي، مهمة CI، أو أي تشغيل مع stdin مغلق
`--skip-specs`	تخطي تحديثات المواصفات لأرشفة واحدة. التغيير الذي لا يحتوي على فروقات مواصفات بشكل دائم يجب أن يُصرّح بـ `skip_specs: true` في ملف `.openspec.yaml` الخاص به — يُرشف دون أي خيار
`--no-validate`	تخطي التحقق (يتطلب تأكيدًا). يعطّل أيضًا تقاعد القدرات — دون حكم من المُتحقِّق، لا شيء يُتقاعد

أمثلة:

bash

# Interactive archive (asks which change, then confirms)
openspec archive

# Archive specific change
openspec archive add-dark-mode

# Archive without prompts (agents, CI, scripts)
openspec archive add-dark-mode --yes

# Archive a tooling change that doesn't affect specs
openspec archive update-ci-config --skip-specs

تقاعد قدرة: أضف علامة التقاعد إلى بيانات التغيير الوصفية:

yaml

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

ثم أرشف التغيير بشكل طبيعي:

bash

openspec archive retire-legacy --yes

عندما يزيل التغيير آخر متطلب للقدرة، يحذف OpenSpec ملف spec.md النشط الخاص بها. تبقى فروقات القدرات الأخرى في نفس التغيير تحدّث مواصفاتها الرئيسية. دون العلامة، يتوقف الأرشف قبل تغيير أي ملفات ويخبرك بإضافتها.

ما الذي يفعله:

يتحقق من التغيير (ما لم يُمرَّر --no-validate)
يطلب تأكيدًا (ما لم يُمرَّر --yes)
يحتفظ بمسار الأرشفة قبل تغيير أي مواصفة رئيسية
يتحقق وادمج مواصفات الفروقات النشطة في openspec/specs/ — قدرة يُزيل التغيير آخر متطلب لها تُتقاعد ويُحذف ملف مواصفاتها، لكن فقط عندما يُصرّح ملف .openspec.yaml الخاص بالتغيير بـ retire_capabilities: true بجانب schema:
ينقل مجلد التغيير إلى openspec/changes/archive/YYYY-MM-DD-<name>/
إذا فشل تعديل مواصفة أو النقل النهائي قبل تأمين أرشفة كاملة، يُعيد المواصفات ويترك التغيير أو يعيده إلى مساره النشط
إذا اكتملت نسخة احتياطية مُتحقَّق منها لكن فشل تنظيف المصدر المؤقت، يحتفظ بالأرشفة الكاملة وحالة المواصفات المُلتزَم بها للاستعادة

دون طرفية: وكيل ذكاء اصطناعي، مهمة CI، أو أي تشغيل مع stdin مغلق لا يستطيع الرد على الخطوة 2، لذا يتوقف الأرشف قبل لمس أي شيء، وينتهي برمز 1، ويسمّي الأمر لإعادة التشغيل — openspec archive <name> --yes، حاملًا أي خيارات أخرى مررتها. مرّر --yes (واسم التغيير) مسبقًا لتخطي ذهاب وإياب.

أوامر سير العمل

تدعم هذه الأوامر سير عمل OPSX القائم على الأرتيفاكت. وهي مفيدة لكل من البشر الذين يتحققون من التقدم والوكلاء الذين يحددون الخطوات التالية.

`openspec new change`

أنشئ دليل تغيير وبيانات وصفية اختيارية مُسجلة في جذر OpenSpec المُحل.

bash

openspec new change <name> [options]

يجب أن تستخدم أسماء التغييرات حالة kebab-case بأحرف صغيرة: أحرف صغيرة وأرقام وواصلات مفردة. لا يمكن أن تحتوي على مسافات أو شرطات سفلية أو أحرف كبيرة أو واصلات متتالية أو واصلات بادئة أو لاحقة. يُسمح برقم بادئ، لذا يمكنك بادئة الأسماء لترتيب أو تصنيف التغييرات، على سبيل المثال 100-add-feature أو 00001-add-auth.

الخيارات:

الخيار	الوصف
`--description <text>`	الوصف الذي سيُضاف إلى `index.md`
`--goal <text>`	بيانات هدف اختيارية تُخزن مع التغيير
`--schema <name>`	مخطط سير العمل الذي سيُستخدم
`--store <id>`	معرّف المخزن الذي سيُستخدم كجذر OpenSpec (المخزن هو مستودع OpenSpec مستقل قمت بتسجيله)
`--json`	إخراج JSON

أمثلة:

bash

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

`openspec status`

عرض حالة اكتمال الأرتيفاكت لتغيير.

openspec status [options]

الخيارات:

الخيار	الوصف
`--change <id>`	اسم التغيير (يُطلب إذا تم حذفه)
`--schema <name>`	تجاوز المخطط (يُكتشف تلقائيًا من إعدادات التغيير)
`--json`	إخراج JSON

أمثلة:

bash

# فحص تفاعلي للحالة
openspec status

# حالة تغيير محدد
openspec status --change add-dark-mode

# JSON لاستخدام الوكيل
openspec status --change add-dark-mode --json

الناتج (نص):

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

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

التغيير الذي يصرّح بـ skip_specs: true يعرض مرحلة المواصفات كـ [~] specs (تم تخطيها: يصرّح التغيير بـ skip_specs) ويستبعدها من عدد التقدم.

الناتج (JSON):

json

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

isPlanningComplete يوضح ما إذا كان كل أرتيفاكت تخطيط غير متخطي موجود؛ تُعد الأرتيفاكتات المتخطاة راضية دون إنشائها. لا يوضح ما إذا كانت مهام التنفيذ مكتملة. يتم الإبقاء على isComplete كاسم مستعار للتوافق بنفس القيمة.

تُدرج الأرتيفاكتات بترتيب التبعية - لا يظهر تبع أبدًا بعد شيء يتطلبه - والأرتيفاكتات التي تصبح جاهزة في نفس الوقت (في spec-driven، يحتاج كل من specs و design إلى proposal فقط) تحتفظ بالترتيب الذي يعلنها المخطط بدلاً من الترتيب الأبجدي. لذا فإن أول إدخال ready هو الأرتيفاكت الذي يجب كتابته تاليًا.

`openspec instructions`

احصل على تعليمات موسعة لإنشاء أرتيفاكت أو تطبيق المهام. يستخدمه الوكلاء الذكيون لفهم ما يجب إنشاؤه بعد ذلك.

openspec instructions [artifact] [options]

الحجج:

الحجة	مطلوب	الوصف
`artifact`	لا	معرّف الأرتيفاكت، أو سطح إدخال سير العمل: `apply` أو `archive`

الخيارات:

الخيار	الوصف
`--change <id>`	اسم التغيير (مطلوب في الوضع غير التفاعلي)
`--schema <name>`	تجاوز المخطط
`--json`	إخراج JSON

حالات خاصة: استخدم apply للحصول على تعليمات تنفيذ المهام. استخدم archive لجلب مدخلات الأرشيف الحالية للقراءة فقط (context و operationGuidance) لتغيير صالح؛ وهو لا يقوم بأرشفة أو تعديل أي شيء.

أمثلة:

bash

# الحصول على تعليمات للأرتيفاكت التالي
openspec instructions --change add-dark-mode

# الحصول على تعليمات أرتيفاكت محدد
openspec instructions design --change add-dark-mode

# الحصول على تعليمات التطبيق/التنفيذ
openspec instructions apply --change add-dark-mode

# الحصول على مدخلات عملية الأرشيف الحالية بدون أرشفة
openspec instructions archive --change add-dark-mode --json

# JSON لاستهلاك الوكيل
openspec instructions design --change add-dark-mode --json

يتضمن الناتج:

محتوى القالب للأرتيفاكت
سياق المشروع من الإعدادات
محتوى من الأرتيفاكتات التابعة
قواعد لكل أرتيفاكت من الإعدادات
سياق المشروع الحالي وإرشادات العملية المطابقة لـ apply/archive

تُقرأ مدخلات العملية من المستودع المُحل أو المخزن المحدد في كل استدعاء. سياق المشروع هو إدخال مطلوب على مستوى الموجه: يقرأه الوكلاء ويطبقون الحقائق والاتفاقيات والقيود ذات الصلة بالمشروع. إرشادات العملية هي نصيحة إضافية اختيارية: ينظر الوكلاء في كل إدخال ويتبعون فقط الإدخالات القابلة للتطبيق والمتوافقة مع سير العمل المدمج. يظل كلا الحقلين منفصلين عن اختيارات المستخدم الصريحة، والحالة التي يتحكم بها CLI، والتعليمات المدمجة، وقواعد الأرتيفاكت. يتم الإبلاغ عن السياق المتعارض؛ ولا يتم اتباع الإرشادات المتعارضة أو غير القابلة للتطبيق ويتم شرح السبب. هذه عقود سلوكية للوكلاء المولّدين، وليست فحوصات CLI إلزامية. instructions archive يعيد فقط التغيير المحدد، والمدخلات الاختيارية، وبيانات الجذر الوصفية؛ ولا يتضمن سير عمل الأرشيف الثابت.

بالنسبة لأرتيفاكت تم تخطيه عبر skip_specs: true، يكون الناتج تحذيرًا فقط (يضيف JSON حقول skipped/warning) — يجب عدم إنشاء الأرتيفاكت.

`openspec templates`

اعرض مسارات القوالب المُحلّة لجميع الأرتيفاكتات في مخطط.

openspec templates [options]

الخيارات:

الخيار	الوصف
`--schema <name>`	المخطط الذي سيتم فحصه (الافتراضي: `spec-driven`)
`--json`	إخراج JSON

أمثلة:

bash

# عرض مسارات القوالب للمخطط الافتراضي
openspec templates

# عرض القوالب لمخطط مخصص
openspec templates --schema my-workflow

# JSON للاستخدام البرمجي
openspec templates --json

الناتج (نص):

Schema: spec-driven

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

`openspec schemas`

اعرض مخططات سير العمل المتاحة مع أوصافها وتدفقات الأرتيفاكت.

openspec schemas [options]

الخيارات:

الخيار	الوصف
`--json`	إخراج JSON
`--store <id>`	استخدم مخزنًا مسجلًا كجذر OpenSpec

مثال:

bash

openspec schemas

الناتج:

Available schemas:

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

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

أوامر المخططات

أوامر لإنشاء وإدارة مخططات سير العمل المخصصة.

`openspec schema init`

إنشاء مخطط محلي للمشروع جديد.

openspec schema init <name> [options]

الوسائط:

الوسيط	مطلوب	الوصف
`name`	نعم	اسم المخطط (بصيغة kebab-case)

الخيارات:

الخيار	الوصف
`--description <text>`	وصف المخطط
`--artifacts <list>`	قائمة بمعرفات النواتج مفصولة بفواصل (الافتراضي: `proposal,specs,design,tasks`)
`--default`	تعيين كمخطط افتراضي للمشروع
`--no-default`	عدم المطالبة بتعيينه كافتراضي
`--force`	استبدال المخطط الموجود
`--json`	الإخراج بصيغة JSON

أمثلة:

bash

# إنشاء مخطط تفاعلي
openspec schema init research-first

# غير تفاعلي مع نواتج محددة
openspec schema init rapid \
  --description "سير عمل التطوير السريع" \
  --artifacts "proposal,tasks" \
  --default

ما ينشئه:

openspec/schemas/<name>/
├── schema.yaml           # تعريف المخطط
└── templates/
    ├── proposal.md       # قالب لكل ناتج
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

نسخ مخطط موجود إلى مشروعك للتخصيص.

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

الوسائط:

الوسيط	مطلوب	الوصف
`source`	نعم	المخطط المراد نسخه
`name`	لا	اسم المخطط الجديد (الافتراضي: `<source>-custom`)

الخيارات:

الخيار	الوصف
`--force`	استبدال الوجهة الموجودة
`--json`	الإخراج بصيغة JSON

مثال:

bash

# نسخ المخطط المدمج القائم على المواصفات
openspec schema fork spec-driven my-workflow

`openspec schema validate`

التحقق من صحة بنية المخطط وقوالبه.

openspec schema validate [name] [options]

الوسائط:

الوسيط	مطلوب	الوصف
`name`	لا	المخطط المراد التحقق منه (يتحقق من الكل إذا حُذف)

الخيارات:

الخيار	الوصف
`--verbose`	عرض خطوات التحقق التفصيلية
`--json`	الإخراج بصيغة JSON

مثال:

bash

# التحقق من مخطط محدد
openspec schema validate my-workflow

# التحقق من جميع المخططات
openspec schema validate

`openspec schema which`

إظهار مصدر المخطط (مفيد لتصحيح أخطاء الأولوية).

openspec schema which [name] [options]

الوسائط:

الوسيط	مطلوب	الوصف
`name`	لا	اسم المخطط

الخيارات:

الخيار	الوصف
`--all`	سرد جميع المخططات مع مصادرها
`--json`	الإخراج بصيغة JSON

مثال:

bash

# التحقق من مصدر مخطط
openspec schema which spec-driven

الناتج:

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

أسبقية المخططات:

المشروع: openspec/schemas/<name>/
المستخدم: ~/.local/share/openspec/schemas/<name>/
الحزمة: المخططات المدمجة

أوامر التكوين

`openspec config`

عرض وتعديل تكوين OpenSpec العام.

openspec config <subcommand> [options]

الأوامر الفرعية:

الأمر الفرعي	الوصف
`path`	عرض مسار ملف التكوين
`list`	عرض جميع الإعدادات الحالية
`get <key>`	الحصول على قيمة محددة
`set <key> <value>`	تعيين قيمة
`unset <key>`	إزالة مفتاح
`reset`	إعادة التعيين إلى الافتراضيات
`edit`	فتح في `$EDITOR`
`profile [preset]`	تكوين ملف سير العمل بشكل تفاعلي أو عبر إعداد مسبق

أمثلة:

bash

# إظهار مسار ملف التكوين
openspec config path

# سرد جميع الإعدادات
openspec config list

# الحصول على قيمة محددة
openspec config get telemetry.enabled

# تعيين قيمة (تعطيل إرسال إحصائيات الاستخدام المجهولة)
openspec config set telemetry.enabled false

# تعيين قيمة نصية بشكل صريح
openspec config set user.name "My Name" --string

# إزالة إعداد مخصص
openspec config unset user.name

# تعيين مخزن افتراضي على مستوى الجهاز (جذر احتياطي عند عدم وجود --store أو جذر محلي أو مؤشر مخزن المشروع)
openspec config set defaultStore team-plans

# إعادة تعيين جميع التكوينات
openspec config reset --all --yes

# تعديل التكوين في المحرر
openspec config edit

# تكوين الملف الشخصي باستخدام معالج قائم على الإجراءات
openspec config profile

# إعداد مسبق سريع: التبديل إلى سير العمل الأساسي (يحتفظ بوضع التسليم)
openspec config profile core

إلغاء الاشتراك في القياس عن بُعد: الإعداد telemetry.enabled يكون مفعّلاً افتراضياً عند عدم ضبطه (نموذج إلغاء الاشتراك). قم بتعيينه إلى false لتعطيل إحصائيات الاستخدام المجهولة وفحص إصدار openspec update. متغيرات البيئة لها الأسبقية على التكوين: OPENSPEC_TELEMETRY=0 و DO_NOT_TRACK=1 وأي قيمة صحيحة لـ CI (مثل true/1/yes) تعطّل القياس عن بُعد دائماً بغض النظر عن قيمة التكوين.

openspec config profile يبدأ بملخص للحالة الحالية، ثم يتيح لك الاختيار:

تغيير التسليم + سير العمل
تغيير التسليم فقط
تغيير سير العمل فقط
الإبقاء على الإعدادات الحالية (خروج)

إذا أبقيت على الإعدادات الحالية، لا تتم كتابة أي تغييرات ولا يظهر أي تنبيه للتحديث. إذا لم تكن هناك تغييرات في التكوين ولكن ملفات المشروع الحالية غير متزامنة مع ملفك الشخصي/التسليم العام، فسيُظهر OpenSpec تحذيراً ويقترح openspec update. يؤدي الضغط على Ctrl+C أيضاً إلى إلغاء التدفق بشكل نظيف (بدون تتبع للمكدس) والخروج بالرمز 130. في قائمة التحقق من سير العمل، تعني [x] أن سير العمل محدد في التكوين العام. لتطبيق تلك التحديدات على ملفات المشروع، شغّل openspec update (أو اختر تطبيق التغييرات على هذا المشروع الآن؟ عند المطالبة داخل المشروع).

أمثلة تفاعلية:

bash

# تحديث التسليم فقط
openspec config profile
# اختر: تغيير التسليم فقط
# اختر التسليم: المهارات فقط

# تحديث سير العمل فقط
openspec config profile
# اختر: تغيير سير العمل فقط
# قم بتبديل سير العمل في القائمة، ثم أكّد

أوامر مساعدة

`openspec feedback`

إرسال ملاحظات حول OpenSpec. ينشئ مشكلة على GitHub.

openspec feedback <message> [options]

الوسائط:

الوسيط	مطلوب	الوصف
`message`	نعم	ملخص الملاحظات؛ يتم تقصير النص الطويل في عنوان المشكلة ويُحفظ في النص

الخيارات:

الخيار	الوصف
`--body <text>`	تفاصيل إضافية تُدرج بعد الملخص

المتطلبات: يجب تثبيت واجهة أوامر GitHub (gh) وتوثيقها.

مثال:

bash

openspec feedback "إضافة دعم لأنواع النواتج المخصصة" \
  --body "أود تعريف أنواع نواتج خاصة بي تتجاوز الأنواع المدمجة."

`openspec completion`

إدارة إكمالات أوامر الـ shell لـ OpenSpec CLI.

openspec completion <subcommand> [shell]

الأوامر الفرعية:

الأمر الفرعي	الوصف
`generate [shell]`	إخراج سكريبت الإكمال إلى stdout
`install [shell]`	تثبيت الإكمال للـ shell الخاص بك
`uninstall [shell]`	إزالة الإكمالات المثبتة

الأصداف المدعومة: bash, zsh, fish, powershell

أمثلة:

bash

# تثبيت الإكمالات (يكتشف الـ shell تلقائياً)
openspec completion install

# التثبيت لـ shell محدد
openspec completion install zsh

# إنشاء سكريبت للتثبيت اليدوي (bash)
openspec completion generate bash > ~/.bash_completion.d/openspec

# إلغاء التثبيت
openspec completion uninstall

نظام Windows (PowerShell): تثبيت الإكمالات لمضيف PowerShell الحالي:

powershell

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

يُخبر $env:PROFILE OpenSpec أي ملف شخصي يجب تكوينه في هذه الجلسة. ينشئ المثبّت أدلة الملف الشخصي المفقودة ويضيف كتلة مُدارة تقوم بتحميل OpenSpecCompletion.ps1. إعادة تحميل الملف الشخصي تُفعّل الإكمالات فوراً.

لإلغاء التثبيت من المضيف الحالي، شغّل:

powershell

$env:PROFILE = $PROFILE
openspec completion uninstall powershell

أعد تشغيل PowerShell بعد إلغاء التثبيت لمسح الإكمالات من الجلسة الحالية.

الإكمالات اختيارية. تذكرها واجهة الأوامر مرة واحدة فقط، على stderr، في أول تشغيل لأمر في طرفية تفاعلية، ولا تعود لتظهر بعدها — كما تبقى صامتة إذا كانت الإكمالات مثبتة مسبقاً. اضبط OPENSPEC_NO_COMPLETIONS=1 لإخفاء هذا التلميح تماماً.

رموز الخروج

الرمز	المعنى
`0`	نجاح
`1`	خطأ (فشل التحقق، ملفات مفقودة، إلخ)

متغيرات البيئة

المتغير	الوصف
`OPENSPEC_TELEMETRY`	اضبط على `0` لتعطيل القياس عن بُعد وفحص إصدار `openspec update` (يتجاوز `telemetry.enabled` في التكوين العام)
`DO_NOT_TRACK`	اضبط على `1` لتعطيل القياس عن بُعد وفحص إصدار `openspec update` (إشارة DNT قياسية؛ تتجاوز التكوين)
`OPENSPEC_CONCURRENCY`	التوازي الافتراضي للتحقق الجماعي (الافتراضي: 6)
`EDITOR` أو `VISUAL`	المحرر المستخدم لأمر `openspec config edit`
`NO_COLOR`	تعطيل الألوان في المخرجات عند الضبط
`OPENSPEC_NO_ANIMATION`	تعطيل رسوم الترحيب المتحركة لأمر `openspec init` عند الضبط
`OPENSPEC_NO_COMPLETIONS`	اضبط على `1` لمنع التلميح لمرة واحدة حول إكمالات الـ shell
`OPENSPEC_NO_UPDATE_CHECK`	تعطيل فحص `openspec update` لإصدار أحدث من الواجهة عند الضبط (أي قيمة، حتى الفارغة). يتم تخطيه أيضاً عند ضبط `CI` (ما لم تكن `false`/`0`/`no`/`off`) أو `NODE_ENV=test`
`npm_config_registry`	السجل الذي يسأله فحص إصدار `openspec update`. يجب أن يكون رابط `http(s)` وإلا يعود إلى `https://registry.npmjs.org`. لا يتم قراءة ملف `.npmrc`

وثائق ذات صلة

الأوامر - أوامر الـ AI باستخدام الشرطة المائلة (/opsx:propose, /opsx:apply, إلخ)
سير العمل - الأنماط الشائعة ومتى تستخدم كل أمر
التخصيص - إنشاء مخططات وقوالب مخصصة
بدء الاستخدام - دليل الإعداد لأول مرة

مرجع سطر الأوامر ​

الملخص ​

أوامر المستخدم البشري مقابل أوامر الوكلاء ​

أوامر مخصصة للبشر فقط ​

أوامر متوافقة مع الوكلاء ​

الخيارات العامة ​

أوامر الإعداد ​

openspec init ​

openspec update ​

المخازن (مستودعات OpenSpec المستقلة) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

الإشارة إلى المخازن من مشروع ​

تسجيل مصدر استنساخ مخزن ​

إعلان مخزن افتراضي ​

الفحص (صحة العلاقات) ​

سياق العمل (المجموعة المُجمَّعة) ​

مجموعات العمل الشخصية ​

أوامر التصفح ​

openspec list ​

openspec view ​

openspec show ​

أوامر التحقق ​

openspec validate ​

أوامر دورة الحياة ​

openspec archive ​

أوامر سير العمل ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

أوامر المخططات ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

أوامر التكوين ​

openspec config ​

أوامر مساعدة ​

openspec feedback ​

openspec completion ​

رموز الخروج ​

متغيرات البيئة ​

وثائق ذات صلة ​

مرجع سطر الأوامر

الملخص

أوامر المستخدم البشري مقابل أوامر الوكلاء

أوامر مخصصة للبشر فقط

أوامر متوافقة مع الوكلاء

الخيارات العامة

أوامر الإعداد

`openspec init`

`openspec update`

المخازن (مستودعات OpenSpec المستقلة)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

الإشارة إلى المخازن من مشروع

تسجيل مصدر استنساخ مخزن

إعلان مخزن افتراضي

الفحص (صحة العلاقات)

سياق العمل (المجموعة المُجمَّعة)

مجموعات العمل الشخصية

أوامر التصفح

`openspec list`

`openspec view`

`openspec show`

أوامر التحقق

`openspec validate`

أوامر دورة الحياة

`openspec archive`

أوامر سير العمل

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

أوامر المخططات

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

أوامر التكوين

`openspec config`

أوامر مساعدة

`openspec feedback`

`openspec completion`

رموز الخروج

متغيرات البيئة

وثائق ذات صلة