إدارة المهام في Cursor: امنح الوكيل لوحة مشتركة عبر MCP

افتح مشروعًا في Cursor اليوم واطلب من وكيله أن يخطط لميزة، وستجد أن إدارة المهام في Cursor تعني عادةً أحد أمرين: إما أنك ثبّت Task Master فصار يكتب المهام في مجلد .taskmaster/، أو أنك كتبت بيدك ملف .cursor/rules بموجّه يجعل الوكيل مديرًا ومنفذًا في آن، ويحتفظ بقائمة جارية داخل المستودع. الطريقتان تعملان. والطريقتان تعيشان في فرع على جهازك. والطريقتان تنهاران في اللحظة التي يحتاج فيها زميل أو مدير منتج أو وكيل ثانٍ إلى معرفة ما يفعله الوكيل فعلًا، لأن المهام ملف لم يسحبه أحد غيرك.

ما يريده معظم من يبحث عن "إدارة المهام في Cursor" ليس ملف JSON أفضل، بل أن يتتبع وكيل Cursor عمله في مكان يبقى ويستطيع الآخرون مراقبته. خلاصة هذا المقال من أوله: اربط Cursor بمتتبع حقيقي عبر MCP، فيقرأ الوكيل المهام من لوحة مشتركة، ويستلم العمل الذي فوضته إليه، ويبلغ عن جلساته في مكان يستطيع البشر مراجعته. يبقى الوكيل يعمل داخل Cursor، وتعيش اللوحة حيث يراها الجميع.

ماذا يستخدم مطورو Cursor لإدارة المهام اليوم

لنكن منصفين مع الوضع القائم، فهو جيد فعلًا.

الأداة المهيمنة هي Task Master AI (مشروع claude-task-master، بنحو 27,900 نجمة على GitHub حتى يوليو 2026). يعرّف نفسه بأنه "نظام إدارة مهام مدعوم بالذكاء الاصطناعي يمكنك إسقاطه في Cursor وLovable وWindsurf وRoo وغيرها". تثبّته بالأمر npm install -g task-master-ai، ثم تشغّل task-master init --rules cursor، فيربط نفسه بـ Cursor بطريقتين: مجموعة قواعد .cursor/rules تعلّم الوكيل كيف يتعامل مع المهام، وخادم MCP يعرض عمليات المهام كأدوات قابلة للاستدعاء. وجّهه إلى مستند متطلبات تضعه في .taskmaster/docs/prd.txt فيحلله إلى قائمة مهام يستطيع الوكيل الاختيار منها وتوسيعها ووضع علامة الإنجاز عليها.

تعرض الأداة عملياتها كأدوات MCP بثلاثة أحجام كي توازن بين القدرة وميزانية السياق: Core (7 أدوات، نحو 5,000 توكن)، وStandard (15 أداة، نحو 10,000 توكن)، وAll (36 أداة، نحو 21,000 توكن)، وتختار بينها عبر إعداد TASK_MASTER_TOOLS. الترخيص MIT مع بند Commons Clause: مجاني للاستخدام الشخصي والتجاري والأكاديمي، لكن لا يجوز لك إعادة بيعه ولا تشغيله كخدمة مستضافة. ويحتاج إلى مفتاح API واحد على الأقل من مفاتيح نماذجك (Anthropic أو OpenAI أو Gemini وغيرها)، إلا حين تشغّله عبر Claude Code أو Codex CLI بمصادقة OAuth، فلا يلزم عندها مفتاح منفصل.

وخارج Task Master، تتجاوز فرق كثيرة الأداة كلها وتبني الحل بيدها: ملف .cursor/rules يعرّف نمط مخطِّط ثم منفِّذ، ويحتفظ الوكيل بقائمته في ملف markdown أو JSON داخل المستودع. حل أخشن، لكنه بلا أي اعتماد خارجي.

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

أين ينكسر النموذج الملفي: البقاء ورؤية الفريق

المشكلة ليست أن Task Master سيئ، بل أن خاصيتين لم يُصمم لامتلاكهما تصبحان مهمتين لحظة يدخل أكثر من شخص أو أكثر من وكيل. Task Master محلي المستودع بالتصميم، ولهذا التصميم نتيجتان.

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

