Task
نشط ومستقريعمل محلياً ✓بدون اشتراك APIاجمع أوامر الفحص والاختبار والبناء في Taskfile.yml، وشغّلها بأسماء واضحة مع ترتيب الخطوات أو تنفيذ المستقل منها بالتوازي.
brew install go-taskالاستخدام المثالي لهذه الأداة
تناسب مطورًا أو فريقًا صغيرًا تتوزع أوامر مشروعه بين لغات ومجلدات وأدوات مختلفة. توفر أسماء تشغيل موثقة يستطيع الإنسان والوكيل استخدامها ومراجعتها في Git. إذا كانت scripts الحالية تغطي احتياج مشروع بسيط، فقد لا تحتاج إضافة Task؛ وهي لا تثبت أدوات المشروع أو تعزل أوامره أمنيًا.
التفاصيل والميزات المصورة
كل مرة تفتح المشروع تحتاج أن تتذكر: بأي أمر تبدأ الواجهة؟ أين تشغّل الاختبارات؟ وهل البناء يأتي قبل الفحص أم بعده؟ Task يجمع هذه الخطوات في ملف Taskfile.yml بأسماء واضحة، فتكتب task check بدل إعادة تركيب سلسلة الأوامر في كل مرة. فائدته أكبر عندما يحتوي المشروع أكثر من لغة أو مجلد، أو يتناوب عليه شخص ووكيل برمجي؛ كلاهما يستطيع قراءة خطوات التشغيل نفسها ومراجعتها في Git.
🧭 ما Task وكيف يعمل؟
Task، من مشروع go-task، أداة مفتوحة المصدر لتشغيل أوامر التطوير والبناء. تكتب المهام في YAML، وهي صيغة نصية تصف أسماء المهام وإعداداتها، ثم تنفّذها من الطرفية. كل مهمة تستدعي الأوامر الموجودة لديك؛ مثل pnpm lint أو go test أو سكربت Python. Task لا يكتب هذه الأدوات ولا يثبت متطلبات مشروعك تلقائيًا.
يقرأ Task الملف، يحدد المهمة المطلوبة واعتمادياتها، ثم يشغّل الأوامر. تستطيع البدء بملف صغير، ثم تقسيمه إلى ملفات فرعية عند الحاجة. لا تحتاج خادمًا أو لوحة إدارة أو خدمة AI لتشغيله محليًا.

رسم توضيحي أصلي. الأسماء أمثلة، وليست لقطة من واجهة المنتج.
🎯 كيف يفيد مطورًا أو فريقًا صغيرًا؟
المشكلة التي يحلها هي اختلاف طريقة تشغيل العمل: شخص ينسى فحص التنسيق، وآخر ينفذ الاختبار من مجلد غير صحيح، ووكيل يبتكر سلسلة أوامر مختلفة. بوضع أسماء ثابتة مثل task check وtask build داخل المستودع، تصبح الخطوات قابلة للاكتشاف والمراجعة. وعندما تغير أداة الاختبار، تستطيع تعديل الأمر خلف الاسم نفسه.
هذه قيمة في تنظيم العمل، وليست ضمانًا لنجاح الاختبارات أو تطابق البيئات. إذا كانت كل حاجتك أمرين واضحين داخل package.json لمشروع JavaScript صغير، فقد تكون scripts الحالية كافية ولا تحتاج طبقة إضافية.
🌟 الميزات والقدرات الرئيسية
1. قائمة أوامر موثقة داخل المشروع
تعرّف المهمة تحت tasks، وتضع أوامرها في cmds ووصفها في desc. يعرض task --list المهام التي لها وصف؛ ويمكن أن يشرح task --summary check تفاصيل المهمة دون تنفيذ أوامرها. بذلك لا يحتاج المنضم للمشروع إلى البحث داخل محادثات قديمة لمعرفة اسم أمر الفحص.
- أين تجدها: داخل
Taskfile.ymlفي جذر المشروع. - كيف تستخدمها: أعطِ كل مهمة اسمًا ثابتًا ووصفًا يوضح أثرها، ثم اعرض القائمة قبل التنفيذ.
- مثال توضيحي: اسم
checkيجمع خطوات التحقق التي اتفق عليها الفريق، بينما تبقىbuildمهمة مستقلة للبناء فقط. - القيد:
--listلا يعرض المهام بلا وصف، والمهامinternalتبقى مخفية؛ لا تعتبر القائمة وحدها مراجعة شاملة للملف.

