إدارة المهام في Claude Code: امنح وكيلك متتبّعًا حقيقيًا لا ملف Markdown

أغلقت جلسة Claude Code للتو بعد إنجاز ميزة. كتب الوكيل الكود، وشغّل الاختبارات، وترك ملف TODO.md في جذر المستودع وفيه ثلاثة بنود مكتملة وبندان في منتصف الطريق. غدًا تفتح جلسة جديدة، فلا يعرف الوكيل شيئًا مما جرى. الملف موجود، لكن لا أحد يراقبه. لم يصل إشعار إلى أحد. زميلك المسؤول عن واجهة API لم يعلم أن الترحيل صدر. وحين فُتحت نافذة Claude Code ثانية في المستودع نفسه، تسابقت العمليتان على ملف Markdown واحد في اللحظة ذاتها.

هذه هي الفجوة التي يتناولها هذا المقال. إدارة المهام في Claude Code تعمل جيدًا طوال محادثة واحدة. ملف Markdown، وتتبع TODO المدمج، ومسودة مؤقتة، كلها تصمد ما دامت نافذة السياق حاضرة. لكن لحظة انتهاء الجلسة، أو انضمام وكيل ثانٍ، أو حاجة إنسان إلى رؤية الحالة دون قراءة طرفيّتك، يتوقف الملف المسطّح عن كونه متتبّعًا ويتحول إلى ملاحظة نسيت إرسالها. هذه جولة فيما ينكسر، وما تجيده الأداة الملفية الأشهر (Task Master)، وكيف يغيّر منح وكيلك متتبّع مهام حقيقيًا عبر MCP شكل المشكلة من أساسه.

لماذا لا يصلح ملف Markdown لإدارة مهام Claude Code

ملف TODO.md بلا ذاكرة بين الجلسات، ولا يعرف من فعل ماذا، ولا يملك طريقة لإخبار إنسان «أنا عالق» ما لم يقرأ أحدهم الملف بنفسه. وهذه ليست ملاحظات هامشية، بل هي الوظائف الثلاث التي يؤديها المتتبّع فعلًا.

فكّر فيما تخسره حين يكون السجل الوحيد للعمل ملفًا في المستودع:

• لا حالة عابرة للجلسات. فهم الوكيل لما «أُنجز» يعيش في نافذة السياق. أغلق النافذة، وستعيد الجلسة التالية بناء ذلك الفهم من الصفر بإعادة قراءة الملف، هذا إن قرأته أصلًا.
• لا إسناد. قائمة تحقق في Markdown لا تستطيع أن تقول أي وكيل، أو أي إنسان، حرّك بندًا. حين تشغّل أكثر من وكيل، أو وكيلًا مع فريق، يصبح سؤال «من غيّر هذا؟» بلا جواب.
• لا إشعارات تصل إليك. الحالة قابعة في ملف. لكي يعلم أي أحد أن مهمة انتهت أو تعثّرت، عليه أن يذهب وينظر بنفسه. لا جرس، ولا بريد، ولا تدفق أحداث.
• التزامن خطر حقيقي. عمليتان تكتبان الملف نفسه وصفة جاهزة لكتابة ضائعة، وهذا بالضبط ما اضطر أنضج الأدوات الملفية إلى إضافة قفل بسببه (التفاصيل أدناه).

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

النسخة الجيدة من نهج الملفات: Task Master

قبل اقتراح بديل، من الإنصاف الاعتراف بأفضل أداة ملفية في فئتها، فهي جيدة فعلًا وواسعة الانتشار.