الثانية: رؤية الفريق. لا يستطيع مدير المنتج فتح لوحة ليرى ما يفعله الوكيل. ولا يستطيع زميل أن يلقي نظرة على عمود فيعرف أن الوكيل التقط إعادة هيكلة المصادقة قبل ساعة وما زال عليها. لا وجهة مشتركة تعيش فيها تلك الحالة. المعلومة موجودة، لكن داخل محرر شخص واحد فقط، وبصيغة ملف صُممت للوكيل لا لإنسان يتصفح التقدم.

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

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

يتحدث Cursor لغة MCP أصلًا، فالفجوة في الوجهة

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

‏Cursor يدعم MCP دعمًا أصيلًا، لا دعمًا جزئيًا. توثيقه يضع علامة "مدعوم" على الأدوات والموارد معًا، ويتعامل مع نواقل stdio وSSE وStreamable HTTP، ويعمل ناقلا SSE وStreamable HTTP مع الخوادم المحلية أو البعيدة ومع مستخدمين متعددين. تضبط خوادم MCP في .cursor/mcp.json داخل المشروع، أو في ~/.cursor/mcp.json على مستوى الجهاز كله. فالمتتبع البعيد القائم على HTTP في الطرف الآخر من اتصال MCP يقع تمامًا ضمن ما يفعله Cursor جاهزًا من اليوم الأول. الناقل موجود.

والتحفظ الصادق بلا مواربة: MCP في Cursor ميزة للخطط المدفوعة. حتى يوليو 2026، يظهر دعم MCP (إلى جانب skills وhooks وCloud Agents) ضمن ما تضيفه خطة Pro فوق فئة Hobby المجانية. وأسعار Cursor حتى يوليو 2026: Hobby مجانية (بلا بطاقة، مع طلبات Agent وإكمالات Tab محدودة)، وPro بـ 20 دولارًا شهريًا، وPro+ بـ 60 دولارًا شهريًا، وUltra بـ 200 دولار شهريًا، وTeams بـ 40 دولارًا لكل مستخدم شهريًا، مع خصم 20% على الفوترة السنوية. إن كنت على خطة Hobby المجانية فلن تستطيع توصيل MCP إطلاقًا. هذه بوابة حقيقية، واعرفها قبل أن تبني خطتك حولها.

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

ماذا تطلب في متتبع يكتب فيه الوكيل

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

1. نقطة MCP تتشارك المصادقة مع REST API، بأدوات لا تنجرف. لا تريد مجموعة أدوات MCP تُصان يدويًا وتتخلف عن الـ API الحقيقي. يقدّم Taskfolk خادم MCP رسميًا على POST /api/mcp/v1 عبر Streamable HTTP (بصيغة JSON-RPC 2.0)، بمصادقة مفتاح API الحامل (bearer) نفسه المستخدم في واجهة REST. كل استدعاء tools/call يعيد الدخول إلى خط REST داخل العملية نفسها، فلا يضيف MCP أي منطق موازٍ للمصادقة أو النطاقات أو حدود المعدل. كتالوج الأدوات يولَّد آليًا بأداة لكل عملية REST من سجل OpenAPI، فلا تنجرف أدوات الوكيل عن الـ API أبدًا، وتُرشَّح نتيجة tools/list حسب نطاقات المفتاح. وتعرض واجهة v1 في REST أكثر من 180 مسار عملية، فمجموعة الأدوات واسعة لكنها مشتقة آليًا، لا منسقة يدويًا.

2. الوكيل عضو حقيقي يُنسب إليه عمله، لا سكربت مجهول. حين يحرك الوكيل تذكرة، تريد اسمًا عليها. الوكيل المتصل في Taskfolk عضو حقيقي في مساحة العمل (users.is_agent) له ملف تعريف ومفتاح API منشئه هو مستخدم الوكيل نفسه. هذه الملكية هي الإسناد: يعود النشاط إلى الوكيل، لا إلى حساب خدمة مشترك.

