سير عمل OPSX
نرحب بالملاحظات على Discord.
ما هو؟
OPSX هو الآن سير العمل القياسي لـ OpenSpec.
إنه سير عمل مرن ومتكرر لتغييرات OpenSpec. لا مزيد من المراحل الجامدة — فقط إجراءات يمكنك اتخاذها في أي وقت.
لماذا يوجد هذا
سير العمل القديم OpenSpec يعمل، لكنه مقفل:
- التعليمات مبرمجة مسبقًا — مدفونة في TypeScript، لا يمكنك تغييرها
- الكل أو لا شيء — أمر واحد كبير ينشئ كل شيء، لا يمكنك اختبار أجزاء فردية
- هيكل ثابت — نفس سير العمل للجميع، بدون تخصيص
- صندوق أسود — عندما يكون خرج الذكاء الاصطناعي سيئًا، لا يمكنك تعديل الأوامر
OPSX يفتحه. الآن يمكن لأي شخص:
- التجربة مع التعليمات — قم بتحرير قالب، وانظر إذا كان الذكاء الاصطناعي أفضل
- الاختبار بشكل تفصيلي — تحقق من تعليمات كل أداة بشكل مستقل
- تخصيص سير العمل — حدد أدواتك الخاصة والتبعيات
- التكرار بسرعة — غيّر قالبًا، اختبر فورًا، بدون إعادة بناء
سير العمل القديم: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ مبرمجة مسبقًا في الحزمة │ │ schema.yaml │◄── أنت تحرر هذا
│ (لا يمكن تغييرها) │ │ templates/*.md │◄── أو هذا
│ ↓ │ │ ↓ │
│ انتظر إصدارًا جديدًا │ │ تأثير فوري │
│ ↓ │ │ ↓ │
│ اأمل أنه أفضل │ │ اختبره بنفسك │
└────────────────────────┘ └────────────────────────┘هذا للجميع:
- الفرق — أنشئ سير عمل يطابق طريقة عملك الفعلية
- المستخدمون المتقدمون — عدل الأوامر للحصول على مخرجات ذكاء اصطناعي أفضل لقاعدة الكود الخاصة بك
- مساهمو OpenSpec — جرب نهجًا جديدًا دون إصدارات
כולנו لا نزال نتعلم ما هو الأفضل. OPSX يتيح لنا التعلم معًا.
تجربة المستخدم
المشكلة مع سير العمل الخطي: أنت في "مرحلة التخطيط"، ثم "مرحلة التنفيذ"، ثم "انتهى". لكن العمل الحقيقي لا يعمل بهذه الطريقة. أنت تنفذ شيئًا، وتدرك أن تصميمك كان خاطئًا، تحتاج إلى تحديث المواصفات، ثم تستمر في التنفيذ. المراحل الخطية تتصادم مع كيفية حدوث العمل فعليًا.
نهج OPSX:
- إجراءات، وليس مراحل — إنشاء، تنفيذ، تحديث، أرشفة — قم بأي منها في أي وقت
- التبعيات هي مُمكِّنات — تُظهر ما هو ممكن، وليس ما هو مطلوب بعد ذلك
proposal ──→ specs ──→ design ──→ tasks ──→ implementالإعداد
bash
# تأكد من تثبيت openspec — يتم إنشاء المهارات تلقائيًا
openspec initهذا ينشئ مهارات في .claude/skills/ (أو ما يعادلها) التي يكتشفها مساعدو البرمجة بالذكاء الاصطناعي تلقائيًا.
بشكل افتراضي، يستخدم OpenSpec ملف تعريف سير العمل core (propose، explore، apply، sync، archive). إذا كنت تريد أوامر سير العمل الموسعة (new، continue، ff، verify، bulk-archive، onboard)، قم بتكوينها باستخدام openspec config profile وطبقها باستخدام openspec update.
أثناء الإعداد، سيُطلب منك إنشاء تكوين مشروع (openspec/config.yaml). هذا اختياري ولكن يُوصى به.
تكوين المشروع
يتيح لك تكوين المشروع تعيين الافتراضيات وحقن سياق خاص بالمشروع في جميع الأدوات.
إنشاء التكوين
يتم إنشاء التكوين أثناء openspec init، أو يدويًا:
yaml
# openspec/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flowsحقول التكوين
| الحقل | النوع | الوصف |
|---|---|---|
schema | string | المخطط الافتراضي للتغييرات الجديدة (مثل spec-driven) |
context | string | سياق المشروع المحقون في تعليمات جميع الأدوات |
rules | object | قواعد لكل أداة، مفتاحها هو معرّف الأداة |
كيف يعمل
أولوية المخطط (من الأعلى إلى الأقل):
- علامة CLI (
--schema <name>) - بيانات التعريف للتغيير (
.openspec.yamlفي دليل التغيير) - تكوين المشروع (
openspec/config.yaml) - الافتراضي (
spec-driven)
حقن السياق:
- يُضاف السياق في بداية تعليمات كل أداة
- يُلف بعلامات
<context>...</context> - يساعد الذكاء الاصطناعي على فهم اتفاقيات مشروعك
حقن القواعد:
- تُحقن القواعد فقط للأدوات المطابقة
- تُلف بعلامات
<rules>...</rules> - تظهر بعد السياق، قبل القالب
معرّفات الأدوات حسب المخطط
spec-driven (الافتراضي):
proposal— اقتراح التغييرspecs— المواصفاتdesign— التصميم التقنيtasks— مهام التنفيذ
التحقق من صحة التكوين
- معرّفات الأدوات غير المعروفة في
rulesتُنشئ تحذيرات - يتم التحقق من أسماء المخططات مقابل المخططات المتاحة
- السياق له حد حجم 50KB
- يُبلّغ عن YAML غير صالح مع أرقام الأسطر
استكشاف الأخطاء وإصلاحها
"معرّف أداة غير معروف في القواعد: X"
- تحقق من تطابق معرّفات الأدوات مع مخططك (انظر القائمة أعلاه)
- شغّل
openspec schemas --jsonلرؤية معرّفات الأدوات لكل مخطط
التكوين لا يُطبق:
- تأكد من أن الملف في
openspec/config.yaml(وليس.yml) - تحقق من بنية YAML باستخدام مُحقق
- تغييرات التتكوين تأخذ مفعولها فورًا (لا حاجة لإعادة التشغيل)
السياق كبير جدًا:
- السياق محدود بـ 50KB
- لخّص أو أنشئ رابطًا إلى مستندات خارجية بدلاً من ذلك
الأوامر
| الأمر | ماذا يفعل |
|---|---|
/opsx:propose | إنشاء تغيير وإنشاء أدوات التخطيط في خطوة واحدة (المسار السريع الافتراضي) |
/opsx:explore | التفكير في الأفكار، التحقيق في المشكلات، توضيح المتطلبات |
/opsx:new | بدء هيكل تغيير جديد (سير العمل الموسّع) |
/opsx:continue | إنشاء الأداة التالية (سير العمل الموسّع) |
/opsx:ff | تقديم سريع لأدوات التخطيط (سير العمل الموسّع) |
/opsx:apply | تنفيذ المهام، مع تحديث الأدوات حسب الحاجة |
/opsx:verify | التحقق من صحة التنفيذ مقابل الأدوات (سير العمل الموسّع) |
/opsx:sync | مزامنة مواصفات الدلتا مع الرئيسية (سير العمل الافتراضي، اختياري) |
/opsx:archive | الأرشفة عند الانتهاء |
/opsx:bulk-archive | أرشفة تغييرات متعددة مكتملة (سير العمل الموسّع) |
/opsx:onboard | جولة إرشادية لتغيير شامل من البداية إلى النهاية (سير العمل الموسّع) |
الاستخدام
استكشاف فكرة
/opsx:exploreالتفكير في الأفكار، التحقيق في المشكلات، مقارنة الخيارات. لا حاجة لهيكل محدد - مجرد شريك تفكير. عندما تتبلور الرؤى، انتقل إلى /opsx:propose (الافتراضي) أو /opsx:new//opsx:ff (الموسّع).
بدء تغيير جديد
/opsx:proposeينشئ التغيير ويولّد أدوات التخطيط اللازمة قبل التنفيذ.
إذا قمت بتمكين سير العمل الموسّع، يمكنك بدلاً من ذلك استخدام:
text
/opsx:new # الهيكل فقط
/opsx:continue # إنشاء أداة واحدة في كل مرة
/opsx:ff # إنشاء جميع أدوات التخطيط دفعة واحدةإنشاء الأدوات
/opsx:continueيعرض ما هو جاهز للإنشاء بناءً على التبعيات، ثم ينشئ أداة واحدة. استخدمه بشكل متكرر لبناء تغييرك بشكل تدريجي.
/opsx:ff add-dark-modeينشئ جميع أدوات التخطيط دفعة واحدة. استخدمه عندما يكون لديك صورة واضحة لما تبنيه.
التنفيذ (الجزء المرن)
/opsx:applyيعمل على المهام، ويعلمها كمكتملة أثناء تقدمك. إذا كنت تتعامل مع تغييرات متعددة، يمكنك تشغيل /opsx:apply <name>؛ وإلا يجب أن يستنتج من المحادثة ويطلب منك الاختيار إذا لم يستطع التمييز.
الانتهاء
/opsx:archive # الانتقال إلى الأرشيف عند الانتهاء (يطلب مزامنة المواصفات إذا لزم الأمر)متى التحديث مقابل البدء من جديد
يمكنك دائمًا تعديل اقتراك أو مواصفاتك قبل التنفيذ. لكن متى يصبح التنقيح "هذا عمل مختلف"؟
ما يلتقطه الاقتراح
يحدد الاقتراح ثلاثة أشياء:
- النية — ما المشكلة التي تحلها؟
- النطاق — ما هو داخل/خارج الحدود؟
- النهج — كيف ستحلها؟
السؤال هو: أيهما تغير، وبأي درجة؟
تحديث التغيير الحالي عندما:
نفس النية، تنفيذ مُحسَّن
- تكتشف حالات حافة لم تفكر فيها
- النهج يحتاج تعديلًا لكن الهدف لم يتغير
- التنفيذ يكشف أن التصميم كان خاطئًا قليلاً
النطاق يضيق
- تدرك أن النطاق الكامل كبير جدًا، تريد إرسال MVP أولاً
- "إضافة الوضع الداكن" → "إضافة مفتاح الوضع الداكن (تفضيل النظام في الإصدار 2)"
تصحيحات مدفوعة بالتعلم
- قاعدة الكود ليست مهيأة كما ظننت
- تبعية لا تعمل كما هو متوقع
- "استخدام متغيرات CSS" → "استخدام بادئة dark: من Tailwind بدلاً من ذلك"
بدء تغيير جديد عندما:
النية تغيرت جوهريًا
- المشكلة نفسها مختلفة الآن
- "إضافة الوضع الداكن" → "إضافة نظام سمات شامل بألوان وخطوط ومسافات مخصصة"
النطاق اتسع
- التغيير نما كثيرًا以至于 أصبح عملًا مختلفًا جوهريًا
- الاقتراح الأصلي سيكون غير قابل للتعرف عليه بعد التحديثات
- "إصلاح خطأ تسجيل الدخول" → "إعادة كتابة نظام المصادقة"
الأصلي قابل للإنجاز
- يمكن وضع علامة "تم" على التغيير الأصلي
- العمل الجديد مستقل، وليس تنقيحًا
- إكمال "إضافة MVP الوضع الداكن" → أرشفة → تغيير جديد "تحسين الوضع الداكن"
القواعد الإرشادية
┌─────────────────────────────────────┐
│ هل هذا نفس العمل؟ │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
نفس النية؟ >50% تداخل؟ هل يمكن للأصلي
نفس المشكلة؟ نفس النطاق؟ أن يكون "مكتملًا" بدون
│ │ هذه التغييرات؟
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
نعم لا نعم لا لا نعم
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
تحديث جديد تحديث جديد تحديث جديد| الاختبار | تحديث | تغيير جديد |
|---|---|---|
| الهوية | "نفس الشيء، مُحسَّن" | "عمل مختلف" |
| تداخل النطاق | >50% تداخل | <50% تداخل |
| الإنجاز | لا يمكن أن يكون "مكتملًا" بدون تغييرات | يمكن إكمال الأصلي، العمل الجديد مستقل |
| القصة | سلسلة التحديثات تروي قصة متماسكة | الترقيع قد يُربك أكثر مما يوضح |
المبدأ
التحديث يحافظ على السياق. التغيير الجديد يوفر الوضوح.
اختر التحديث عندما يكون تاريخ تفكيرك ذا قيمة. اختر الجديد عندما يكون البدء من جديد أوضح من الترقيع.
فكّر فيه مثل فروع git:
- استمر في الالتزام أثناء العمل على نفس الميزة
- ابدأ فرعًا جديدًا عندما يكون عملًا جديدًا حقيقيًا
- أحيانًا ادمج ميزة جزئية وابدأ من جديد للمرحلة 2
ما الفرق؟
النظام القديم (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| الهيكل | مستند اقتراح واحد كبير | أجزاء منفصلة مع تبعيات |
| سير العمل | مراحل خطية: التخطيط → التنفيذ → الأرشفة | إجراءات مرنة — قم بأي شيء في أي وقت |
| التكرار | من الصعب العودة للخلف | تحديث الأجزاء أثناء التعلم |
| التخصيص | هيكل ثابت | مدفوع بالمخطط (حدد أجزاءك الخاصة) |
الفكرة الأساسية: العمل ليس خطيًا. OPSX يتوقف عن التظاهر بأنه كذلك.
تعمق في البنية
يشرح هذا القسم كيفية عمل OPSX من الداخل وكيف يقارن بسير العمل القديم. تستخدم الأمثلة في هذا القسم مجموعة الأوامر الموسعة (new، continue، إلخ)؛ يمكن لمستخدمي core الافتراضيين تعيين نفس التدفق إلى propose → apply → sync → archive.
الفلسفة: المراحل مقابل الإجراءات
┌─────────────────────────────────────────────────────────────────────────────┐
│ سير العمل القديم │
│ (مقيّد بالمراحل، الكل أو لا شيء) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ مرحلة │ ───► │ مرحلة │ ───► │ مرحلة │ │
│ │ التخطيط │ │ التنفيذ │ │ الأرشفة │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • يُنشئ جميع المصنوعات دفعة واحدة │
│ • لا يمكن العودة لتحديث المواصفات أثناء التنفيذ │
│ • بوابات المرحلة تفرض التقدم الخطي │ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ سير عمل OPSX │
│ (إجراءات سلسة، تكرارية) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ الإجراءات (ليست مراحل) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ بأي ترتيب │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • إنشاء المصنوعات واحدًا تلو الآخر أو التقدم السريع │
│ • تحديث المواصفات/التصميم/المهام أثناء التنفيذ │
│ • التبعيات تمكّن التقدم، لا توجد مراحل │ │
└─────────────────────────────────────────────────────────────────────────────┘بنية المكونات
سير العمل القديم يستخدم قوالب مبرمجة في TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ مكونات سير العمل القديم │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ قوالب مبرمجة (نصوص TypeScript) │
│ │ │
│ ▼ │
│ مُهيئات/محوّلات خاصة بالأداة │
│ │ │
│ ▼ │
│ ملفات الأوامر المُنشأة (.claude/commands/openspec/*.md) │
│ │
│ • بنية ثابتة، لا وعي بالمصنوعات │
│ • التغيير يتطلب تعديل الكود + إعادة البناء │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX يستخدم مخططات خارجية ومحرك رسم بياني للتبعيات:
┌─────────────────────────────────────────────────────────────────────────────┐
│ مكونات OPSX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ تعريفات المخطط (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── التبعيات │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── أنماط Glob │ │
│ │ requires: [proposal] ◄── يُمكّن بعد الاقتراح │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ محرك رسم المصنوعات البياني │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • الترتيب الطوبولوجي (ترتيب التبعيات) │ │
│ │ • كشف الحالة (وجود نظام الملفات) │ │
│ │ • توليد تعليمات غنية (قوالب + سياق) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ملفات المهارات (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • متوافقة عبر المحررات (Claude Code، Cursor، Windsurf) │
│ • المهارات تستعلم من واجهة سطر الأوامر للبيانات المنظمة │
│ • قابلة للتخصيص بالكامل عبر ملفات المخطط │
│ │
└─────────────────────────────────────────────────────────────────────────────┘نموذج الرسم البياني للتبعيات
تشكل المصنوعات رسمًا بيانيًا موجّهًا غير دوري (DAG). التبعيات هي مُمكِّنات، وليست بوابات:
proposal
(العقدة الجذرية)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requires: (requires:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requires:
specs, design)
│
▼
┌──────────────┐
│ APPLY PHASE │
│ (requires: │
│ tasks) │
└──────────────┘تحولات الحالة:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
تبعيات جميع التبعيات الملف موجود
مفقودة في حالة DONE على نظام الملفاتتدفق المعلومات
سير العمل القديم — الوكيل يتلقى تعليمات ثابتة:
المستخدم: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ تعليمات ثابتة: │
│ • إنشاء proposal.md │
│ • إنشاء tasks.md │
│ • إنشاء design.md │
│ • إنشاء specs/<capability>/spec.md │
│ │
│ لا وعي بما هو موجود أو │
│ التبعيات بين المصنوعات │
└─────────────────────────────────────────┘
│
▼
الوكيل يُنشئ جميع المصنوعات دفعة واحدةOPSX — الوكيل يستعلم للحصول على سياق غني:
المستخدم: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ الخطوة 1: الاستعلام عن الحالة الحالية │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── الأولى جاهزة │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ الخطوة 2: الحصول على تعليمات غنية للمصنوعة الجاهزة │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ الخطوة 3: قراءة التبعيات → إنشاء مصنوعة واحدة → إظهار ما تم فتحه │
└──────────────────────────────────────────────────────────────────────────┘نموذج التكرار
سير العمل القديم — من الصعب التكرار:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "لحظة، التصميم خاطئ"
│ │
│ ├── الخيارات:
│ │ • تحرير الملفات يدويًا (يكسر السياق)
│ │ • التخلي والبدء من جديد
│ │ • المتابعة والإصلاح لاحقًا
│ │
│ └── لا يوجد آلية رسمية "للعودة"
│
└── يُنشئ جميع المصنوعات دفعة واحدةOPSX — تكرار طبيعي:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "التصميم خاطئ"
│ │ │
│ │ ▼
│ │ فقط قم بتحرير design.md
│ │ واستمر!
│ │ │
│ │ ▼
│ │ /opsx:apply يلتقط
│ │ من حيث توقفت
│ │
│ └── يُنشئ مصنوعة واحدة، يُظهر ما تم فتحه
│
└── يُهيّئ التغيير، ينتظر التوجيهمخططات مخصصة
أنشئ سير عمل مخصصًا باستخدام أوامر إدارة المخططات:
bash
# إنشاء مخطط جديد من الصفر (تفاعلي)
openspec schema init my-workflow
# أو تفرع مخطط موجود كنقطة بداية
openspec schema fork spec-driven my-workflow
# التحقق من صحة بنية المخطط
openspec schema validate my-workflow
# الاطلاع على مصدر حل المخطط (مفيد للتصحيح)
openspec schema which my-workflowيتم تخزين المخططات في openspec/schemas/ (محلي للمشروع، خاضع للتحكم في الإصدارات) أو ~/.local/share/openspec/schemas/ (عام للمستخدم).
بنية المخطط:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdمثال schema.yaml:
yaml
name: research-first
artifacts:
- id: research # Added before proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Now depends on research
- id: tasks
generates: tasks.md
requires: [proposal]الرسم البياني للتبعيات:
research ──► proposal ──► tasksملخص
| الجانب | القديم | OPSX |
|---|---|---|
| القوالب | TypeScript مبرمجة | YAML خارجي + Markdown |
| التبعيات | لا يوجد (كل شيء دفعة واحدة) | DAG مع ترتيب طوبولوجي |
| الحالة | نموذج ذهني قائم على المراحل | وجود نظام الملفات |
| التخصيص | تعديل المصدر، إعادة البناء | إنشاء schema.yaml |
| التكرار | مقيّد بالمراحل | سلسل، تحرير أي شيء |
| دعم المحرر | مُهيئ/محوّل خاص بالأداة | دليل مهارات واحد |
المخططات
تحدد المخططات ما هي الأصناف الموجودة واعتمادياتها. المتاحة حالياً:
- مُدار بالمواصفات (افتراضي): اقتراح → مواصفات → تصميم → مهام
bash
# قائمة المخططات المتاحة
openspec schemas
# عرض جميع المخططات مع مصادر حلها
openspec schema which --all
# إنشاء مخطط جديد بشكل تفاعلي
openspec schema init my-workflow
# نسخ مخطط موجود للتخصيص
openspec schema fork spec-driven my-workflow
# التحقق من هيكل المخطط قبل الاستخدام
openspec schema validate my-workflowنصائح
- استخدم
/opsx:exploreللتفكير في فكرة قبل الالتزام بالتغيير /opsx:ffعندما تعرف ما تريده،/opsx:continueعند الاستكشاف- أثناء
/opsx:apply، إذا كان هناك خطأ — قم بإصلاح الصنف، ثم تابع - تتبع المهام التقدم عبر مربعات الاختيار في
tasks.md - تحقق من الحالة في أي وقت:
openspec status --change "name"
ملاحظات
هذا العمل مبدئي. هذا مقصود — نحن نتعلم ما يصلح.
هل وجدت خطأً؟ لديك أفكار؟ انضم إلينا على Discord أو افتح مشكلة على GitHub.