انتقل إلى المحتوى
AppFoyer
ابدأ

اجعل تطبيقك جاهزًا للمتجر من وكيل البرمجة لديك

يقرأ وكيلك التطبيق الذي أمامه — حزم SDK، والأذونات، ومعرّف الحزمة — ويكتب مسودة كل صفحة امتثال مما يجده. أنت تقرأ المسودات وتنشرها. والوكيل لا يستطيع.

قبل أن تبدأ

تحتاج إلى Claude Code وحساب في AppFoyer. الخطة المجانية تكفي: أنشئ حسابًا. لا يوجد مفتاح لإنشائه — يطلب منك الوكيل الموافقة عليه في المتصفح أول مرة يتصل فيها.

لا تملك وكيل برمجة على الإطلاق؟ ستة حقول في المتصفح تمنحك الصفحات الخمس نفسها دون الإضافة.

لا تستخدم Claude Code؟ الإضافة تحتاج إليه، أما صفحتا الخصوصية والشروط فلا: في محرريهما في لوحة التحكم موجّه (prompt) مملوء بتفاصيل تطبيقك، تشغّله في أي مساعد ثم تلصق الرد — وهو منشور كاملًا في دليل سياسة الخصوصية ودليل الشروط.

التثبيت

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

لا تحتاج إلى حساب للبدء: يقرأ الوكيل البناء لديك، ويعرض ما وجده، ويطرح أسئلته على جهازك، ولا يطلب منك الاتصال إلا حين يكون هناك ما يُحفظ. في أول مرة يستدعي فيها AppFoyer، يُفتح متصفحك على صفحة موافقة: سجّل الدخول أو أنشئ حسابًا مجانيًا، وتحقق من الاسم ومن العنوان الذي يعود إليه المتصفح، ثم وافق. يحتفظ Claude Code بالاتصال ويجدّده من تلقاء نفسه؛ لا شيء يُنسخ، ولا شيء يُخزَّن في الصدفة (shell) لديك. إذا لم يُفتح المتصفح، فشغّل /mcp، واختر appfoyer ثم Authenticate. في تطبيق Claude Code لسطح المكتب، اتصل مرة واحدة بهذه الطريقة من الطرفية، ثم ابدأ جلسة جديدة هناك: الجلسة التي كانت تعمل من قبل لا ترى الاتصال الجديد. افصله من صفحة Agent في لوحة التحكم فيفشل الاستدعاء التالي فورًا. لا يحدّث Claude Code متاجر الإضافات (marketplaces) التابعة لجهات خارجية من تلقاء نفسه: في /plugin → Marketplaces → appfoyer، اختر Enable auto-update لتتلقى الإصدارات الجديدة.

لا يوجد متصفح على ذلك الجهاز — خادم بعيد، أو حاوية، أو تشغيل عبر سكربت؟ استخدم مفتاح API بدلًا من ذلك: أنشئه من Agent → API key — for CI and headless use، وثبّت الإضافة كما سبق للحصول على سير العمل، ثم أضف الخادم مرة أخرى مع المفتاح في ترويسته:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

تقرأ الإضافة المفتاح من متغير البيئة ذاك فقط — لا تراه المهارة (skill) أبدًا، ولا ينتقل إلا في ترويسة Authorization التي يملؤها Claude Code.

يمكن لعميل MCP آخر — claude.ai، أو Claude Desktop، أو Cursor، أو VS Code — الاتصال بـ https://app.appfoyer.com/mcp بالطريقة نفسها، ومع صفحة الموافقة نفسها. يحصل على الأدوات؛ أما سير العمل خطوة بخطوة الذي يقرأ ملفات البناء لديك فيأتي مع إضافة Claude Code.

ماذا تقول

شغّل هذه داخل مستودع تطبيقك، لا في مجلد فارغ:

قلما يحدث
Make this app store-ready يفحص ملفات البناء، ويتأكد معك من الحقائق التي لم يستطع استنتاجها، ويكتب مسودة كل صفحة، ويعيد رابطًا للمراجعة.
Is this app store-ready? تدقيق للقراءة فقط مقابل قائمة التحقق من الامتثال. لا يكتب شيئًا.
Wire the store-ready links into the app بعد أن تنشر: يقترح روابط الخصوصية والدعم داخل التطبيق على شكل diff تراجعه.
Add the AppFoyer drift check يقترح سير عمل في GitHub يُنبّه إلى طلبات السحب (pull requests) التي تضيف حزمة SDK أو إذنًا قد لا تغطيه الصفحات. طريقة العمل.