3. الوكلاء لا يستهلكون مقاعد مدفوعة. أن تحاسِب على الوكيل كما تحاسِب على الإنسان يقتل الفكرة كلها. دالة countEditorSeats في Taskfolk تستبعد الوكلاء (eq(isAgent, 0))، فلا يُحاسَب الوكيل المتصل على مقعد منفّذ أبدًا، بخلاف المنفّذ البشري.

4. دورة حياة للجلسات يستطيع البشر مراقبتها. تريد أن ترى الوكيل يتنقل بين الحالات، لا أن تخمّن. يمثّل Taskfolk الجلسات كآلة حالات حقيقية: pending وrunning وneeds_input وreview وdone وfailed وcancelled. والجلسة الجارية بلا نبضة اتصال لمدة 30 دقيقة تُعرض متوقفة، وتُشتق هذه الحالة عند القراءة، فالوكيل الذي مات بصمت يظهر متوقفًا بدل أن يبدو مشغولًا إلى الأبد.

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

6. طريقة لرصد جلسة تدّعي الإنجاز بلا شيء تعرضه. يبلّغ الوكلاء أحيانًا عن الإكمال دون أن ينتجوا شيئًا. يشتق Taskfolk عند القراءة شارة "غير موثَّق" تعلّم أي جلسة في review أو done بلا نشاط منسوب ولا تعليق على مهمتها، فيظهر "الإنجاز" الفارغ أمام البشر بدل أن يمر بصمت.

لا شيء من هذا غريب. هو فقط الفرق بين "الوكيل يحرر ملفًا" و"الوكيل يشارك في اللوحة التي يستخدمها فريقك أصلًا".

المقارنة الصادقة: Task Master مقابل لوحة مشتركة عبر MCP

إليك القرار مبسوطًا. كل واقعة أدناه من البحث، والأسعار والحدود مذكورة كما هي حتى يوليو 2026.

	Task Master (داخل Cursor)	لوحة مشتركة عبر MCP (Taskfolk)
أين تعيش الحالة	مجلد .taskmaster/ محلي داخل المستودع	مساحة عمل مستضافة، على الخادم
مرئي للفريق	لا، هو ملف في فرع	نعم، يفتح البشر اللوحة
استلام العمل بين وكلاء متعددين	لا استلام مشتركًا، كلٌّ يقرأ ملفاته المحلية	جلسة pending تُستلم عند البدء
ناقل MCP	نعم (خادم MCP + قواعد .cursor/rules)	نعم (POST /api/mcp/v1 عبر Streamable HTTP)
الإسناد	ملفي، بلا هوية عضو	عضو is_agent، والإسناد عبر ملكية المفتاح
نموذج التكلفة	مجاني، بمفاتيح نماذجك	خطة مجانية للبشر، الوكلاء مجانًا، مقعد المنفّذ 3 دولارات في Pro و6 دولارات في Business شهريًا
الترخيص	MIT مع Commons Clause، مفتوح المصدر	SaaS مستضاف
الأنسب له	مطور يعمل وحده، مهام داخل المستودع، صفر اعتماد خارجي	فريق مع بشر يراجعون الوكلاء

والحكم بوضوح: Task Master هو الأداة الصحيحة إن كنت مطورًا تعمل وحدك وتريد مهامك داخل المستودع بلا اعتماد خارجي ولا حساب تديره. مجاني ومفتوح المصدر ويؤدي هذه المهمة جيدًا. وتفوز اللوحة المشتركة حين يحتاج إنسان أو وكيل ثانٍ إلى رؤية العمل ومراجعته، لا حين يحتاج الوكيل إلى مسودة يخربش فيها فحسب. وظيفتان مختلفتان. اختر بناءً على سؤال واحد: هل يحتاج أحد غير الوكيل إلى المراقبة؟

اربط Cursor باللوحة بملف إعداد واحد

التوصيل كله ملف واحد. تولّد تبويبة Skills في Taskfolk كتلة جاهزة للصقها في ~/.cursor/mcp.json:

{
  "mcpServers": {
    "taskfolk-product": {
      "url": "https://taskfolk.ai/api/mcp/v1",
      "headers": {
        "Authorization": "Bearer <your-api-key>"
      }
    }
  }
}

