في معظم الأوقات يعمل Claude في turns: تطلب، فيتصرّف، ثم ينتظرك. يكسر Monitor هذا النمط. فهو يُطلق أمرًا طويل التشغيل — dev server، أو test watcher، أو deploy، أو tail لسجلّاتك — ويحوّل المخرجات إلى تدفّق حيّ يراقبه Claude. لا تشغّل أنت شيئًا بنفسك: تطلبه بلغة بسيطة (يعمل في Claude Desktop أو في الـ terminal) ويتولّى Claude الأمر من هناك. في اللحظة التي يظهر فيها سطر ذو معنى (stack trace، أو اختبار فاشل، أو build succeeded)، يستيقظ Claude ويستجيب، بدلًا من أن تضطر أنت إلى ملاحظته ولصقه. ولأن ما يراقبه هو مخرجات سطر الأوامر، فإن أنفع من يستفيد منه هم من يتضمّن عملهم تشغيل الكود — وهي قدرة موجّهة للمطوّرين، تميل إلى مسار `Power Track`.
بعض الأعمال ليست خطوة واحدة تشغّلها وتقرأها — بل تتكشّف عبر الزمن. فالـ dev server يطبع خطأً بعد ثلاث دقائق من بدئه. ومجموعة الاختبارات تتحوّل إلى الأحمر في منتصف عملية refactor. وعملية الـ deploy تفشل في المرحلة الأخيرة. عادةً تكون أنت من يترقّب تلك اللحظة، ثم يلصقها إلى Claude. يُسلّم Monitor هذه المهمّة إلى Claude.
فهو يُطلق أمرًا طويل التشغيل ويعامل كل سطر من المخرجات كحدث. في اللحظة التي يظهر فيها شيء يستحقّ التصرّف — stack trace، أو assertion فاشل، أو “listening on port 3000” — يستيقظ Claude ويستجيب، بدلًا من أن ينتظر رسالتك التالية. هذه هي النقلة: من طلب-وانتظار إلى مراقبة-وتفاعل.
ويتكامل بشكل ممتاز مع /goal: أعطِ Claude شرطًا
يلتزم به (“أبقِ الـ build أخضر”)، ووجِّه Monitor نحو الـ test runner، فيتفاعل
مع كل عطل ويواصل حتى يتحقّق الهدف — مغلِقًا الحلقة دون أن تكون أنت في
وسطها. أخبره أيّ الأسطر مهمّة، فتحصل على زميل مركّز يبقي
عينه على الشيء الذي كان عليك أنت أن تحدّق فيه بنفسك.
لماذا يفيد يحوّل Claude من طلب-وانتظار إلى شيء يتفاعل مع الأحداث — فيستطيع التقاط العطل لحظة حدوثه، لا في المرة التالية التي تتذكّر فيها أن تسأل.
أمثلة- الأفضل للأشياء طويلة التشغيل التي كنت ستراقبها بنفسك — dev servers، وtails للـ CI، وعمليات deploy، وتدفّقات السجلّات.
- اقرنه بـ
/goalكي لا يكتفي Claude بالتفاعل مع المخرجات، بل يواصل العمل حتى يتحقّق الشرط الذي حدّدته. - يقرأ التدفّق سطرًا سطرًا، لذا حدّد أيّ الأسطر مهمّة ('تصرّف على الأخطاء فقط') كي يبقى مركّزًا على الإشارة لا الضجيج.
أسئلة يطرحها الناس
- بمَ يختلف Monitor عن مجرّد تشغيل أمر؟
- الأمر العادي يعمل مرة واحدة ويُرجع مخرجاته. أما Monitor فيُبقي الأمر قيد التشغيل ويبثّ مخرجاته إلى Claude سطرًا سطرًا، فيستطيع Claude التفاعل مع المخرجات الجديدة فور ظهورها — مفيد لأي شيء مستمرّ، مثل server أو test watcher.
- ماذا يستطيع أن يراقب؟
- أي شيء يطبع إلى الـ terminal مع مرور الوقت — dev server، أو test runner في وضع المراقبة، أو build أو deploy، أو tail حيّ لسجلّات تطبيقك.
- ألن يُغرق سجلّ كثير الضجيج المحادثة؟
- يبثّ المخرجات كأحداث بدلًا من إغراق الـ context بكل شيء، فلا يزدحم الأمر بسبب سجلّ ثرثار. أخبره أيّ الأسطر مهمّة فيتفاعل مع الإشارة، لا مع كل سطر.
- هل Monitor هو slash command؟
- لا — إنه أداة مدمجة يلجأ إليها Claude من تلقاء نفسه حين تتطلّب المهمّة مراقبة مخرجات حيّة. تُشغّله بأن تطلب بلغة بسيطة، في Claude Desktop أو في الـ terminal، مثلًا: "run the server with Monitor and fix errors as they show up."
- هل Monitor مفيد إن كنت لا أكتب الكود؟
- أقلّ فائدةً. فهو يراقب مخرجات سطر الأوامر — dev servers، وtest runners، وعمليات deploy، وتدفّقات السجلّات — لذا فهو قدرة موجّهة للمطوّرين تميل إلى مسار `Power Track`. إن كان عملك لا يتضمّن تشغيل الكود، فنادرًا ما ستلجأ إليه.