‏Task Master (مشروع claude-task-master، بنحو 27.9 ألف نجمة على GitHub كما في يوليو 2026) نظام إدارة مهام مدعوم بالذكاء الاصطناعي بُني لهذا السيناريو بالذات. تثبّته عالميًا بالأمر npm install -g task-master-ai، ثم تشغّل task-master init، فيضع مجلد .taskmaster/ في مستودعك. متطلباتك تذهب إلى .taskmaster/docs/prd.txt، والإعدادات في .taskmaster/config.json، وكل مهمة تعيش في ملف tasks.json واحد منظم بالوسوم. يأتي بخادم MCP خاص به حتى تستطيع Claude Code وCursor وWindsurf وVS Code قيادته جميعًا، ويستطيع مستخدمو Claude Code الاستغناء كليًا عن مفاتيح مزودي النماذج باستخدام مزود Claude Code CLI. رخصته MIT (مع بند Commons Clause، فلك حرية الاستخدام والتعديل لكن دون إعادة بيعه كخدمة).

ما يجيده Task Master هو الجزء الذي يسبق اللوحة: يستطيع تحليل مستند PRD وتوسيعه إلى شجرة مهام منظمة، مع التبعيات وحقل testStrategy لكل مهمة. هذه قدرة حقيقية لا يملكها Taskfolk، وإن كان تحويل مستند متطلبات إلى شبكة مهام هو حاجتك الأساسية، فـ Task Master الأداة الأفضل. بلا مواربة.

المثير في الأمر أن تصميمه نفسه يدلّك على موضع الحد. حقول المهمة في Task Master هي id وtitle وdescription وstatus وdependencies وpriority وdetails وtestStrategy وsubtasks. أعد قراءة القائمة: لا يوجد مُسند إليه، ولا أي حقل إسناد على الإطلاق. وليس هذا سهوًا، بل انعكاس لنموذج يعمل فيه وكيل واحد على ملف tasks.json واحد. وملاحظات إصدارات المشروع نفسها تصرّح بكلفة التزامن: الإصدار 0.40.1 حمل إصلاحًا وُصف بأنه «حالة تسابق عند كتابة عدة نوافذ Claude Code في tasks.json في آن واحد»، وأضاف قفل ملفات عابرًا للعمليات لمنع فقدان البيانات. الأداة أضافت الوسوم (منذ الإصدار 0.16.2، «Tagged Task Lists» لسياقات فروع أو بيئات منفصلة داخل الملف نفسه) ثم اضطرت إلى إضافة قفل. وكلاهما نموذج الملف وهو يئن تحت الوظائف الثلاث أعلاه بالضبط.

فالقرار إذن ليس «أداة جيدة مقابل أداة سيئة»، بل «أي نموذج يناسب العمل الذي أمامي».

النموذجان وجهًا لوجه

هذه المقارنة الصريحة، وحقائق الطرف الآخر فيها مأخوذة حصرًا من وثائق كل مشروع كما هي في يوليو 2026.

	Task Master (ملفي)	Taskfolk (متتبّع عبر MCP)
أين تعيش المهام	.taskmaster/tasks.json داخل المستودع	قاعدة بيانات خلف مساحة العمل
الحالة بين الجلسات	تُقرأ من الملف في كل جلسة	دائمة؛ المتتبّع هو مصدر الحقيقة
الإسناد	لا حقل مُسند إليه في بنية المهمة	الوكلاء أعضاء حقيقيون؛ كل كتابة منسوبة
كتابة عدة وكلاء	قفل ملفات عابر للعمليات (أُضيف في 0.40.1)	على الخادم؛ الكتابات المتزامنة أمر طبيعي
رؤية البشر	افتح الملف أو المحرر	إشعارات داخل التطبيق، وبريد، وعروض اللوحة
تحويل PRD إلى مهام	نعم، parse-prd يوسّع مستندًا إلى شجرة مهام	لا مسار لتحليل PRD (توجد مساعدة ذكاء اصطناعي مقيدة بالرصيد)
يشغّل الوكيل	لا (يقوده عبر MCP)	لا (يبقى Claude Code يعمل على جهازك)
الإعداد	ملف يوضع ومجلد يُهيأ	يحتاج مساحة عمل ومفتاح API محدود الصلاحيات
التكلفة	MIT مع Commons Clause، مجاني	خطة مجانية؛ Pro بـ 3 دولارات لكل منفّذ شهريًا كما في يوليو 2026