رسم يشرح العلاقة بين الاسم والأمر. أوامر pnpm تفترض وجود scripts مقابلة في المشروع.
2. ترتيب الخطوات أو تنفيذ المستقل منها بالتوازي
عندما تضع استدعاءات المهام تحت cmds، ينتظر Task نجاح الخطوة قبل بدء التالية. أما deps فتشغّل الاعتماديات بالتوازي، ثم تبدأ أوامر المهمة الأم بعد نجاحها جميعًا. ترتيب الأسماء داخل deps لا يحدد ترتيب التنفيذ.
- أين تجدها:
cmdsللتسلسل، وdepsللمتطلبات المستقلة. - كيف تستخدمها: اختر التسلسل عندما يستهلك الاختبار ملفات ينتجها البناء؛ واستخدم التوازي فقط إذا كانت المهام مستقلة ولا تتنافس على موارد مشتركة.
- مثال توضيحي: يمكن تشغيل lint واختبار مستقل معًا قبل البناء. أما lint ثم test ثم build فتكتبها كاستدعاءات تحت
cmds. - القيد: فشل اعتماد يمنع أوامر المهمة الأم، لكنه لا يتراجع عن تغييرات أنجزتها أوامر أخرى. ويمكن تحديد حد للتوازي باستخدام
--concurrencyدون أن يصبح ذلك ترتيبًا للاعتماديات.

رسم للعلاقات الموثقة؛ لا يَعِد بأن التوازي أسرع أو أخف على جهازك.
3. تجنّب إعادة العمل عندما لم تتغير مدخلاته
بإضافة sources لملفات الإدخال وgenerates لمسارات النتائج، يستطيع Task تخطي أوامر المهمة إذا لم تتغير المصادر وكانت النتائج المعلنة موجودة. الطريقة الافتراضية تقارن بصمة محتوى المصادر، وتتحقق من وجود النتائج؛ لا تقارن محتوى ملفات النتائج نفسها. هذه نقطة مهمة إذا عدّل برنامج آخر الناتج.
- أين تجدها: الحقول
sourcesوgeneratesوmethodداخل المهمة. - كيف تستخدمها: أدرج كل ما يؤثر في النتيجة، مثل ملفات المصدر والإعداد وملف قفل الاعتماديات. راجع الأنماط بعد إضافة مجلدات جديدة.
- مثال توضيحي: بناء ملف تنفيذي من مصادر Go، ثم تخطي البناء في التشغيل التالي إذا بقيت المصادر كما هي والناتج موجودًا.
- القيد: إغفال ملف مؤثر قد يجعل التخطي خاطئًا. الاعتماديات تُفحص أولًا حتى عندما تُتخطى أوامر المهمة الأم. تُحفظ البصمات عادة داخل
.task/.