أمثلة

قلها بكلماتك الخاصة؛ هذه هي الحالات التي تتعامل معها المهارة (skill).

تطبيق واحد، أول تشغيل

> Make this app store-ready
  • يسرد ما وجده في ملفات البناء — حزم SDK، والأذونات، ومعرّف الحزمة — كلٌّ مع الملف ورقم السطر.
  • لا يسأل إلا عمّا لم يجده: اسم الشركة، وبريد الدعم، والولاية القضائية، وروابط المتاجر. جولتان على الأكثر.
  • ينشئ التطبيق، ويرفع الأيقونة من المستودع، ويكتب مسودات الصفحات الخمس كلها.
  • ينتهي برابط للمراجعة. لا يصبح أي شيء علنيًا حتى تنشره هناك.

شغّله مجددًا بعد تغيير

> Make this app store-ready
  • يعثر على التطبيق الموجود من معرّف التطبيق (application id)، ويقارن الحقائق الجديدة بالمخزّنة.
  • يعيد كتابة مسودات الصفحات التي يمسّها التغيير فقط، مثل صفحة الخصوصية بعد إضافة حزمة SDK جديدة للتحليلات.
  • لا يمسّ الأيقونة والعنوان ما لم تطلب ذلك.

عدة نكهات (flavors)، مسمّاة في الموجّه

> Make com.acme.weather.free and com.acme.weather.pro store-ready
  • ينشئ تطبيقين ولا يسأل شيئًا عن الاختيار.
  • يقرأ المجلد والاسم والتبعيات الخاصة بكل نكهة. حزمة SDK إعلانية تستخدمها النكهة المجانية وحدها لا تُذكر في سياسة خصوصية النكهة المدفوعة (pro).
  • يعيد رابطًا للمراجعة وجدولًا بروابط وحدة التحكم لكل نكهة.

عدة نكهات (flavors)، غير مسمّاة

> Make this app store-ready
  • يسرد النكهات مع معرّفات التطبيقات الخاصة بها، وكلها محددة مسبقًا، وأنت تختار أيها يحصل على موقع.
  • أنواع البناء مثل debug وstaging تُدرج على أنها مستبعدة، ولا تُعرض للاختيار.

أبعاد العلامة التجارية × البيئة

> Make every brand store-ready
  • يسرد التركيبات (brandAProd وbrandBProd)، لا النكهات المفردة.
  • لا يعرض إلا بيئة الإنتاج. فبيئتا dev وqa لا تصلان إلى المتجر أبدًا.
  • يقرأ اسم التطبيق من Gradle (resValue وmanifestPlaceholders) أو من مجموعات المصادر المنقولة حين يضعه البناء هناك.
  • إذا لم يستطع التمييز بين بُعد للبيئات وبُعد للعلامات التجارية، فإنه يسأل.

عنوان مخصص (Pro وAdvanced)

> Make this app store-ready
  • يبني العنوان من الاسم الإنجليزي للتطبيق، مثل weather-now.
  • إذا كان محجوزًا أو قريبًا جدًا من اسم علامة تجارية، يجرّب التالي — weather-now-app، أو acme-weather — خمس مرات على الأكثر، ثم يسألك.
  • في الخطة المجانية يُبقي على عنوان app-… ويوضح أن العنوان المخصص يأتي مع Pro.
  • يواصل عنوان app-… تقديم الموقع نفسه.

تغيير عنوان تستخدمه بالفعل

> Change the address to weather-radar
  • يسأل أولًا. يُحرَّر العنوان المخصص القديم فورًا، وصفحة المتجر التي لا تزال تذكره تتوقف عن العمل.
  • لا يغيّره إلا بعد موافقتك.

تحديث الأيقونة