في تبويبة Skills تلك، يظهر Cursor خيارًا أساسيًا إلى جانب Claude Code وClaude Desktop وVS Code وCodex وopencode وإعداد MCP عام وOpenAPI خام، فتنسخ نسخة Cursor بدل ترجمة مثال عام. وCursor أيضًا نوع وكيل أساسي في مركز الوكلاء بشعاره الخاص، فيُعرف وكيل Cursor المتصل بوصفه Cursor لا روبوتًا عامًا.

ملاحظتان عمليتان. تسجّل الدخول إلى Taskfolk بالرابط السحري (بلا كلمات مرور)، ويأتي مفتاح API من منطقة المطورين، مقيدًا بالنطاقات التي تريد للوكيل أن يلمسها. ولنكن دقيقين في ماهية هذا الاتصال: هو لوحة مشتركة يقرأ فيها الوكيل ويكتب عبر MCP. لا يشغّل Taskfolk وكيل Cursor عندك، بل يعمل الوكيل داخل Cursor كما كان دائمًا. Taskfolk هو الوجهة في الطرف الآخر من اتصال MCP، لا مضيفًا للنموذج.

ما يفعله الوكيل فعلًا: يقرأ المهام ويستلم العمل ويبلغ عن الجلسات

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

التفويض هو الجزء الجميل. حين تسند مهمة إلى الوكيل، ينشئ Taskfolk تلقائيًا جلسة pending لها. لا يدخل الوكيل حالة pending بنفسه أبدًا، بل يغادرها فقط: استدعاء startAgentSession يستلم ذلك الصف المعلق ويقلبه إلى running بدل إنشاء نسخة مكررة. وهكذا يصبح "أسنِد التذكرة إلى الوكيل" و"يلتقطها الوكيل" نصفي الجلسة نفسها، لا سجلين متنافسين. وتُلغي جولة العامل الدورية تلقائيًا الجلسات المعلقة التي لم يستلمها الوكيل، فلا يبقى تفويض متجاهَل جاثمًا في المركز إلى الأبد.

أولًا، اسرد المهام التي ينبغي للوكيل النظر فيها (هنا: كل ما هو حاليًا في حالة قيد التنفيذ في مشروع WEB ومسند إلى الوكيل المستدعي):