لا أحد من الاثنين يشغّل وكيلك. Task Master لا ينفّذ Claude Code، وTaskfolk لا يفعل ذلك أيضًا. يبقى Claude Code يعمل على جهازك أو في CI؛ المتتبّع هو المكان الذي يرفع إليه تقاريره. ثبّت هذه النقطة، فهي أكثر ما يُساء فهمه.

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

منح Claude Code متتبّعًا حقيقيًا عبر MCP

هذا هو النموذج الذهني لنهج المتتبّع:

flowchart LR
  A[Claude Code] -->|MCP over HTTP| B[Taskfolk tracker]
  B --> C[Issues and board]
  B --> D[Agent sessions]
  D --> E[Human notifications]
  A -->|heartbeat| D

يتحدث Claude Code إلى Taskfolk عبر MCP. يصبح الوكيل عضوًا حقيقيًا في مساحة العمل، يقرأ التذاكر ويكتبها، ويبلّغ عن عمله كجلسة يستطيع البشر متابعتها. لا شيء يتغير في طريقة تشغيل Claude Code. ما يتغير أن سجل العمل صار يعيش في مكان دائم ومنسوب وقابل للمراقبة.

الربط أمر واحد. المنتج يعرض لك هذا السطر بعينه في نافذة ربط الوكيل وفي تبويب Developer > Skills، مع مفتاح جديد محدود الصلاحيات معبأ مسبقًا:

claude mcp add taskfolk-product https://your-site/api/mcp/v1 \
  --header "Authorization: Bearer YOUR_API_KEY"