> Update the app icon
  • يعثر على أيقونة التشغيل: أيقونة Play بمقاس 512، أو أكبر صورة mipmap، أو صورة التسويق في AppIcon على iOS — أيقونة النكهة نفسها أولًا.
  • إذا تجاوز حجمها 512 KB، يصغّر نسخة منها في مجلد مؤقت. ولا يُمسّ مستودعك.
  • يخبرك بالملف الذي رفعه. في التطبيق المنشور تصبح الأيقونة الجديدة ظاهرة فورًا.

تطبيق يعرض إعلانات

> Make this app store-ready. AdMob publisher id pub-0000000000000000
  • يكتب app-ads.txt من الأسطر التي تعطيها له. معرّف الناشر ليس في شيفرتك، لذا لا يخمّنه أبدًا.
  • يذكّرك بأن تجعل الموقع موقع المطوّر في صفحة تطبيقك في المتجر.
  • تحقق AdMob من ملفات app-ads.txt على عناويننا؛ امنحه ما يصل إلى 24 ساعة للزحف.

إبقاء الصفحات متوافقة مع البناء

> Add the AppFoyer drift check
  • كل تشغيل لـ “make this app store-ready” يكتب appfoyer.json في جذر المستودع: حزم SDK وأنواع البيانات والأذونات التي كُتبت الصفحات على أساسها. يكتبه الماسح نفسه الذي يشغّله الفحص، ولا يُكتب يدويًا أبدًا.
  • يعرض هذا الموجّه سير عمل GitHub لـ appfoyer/check-action المجاني، ويكتب .github/workflows/appfoyer.yml حين توافق. ولا يستبدل أبدًا سير عمل موجودًا لديك.
  • من ذلك الحين يسرد كل طلب سحب ما أضافه أو أزاله منذ كتابة الصفحات، مع الملف ورقم السطر. وتشغيل الإضافة مجددًا يحدّث المسودات وappfoyer.json.
  • لا يُجرى أي commit نيابةً عنك. ودليل إبقاء سياسة الخصوصية متوافقة مع البناء يتضمن التفاصيل والإعداد لأنظمة CI الأخرى.

الفحص دون تغيير أي شيء

> Is this app store-ready?
  • يشغّل قائمة التحقق لكل تطبيق مطابق ويُبلغ عمّا ينقص. لا يكتب شيئًا.
  • النكهة التي ليس لها تطبيق بعد تُذكر على أنها ناقصة.

وضع الروابط داخل التطبيق

> Wire the store-ready links into the app
  • يحتاج إلى صفحات منشورة.
  • يقترح diff لروابط الخصوصية والدعم في شاشة الإعدادات أو ملفات النصوص لديك. ولا يطبّقه إلا حين توافق، ولا يُجري commit أبدًا.

ما الذي يغادر جهازك

الحقائق المستنتجة فقط:

  • اسم التطبيق، ومنصته، ومعرّف الحزمة أو التطبيق؛
  • أسماء حزم SDK والأذونات الموجودة في ملفات البناء لديك؛
  • الإجابات التي تؤكدها — اسم الشركة، وبريد الدعم، والولاية القضائية، وروابط المتاجر؛
  • نص الصفحات الذي يكتبه الوكيل، ويُخزَّن في حسابك كمسودة؛
  • أيقونة التطبيق نفسه، تُرسل مرة واحدة عبر رابط رفع صالح لاستخدام واحد.

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

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

ما لا يستطيع الوكيل فعله

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

  • لا توجد أداة للنشر. يكتب الوكيل مسودات؛ وصفحاتك المنشورة لا تتغير.
  • شيئان ليست لهما مسودة: الأيقونة والعنوان المخصص. في التطبيق المنشور يغيّران الموقع المنشور فورًا، ويخبرك الوكيل حين يضبطهما. ولا يستطيع استبدال عنوان مخصص تستخدمه بالفعل دون موافقتك.
  • مسار REST الذي ينشر الصفحة يرفض بيانات اعتماد الوكيل رفضًا قاطعًا — للجلسات فقط.
  • لا تزال كل صفحة تمر بفحص المحتوى نفسه عند النشر كما يمر التعديل المكتوب يدويًا.
  • يُسجَّل كل استدعاء للوكيل في سجل التدقيق الخاص بالحساب مع الاتصال أو المفتاح الذي أجراه.