curl "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues?status=in_progress&assignee=me" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY"

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues?status=in_progress&assignee=me",
  { headers: { Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}` } },
);
const issues = await res.json();

import os, requests
res = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues",
    params={"status": "in_progress", "assignee": "me"},
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
)
issues = res.json()

الاستجابة قائمة بسيطة من موارد المهام:

{
  "data": [
    {
      "id": "018f...c2",
      "key": "WEB-142",
      "url": "https://taskfolk.ai/w/acme/p/web/WEB-142",
      "type": "task",
      "title": "Refactor auth token refresh",
      "status": "in_progress",
      "status_name": "In progress",
      "priority": "high",
      "assignees": ["018f...ab"]
    }
  ]
}

ثم يستلم الوكيل جلسته المفوضة ويبدأ العمل. بدء جلسة على المهمة يستلم صف pending الذي أنشئ عند الإسناد:

curl -X POST "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Refactor auth token refresh","issue_key":"WEB-142"}'

const start = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ title: "Refactor auth token refresh", issue_key: "WEB-142" }),
  },
);
const session = await start.json();

start = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={"title": "Refactor auth token refresh", "issue_key": "WEB-142"},
)
session = start.json()

تعود الجلسة في حالة running، حاملة هوية الوكيل والمهمة المرتبطة بها:

{
  "data": {
    "id": "018f...9d",
    "agent_id": "018f...ab",
    "agent_name": "Cursor agent",
    "agent_kind": "cursor",
    "state": "running",
    "title": "Refactor auth token refresh",
    "note": null,
    "external_url": null,
    "issue_id": "018f...c2",
    "issue_key": "WEB-142",
    "started_at": "2026-07-16T09:12:04.000Z",
    "last_activity_at": "2026-07-16T09:12:04.000Z",
    "ended_at": null
  }
}

وعند اكتمال العمل، يرسل الوكيل طلب PATCH ينقل الجلسة إلى حالة نهائية ويضع رابط طلب السحب في external_url. ضبط state على قيمة نهائية مثل review أو done أو failed يختم ended_at، والدخول في needs_input أو review أو done أو failed يخطر البشر داخل التطبيق (مالك الوكيل، مع مبلّغ المهمة والمُسند إليه ومراقبيها):

curl -X PATCH "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/018f...9d" \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"review","external_url":"https://github.com/acme/web/pull/318"}'

await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/018f...9d",
  {
    method: "PATCH",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      state: "review",
      external_url: "https://github.com/acme/web/pull/318",
    }),
  },
);

requests.patch(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/018f...9d",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={"state": "review", "external_url": "https://github.com/acme/web/pull/318"},
)

ودورة حياة الجلسة من أولها إلى آخرها:

flowchart LR
  A[assigned: pending] --> B[running]
  B --> C[needs_input]
  C --> B
  B --> D[review]
  B --> E[done]
  B --> F[failed]
  D --> E

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

نقطة تستحق الدقة كي لا تبني خطتك على ميزة غير موجودة: التحديث اللحظي يذهب إلى بث SSE داخل التطبيق نفسه، للبشر الذين يراقبون اللوحة. لا يعود شيء إلى Cursor عبر MCP. خادم MCP في Taskfolk يعلن listChanged: false، ولا يملك إشعارات يبدؤها الخادم في v1، فقناة SSE على GET /api/mcp/v1 مجرد إبقاء للاتصال، لا بث حي إلى المحرر. يعرف الوكيل بالعمل الجديد بالسؤال (سرد مهامه)، كما يفعل أي عميل يستطلع دوريًا. البشر يتلقون التحديثات لحظيًا، والوكيل يسحب.

متى تبقى على النموذج الملفي (ومتى لا)

لن أقول لك بدّل إن كان لا ينبغي لك التبديل.

ابقَ مع Task Master أو مع إعداد .cursor/rules إن كنت تعمل وحدك، في مستودع واحد، وتريد صفر اعتماد خارجي، ولا أحد غيرك يحتاج إلى مراقبة الوكيل. الأداة مجانية ومفتوحة المصدر (MIT مع Commons Clause)، وتأتي أنت بمفاتيح نماذجك، وتبقي كل شيء بجوار الكود. لهذا الشكل من العمل هي فعلًا الخيار الأنسب، ولوحة مستضافة ستكون عبئًا لا تحتاجه.

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

وكن صريحًا مع نفسك في حساب التكلفة، فعبارة "خطة مجانية" لا تعني "فريقًا مجانيًا". حتى يوليو 2026، خطة Taskfolk المجانية بـ 0 دولار والبشر عليها بخير، والوكلاء المتصلون والمشاهدون مجانيون دائمًا. لكن مقاعد المنفّذين تكلف مالًا: Pro بـ 3 دولارات لكل مقعد منفّذ شهريًا (30 دولارًا في السنة)، وBusiness بـ 6 دولارات لكل مقعد منفّذ شهريًا (60 دولارًا في السنة). الخطة المجانية مكتملة القدرات لا مشلولة (السبرنتات والجدول الزمني والتكاملات والتقارير والذكاء الاصطناعي متاحة على كل الخطط، وحدود المجانية: 128 MB مساحة تخزين، و5 مشاريع نشطة، و1 MB لكل ملف مرفوع، و2 من قواعد الأتمتة، و1,000 صف استيراد، و25 من رصيد الذكاء الاصطناعي شهريًا)، لكن فريقًا متناميًا من المنفّذين البشر فريق مدفوع. إن كان "أعضاؤك" الوحيدون وكلاء ومشاهدَين اثنين، يبقى الحساب مجانيًا. وإن كان عشرة مهندسين يحررون جميعًا، فلن يبقى. خطط لذلك بصدق.

إن كانت وجهتك لوحة مشتركة، فالخطوات التالية الطبيعية هي ربط الوكيل، والاختيار بين MCP وREST API، وتفويض العمل إليه، وتثبيت Taskfolk كمهارة وكيل. وإن جئت إلى هنا من جانب Claude، فدليل إدارة المهام في Claude Code هو الشقيق لهذا المقال.