// Or wire it into an mcp.json for Cursor / Windsurf / VS Code:
{
  "mcpServers": {
    "taskfolk-product": {
      "url": "https://your-site/api/mcp/v1",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

# Or hit the same REST surface directly from a runner:
import requests
requests.get(
    "https://your-site/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    params={"state": "review"},  # which agents are ready for review
)

خادم MCP يعيش على POST /api/mcp/v1 (بأسلوب Streamable HTTP، مع GET لإشعارات SSE) ويستوثق بمفتاح API نفسه الذي تستخدمه واجهة REST. والخاصية الجميلة تحت الغطاء: نداء tools/call في MCP يدخل من جديد إلى مسار REST داخل العملية نفسها، فلا توجد نسخة ثانية من الاستيثاق أو النطاقات أو حدود المعدل يمكن أن تنحرف مع الوقت. كل واحدة من عمليات REST v1 المسجلة، وعددها 155، تصبح أداة MCP بصيغة snake_case، وقائمة tools/list تُرشَّح وفق نطاقات مفتاحك، فلا يرى الوكيل إلا الأدوات المسموح له باستخدامها. إن أردت المقارنة الكاملة بين الصيغتين، كتبناها في MCP أم REST لوكيلك؛ والخلاصة أن MCP هو طريق Claude Code، وواجهة REST حاضرة حين تحتاج HTTP خامًا. شرح الربط خطوة بخطوة تجده في كيف تربط وكيل ذكاء اصطناعي، وطريق ملف المهارة (وضع SKILL.md في ~/.claude/skills/) مغطى في تثبيت Taskfolk كمهارة وكيل.

الجلسات: القطعة التي لا يمكن لملف Markdown امتلاكها

هذا هو الجزء الذي يجيب فعلًا عن الوظائف الثلاث المذكورة في المقدمة، فهو يستحق التمهل.

حين يبدأ الوكيل العمل، يفتح جلسة. والجلسة سجل صغير: عنوان، والتذكرة التي يعمل عليها، وملاحظة تقدم اختيارية، ورابط (رابط PR عادةً). ينشئها الوكيل بنداء واحد:

curl -X POST https://your-site/api/v1/workspaces/acme/agent-sessions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Fix login redirect","issue_key":"WEB-42","note":"reproducing"}'

await fetch("https://your-site/api/v1/workspaces/acme/agent-sessions", {
  method: "POST",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    title: "Fix login redirect",
    issue_key: "WEB-42",
    note: "reproducing",
  }),
});

import requests
requests.post(
    "https://your-site/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"title": "Fix login redirect", "issue_key": "WEB-42", "note": "reproducing"},
)

والاستجابة هي مورد الجلسة:

{
  "id": "0198f2a1-7c3e-7b41-9d2a-1c4e5f6a7b88",
  "agent_id": "0198f29c-4a11-7c02-8e3d-9b2c1a0f5d44",
  "state": "running",
  "title": "Fix login redirect",
  "note": "reproducing",
  "external_url": null,
  "issue_key": "WEB-42",
  "started_at": "2026-07-16T09:14:22.000Z",
  "last_activity_at": "2026-07-16T09:14:22.000Z",
  "ended_at": null
}

من هنا، كل PATCH على تلك الجلسة نبضة حياة. تحدّث last_activity_at، ويمكن أن تحمل ملاحظة تقدم جديدة، أو تغيير حالة، أو رابط PR في external_url حين يجهز العمل. تمر الجلسة بمجموعة صغيرة من الحالات: pending وrunning وneeds_input وreview وdone وfailed وcancelled. والحالات done وfailed وcancelled نهائية (تسجّل وقت انتهاء). جلسة running لم ترسل نبضة منذ 30 دقيقة تظهر متوقفة، وهذا يُشتق عند القراءة لا يُكتب في قاعدة البيانات، فالوكيل المنهار يظهر متجمدًا من تلقاء نفسه.

الآن اكتملت الوظائف الثلاث. الحالة تبقى لأنها تعيش في المتتبّع. والإسناد مدمج لأن الجلسة تخص وكيلًا هو عضو حقيقي. والبشر يصلهم الخبر: حين تدخل الجلسة حالة needs_input أو review أو done أو failed، يوزّع Taskfolk إشعارات داخل التطبيق على مالك الوكيل وعلى مُبلّغ التذكرة والمُسند إليه ومتابعيها. لا أحد يحتاج إلى فتح ملف ليعلم أن الوكيل عالق. وهناك أيضًا تدفق SSE لكل وكيل (GET /api/v1/workspaces/acme/agent-events) يدفع الإسنادات والإشارات وتغيّرات حالة الجلسات إلى بيئة تشغيل الوكيل، فتدور الحلقة في الاتجاهين.

تفصيلة واحدة تغلق حلقة تتركها الأدوات الملفية مفتوحة: إذا أسندت تذكرة إلى وكيل، ينشئ Taskfolk تلقائيًا جلسة pending على تلك التذكرة. وحين ينشر الوكيل لاحقًا جلسته لمفتاح التذكرة نفسه، فإنه يطالب بالصف المعلّق بدل إنشاء نسخة مكررة، فيعرض المركز خطًا زمنيًا متصلًا واحدًا من «فوّض إنسان هذا العمل» إلى «أنهى الوكيل». التفويضات التي لا يطالب بها أحد تبقى معلّقة حتى 7 أيام، ثم يلغيها عامل الخلفية. هذا التسليم كله مغطى في تفويض العمل إلى وكيل.

حواجز أمان لا يستطيع ملف فرضها

قائمة تحقق في Markdown تثق بمن يمسك القلم. أما المتتبّع فيستطيع تقييد ما يُسمح للوكيل بلمسه، وهذا يزداد أهمية كثيرًا حين يكتب الوكيل في حالة مشتركة.

لدى Taskfolk صلاحيات حقول لكل وكيل (field_policy_json)، وهي قائمة سماح على 14 رمز حقل تذكرة: title وdescription وstatus وpriority وassignee وlabels وmilestone وsprint وrelease وestimate وspent وcompletion وstart_at وdue_at. السياسة الفارغة (null) تعني أن الوكيل يكتب في كل الحقول. والسياسة الضيقة تعني أنه لا يستطيع مثلًا إعادة إسناد العمل أو تغيير إصدار حتى وإن كان يستطيع نقل الحالة وإضافة تسميات. القاعدة تُفرض عند نقطة الكتابة الوحيدة في API التي تغطي REST والانتقالات وMCP معًا، فلا باب خلفيًا يتجاوز فيه مسار ما الفحص.

لكن لنكن صادقين حول شكل هذا الحاجز. هو على مستوى الحقل لا القيمة (لا يستطيع أن يقول «حدد الأولوية على منخفضة فقط»)، ويغطي حقول التذاكر وحدها، ويقيّد مفتاح الوكيل نفسه لا حساب مدير. أما الإنشاء والحذف والموارد غير التذاكر فتحكمها نطاقات API مع الأدوار. إنه سياج له معنى، لا صندوق رمل.

وهناك حاجز ثانٍ يستحق الذكر لأنه يعترف بحدوده. جلسة review أو done بلا أي نشاط أو تعليق منسوب على تذكرتها تحصل على شارة «غير موثّقة»، تُشتق عند القراءة. وهي اختبار مبدئي مفيد: وكيل يدّعي الإنجاز دون أن يترك أثرًا على التذكرة يُعلَّم فورًا. لكن ما لا تستطيعه الشارة هو إثبات أن عمل الكود حدث فعلًا. Taskfolk متتبّع لا مشغّل، فحالات الجلسات ونبضاتها يبلّغ عنها الوكيل نفسه عبر API. شارة «غير موثّقة» تلتقط التناقض الواضح؛ لكنها لا تتحقق من الفرق البرمجي نفسه. هذه الصراحة هي المقصد، ومراجعة الإنسان تبقى حيث يجب أن تكون، وهو ما نغطيه في موافقة الإنسان في الحلقة لوكلاء الذكاء الاصطناعي.

ثمرة الانتقال من الملف أن هذا كله يصل إلى لوحة حقيقية يعرف البشر قراءتها أصلًا. مهام الوكيل تذاكر، في أعمدة، بالعروض نفسها التي يستخدمها الإنسان.

متى تُبقي على الملف، ومتى تحتاج متتبّعًا

دليل قرار مختصر، لأن الجواب الصادق «حسب الحالة».

وضعك	الأنسب لك
وكيل واحد، مستودع واحد، جلسة واحدة، عمل محدود	ملف Markdown أو Task Master
تحتاج توسيع PRD إلى شجرة مهام	Task Master (parse-prd)
العمل يجب أن يبقى بين الجلسات	متتبّع
البشر يحتاجون رؤية الحالة دون طرفيّتك	متتبّع
أكثر من وكيل يكتب في حالة مشتركة	متتبّع
تريد حدود كتابة وإسنادًا لكل وكيل	متتبّع
بلا حساب، بلا إعداد، ودون اتصال	ملف

كلفة الإعداد هي المقايضة الحقيقية. الملف مجاني وفوري. المتتبّع يحتاج مساحة عمل ومفتاح API بنطاقي agents:read وagents:write، وهذا أكثر من وضع JSON في مستودع حتى وإن كان الربط نفسه أمرًا واحدًا. الخطة المجانية في Taskfolk تغطي الكثير (5 مشاريع نشطة، و128 ميغابايت مساحة تخزين، و1 ميغابايت للملف الواحد، و25 من رصيد الذكاء الاصطناعي شهريًا، والسبرنتات والجدول الزمني والتكاملات والتقارير والذكاء الاصطناعي كلها مشمولة)، وخطة Pro بـ 3 دولارات لكل منفّذ شهريًا كما في يوليو 2026، مع بقاء الوكلاء والمشاهدين مقاعد مجانية دائمًا. أما الأتمتة والأدوار المخصصة وSSO وسجل التدقيق فعلى الخطط المدفوعة. الاستيثاق بالرابط السحري فقط (بلا كلمات مرور)، والمنتج كله ثنائي اللغة بالإنجليزية والعربية مع دعم RTL كامل إن كان هذا يهم فريقك.

إن بلغتَ النقطة التي صار فيها ملف TODO.md لوكيلك يفقد العمل بصمت بين الجلسات، فهذه هي إشارتك لمنحه متتبّعًا. اربط Claude Code بسطر claude mcp add واحد ودع الجلسات تحمل الحالة التي عجز ملفك عن حملها.