لذا فأسوأ الاحتمالات عند اختراق اتصال أو مفتاح هو مسودات تتجاهلها، أو أيقونة خاطئة، أو عنوان جديد — لا صفحة تُنشر باسمك.

الأدوات التي يحصل عليها

تتصل الإضافة بنقطة نهاية MCP تتيح هذه الأدوات بالضبط:

الأداةما تفعله
list_apps قراءة كل تطبيقات الحساب مع المعرّف (slug) والرابط العام لكل منها، وهل نُشر أي شيء.
get_app قراءة تطبيق واحد: الإعدادات، وحقائق جمع البيانات المخزّنة، والنص المنشور لكل صفحة وحالة نشرها ومسودتها المعلّقة.
create_app كتابة ينشئ تطبيقًا بصفحات من القوالب. لا شيء علني.
create_apps كتابة ينشئ ما يصل إلى عشرة تطبيقات في استدعاء واحد، تطبيقًا لكل نكهة منتج. ويبدأ كل منها غير منشور.
update_app كتابة يغيّر الإعدادات، أو حقائق جمع البيانات المخزّنة، أو قائمة حزم SDK. ولا يعدّل نص الصفحات أبدًا.
set_page كتابة يكتب المسودة لصفحة واحدة. والصفحة المنشورة لا تُمس.
set_ad_lines كتابة يستبدل app-ads.txt. لا يُستخدم إلا حين توجد حزمة SDK إعلانية وتكون قد قدّمت معرّفات الناشر.
get_checklist قراءة قائمة الجاهزية للمتجر المحسوبة على الخادم، إضافة إلى الصفحات التي لا تزال لها مسودات غير منشورة.
get_store_forms قراءة مسودات إجابات لنموذج Data safety في Google Play وتفاصيل App Privacy لدى Apple، من الحقائق وقائمة حزم SDK. أنت من يُدخلها في وحدة التحكم.
request_publish كتابة يُعلن انتهاء كتابة المسودات ويعيد رابط المراجعة. لا ينشر شيئًا.
set_icon كتابة يعيد رابط رفع صالحًا لمرة واحدة لأيقونة التطبيق. تظهر فورًا — فالأيقونة ليست لها مسودة.
check_slug قراءة يفحص عنوانًا مخصصًا (Pro وAdvanced) وفق القواعد نفسها المطبقة في لوحة التحكم.
set_slug كتابة يحجز عنوانًا مخصصًا. يصبح فعّالًا فورًا. ويرفض استبدال عنوان لديك بالفعل ما لم توافق.

عندما يحدث خطأ ما

العَرَضالسبب
تعرض الأدوات "needs authentication" لم تتم الموافقة على الاتصال قط، أو فُصل. شغّل /mcp، واختر appfoyer ثم Authenticate.
تقول صفحة الموافقة إن الطلب لا يمكن استخدامه انتهت صلاحية الرابط أو فُتح مرتين. ابدأ من جديد من المحرر؛ لم يُربط أي شيء.
unauthorized مع مفتاح API أُلغي المفتاح من لوحة التحكم، أو أنه يخص حسابًا آخر. أنشئ مفتاحًا جديدًا وصدّره (export) مرة أخرى.
يعيد النشر خطأ في الحصة استُنفد حد التطبيقات المنشورة في الخطة. يُحتفظ بالتطبيق ومسوداته — ألغِ نشر تطبيق آخر أو رقِّ خطتك، ثم انشر من شاشة المراجعة.
تعود مسودة مرفوضة أو موقوفة طابق فحص المحتوى شيئًا ما. تذكر الأسباب ما الذي طابق وكيف تصلحه؛ عدّل ثم أعد الإرسال. لم يتغير أي شيء علني.

شيء واحد لا يغيّره هذا

المسودات قوالب مكتملة من شيفرتك، وليست استشارة قانونية. كتابة الوكيل لها بسرعة لا تجعلها صحيحة — اقرأ ما كتبه قبل أن تنشر، ولا سيما قائمة ما يجمعه تطبيقك. فأنت من يحمّله المتجر المسؤولية.

للأسئلة: support@appfoyer.com.