رسم مبسط لآلية sources وgenerates، وليس قياس أداء أو تحققًا من سلامة الناتج.
🪜 مثال عملي: أمر واحد لفحص مشروع ويب
مثال توضيحي لم أنفذه على مشروع فعلي. نفترض أن لديك Node.js وpnpm، وأن package.json يحتوي scripts باسم lint وtest وbuild. أنشئ الملف التالي في جذر المشروع:
version: '3'
tasks:
lint:
desc: Check code style
cmds:
- pnpm lint
test:
desc: Run project tests
cmds:
- pnpm test
build:
desc: Build the application
cmds:
- pnpm build
check:
desc: Run lint, tests, and build in order
cmds:
- task: lint
- task: test
- task: build
ثم اتبع هذه الخطوات:
- اقرأ الملف وأوامر scripts التي يستدعيها؛ الاسم القصير لا يختصر أثر الأمر الحقيقي.
- اعرض قائمة المهام باستخدام
task --list. - اقرأ ملخص المسار باستخدام
task --summary check. - شغّل
task check. في هذا المثال يبدأ lint ثم الاختبار ثم البناء؛ فشل خطوة يمنع بدء الخطوات التالية. - راجع المخرجات الفعلية ورمز الخروج. نجاح Task يعني نجاح الأوامر بحسب رموز خروجها، ولا يثبت أن اختباراتك تغطي كل المطلوب.
- أضف الملف إلى مراجعة Git مع تغيير الأوامر مستقبلًا، حتى يرى الفريق والوكيل التعديل نفسه.
يمكن للوكيل الذي يملك صلاحية تشغيل الطرفية استخدام هذا المسار، لكنه لا يحصل من Task على صلاحيات جديدة. ربطه بالوكلاء هنا طريقة عمل، وليس إضافة AI رسمية أو موصل MCP مطلوبًا.
⚖️ ماذا يغيّر مقارنة بالعمل اليدوي؟
| قبل | مع Task |
|---|---|
| أوامر موزعة بين README وسكربتات ومحادثات | أسماء مهام وأوصافها بجوار الكود |
| كل شخص يعيد ترتيب الخطوات | ترتيب أو اعتماديات مصرح بها في الملف |
| الوكيل قد يستخدم سلسلة مختلفة | يمكن توجيهه إلى مهمة متفق عليها |
| إعادة بناء بلا قواعد لتغير الملفات | تخطٍ اختياري إذا ضُبطت المدخلات والنتائج بدقة |
Task لا يستبدل README أو أدوات الاختبار، ولا ينشئ بيئة متطابقة تلقائيًا. الأثر العملي هو تقليل اختلاف تعليمات التشغيل، دون نسبة توفير وقت غير مقاسة.
⚙️ الإعدادات والتوسع التدريجي
استخدم dir لتحديد مجلد تنفيذ المهمة وenv أو dotenv للقيم البيئية. كل سطر ضمن cmds له سياق shell منفصل؛ تنفيذ cd أو export في سطر لا ينتقل تلقائيًا إلى السطر التالي. لهذا يكون dir وenv أوضح من الاعتماد على حالة الطرفية.
عندما يكبر الملف، قسّمه باستخدام includes وأسماء نطاق مثل web:build وapi:test. انتبه إلى أن وضع الملف في مجلد فرعي لا يجعل ذلك المجلد وجهة التنفيذ تلقائيًا؛ اضبط dir للملف المضمّن عند الحاجة.
وضع المراقبة task --watch build يعيد النظر في المهمة عند تغير sources. لا تجعله بديلًا تلقائيًا لكل خادم تطوير؛ توثق الأداة مشكلة معروفة قد تُبقي بعض العمليات الأبناء حية في وضع المراقبة. ابدأ بتشغيل الفحوص التي تنتهي بدل برامج الخوادم الطويلة.
🚀 التثبيت والتوافق
على macOS مع Homebrew، الأمر الموثق:
brew install go-task
task --version
تتوفر طريقة npm الرسمية على macOS وLinux وWindows:
npm install -g @go-task/cli
وتوجد حزم وثنائيات لأنظمة ومعماريات متعددة. لا تحتاج تثبيت Go لاستخدام الثنائي الجاهز؛ البناء من المصدر له متطلبات Go منفصلة. أما أدوات المشروع مثل pnpm أو Docker أو Python فيجب أن تكون متاحة حيث تنفذ المهمة. دعم Task للأنظمة المختلفة لا يجعل كل أمر تكتبه محمولًا بينها.
يمكن استخدامه في GitHub Actions عبر إجراء الإعداد الرسمي go-task/setup-task@v2 ثم تشغيل المهمة نفسها. ثبّت إصدار Task المناسب في إعداد CI، وراجع إصدار الإجراء ومتطلبات مشروعك قبل دمجه. النسخة المستقرة التي تحققت منها v3.54.0؛ إصدار v3.55.0-nightly الظاهر يوم الفحص تجريبي وليس أساس هذه البطاقة.
💰 التكلفة والخصوصية والصلاحيات
الكود برخصة MIT، ولا يتطلب حسابًا أو اشتراك Task أو API مدفوعًا لتشغيل مهام محلية. تكلفة الحوسبة أو الخدمات التي تستدعيها الأوامر مستقلة عنه. ملفات YAML وبيانات البصمات محلية، لكن أوامرك تستطيع الاتصال بالشبكة أو نشر ملفات أو قراءة أسرار متاحة للعملية.
عامل Taskfile ككود قابل للتنفيذ. اقرأ الأوامر وincludes والمتغيرات الديناميكية قبل تشغيل ملف من مصدر آخر. خيار --dry يعرض الأوامر، لكنه ما زال يحل القوالب والمتغيرات؛ متغير يستخدم sh قد ينفذ أمرًا أثناء المعاينة. لذلك لا تعتبر المعاينة عزلًا أمنيًا.
تحميل Taskfile بعيد عبر HTTP أو Git ميزة منفصلة عن الاستخدام المحلي. راجع مصدره ومحتواه وثبّت مرجعًا أو checksum عند اعتماد ملف تمت مراجعته؛ لا تستخدم الموافقة العامة لتجاوز تغيراته بلا مراجعة. الإصدار v3.54.0 يتضمن إصلاحًا لمشكلة في كاش ملفات Git البعيدة على الأجهزة المشتركة. لم أُجرِ تدقيقًا أمنيًا مستقلًا للكود أو اختبارًا لحركة الشبكة، ولا أزعم انعدام الاتصالات في كل إعداد.
📚 المصادر وتاريخ التحقق
تحققت في 15 أكتوبر 2026 من المستودع الأصلي، الإصدار v3.54.0 الصادر في 1 أكتوبر 2026، رخصة MIT، والتثبيت الرسمي. تفاصيل تعريف المهام، التنفيذ والمعاينة، الاعتماديات، تخطي العمل، الملفات المضمّنة، المنصات، المراقبة، والملفات البعيدة من وثائق المشروع.
أظهر GitHub وقت الفحص نحو 16.3 ألف نجمة و928 تفرعًا. هذه أرقام انتشار متغيرة وليست تقييم مستخدمين أو شهادة جودة. لم أثبت الأداة أو أشغّل المثال. ظهرت أثناء الاكتشاف في GitHub Topics؛ وقورنت مع Lazygit من مجال إدارة Git، ثم اختيرت لتنويع الدليل نحو أتمتة أوامر المشروع. فهارس المهارات وسيلة اكتشاف، وليست مصدرًا لحقائق Task.