بمَ يختلف هذا عن playbook الـ spend-audit؟

دليل قواعد التصنيف هو المرجع الذي يستخدمه الـ spend audit. يمسح الـ audit شهرًا بحثًا عن الشذوذ ويصنّف الأطراف المتفلّتة؛ وهذا الـ playbook يبني الـ categorization-rules.md الذي يخبره بأي فئة ينتمي إليها كل vendor. ابنِ دليل القواعد مرّة واحدة (فهو أساس من Stage 1) وغذِّ به كل audit وميزانية وإغلاق كي يكون التصنيف متّسقًا بدلًا من إعادة تقريره كل شهر.

لماذا لا أخبر Claude بفئاتي في كل prompt فحسب؟

لأنك ستصفها بشكل مختلف قليلًا في كل مرة، فينحرف الـ vendor نفسه بين الفئات من شهر لآخر — وهو ما يكسر بصمت كل مقارنة شهر بشهر. دليل قواعد مكتوب ترفقه يجعل التصنيف حتميًا: المُدخَل نفسه يُنتِج الفئات نفسها، فتتقارن مجاميعك فعلًا.

هل سيجعل دليل القواعد تصنيفي صحيحًا؟

يجعله متّسقًا، وهو معظم القيمة، لكن ليس صحيحًا تلقائيًا. تضمن القواعد أن يقع الـ vendor دائمًا في الفئة نفسها — لكنك ما زلت تراجع التخطيط نفسه لتؤكّد أن تلك الفئة هي الصحيحة، وتحدّثه حين يتغيّر عملك. الاتّساق هو ما يشتريه لك دليل القواعد؛ أما الصحّة فتبقى حُكمًا بشريًا.

ماذا يحدث حين يظهر vendor جديد تمامًا؟

أهمّ قاعدة في دليل القواعد هي أن الـ vendor المجهول يُترَك دون تصنيف ويُنبَّه إليه للمراجعة — لا يُحشَر قسرًا في أقرب فئة أبدًا. أنت تتّخذ القرار، ثم تضيف الـ vendor الجديد إلى التخطيط كي يُحسَم للشهر القادم. التنبيه إلى المجهول بدلًا من تخمينه هو ما يبقي فئة خاطئة واثقة بعيدةً عن مجاميعك.

ابنِ دليل قواعد التصنيف الذي يرث منه كل تقرير

متى تلجأ إلى هذا

«صنّف هذا» لا يعني شيئًا لـ Claude — ولا أكثر من ذلك بقليل لمحلّل جديد — ما لم تكن القواعد مكتوبة. فيقع الـ vendor نفسه كل شهر في فئة مختلفة قليلًا: AWS هي Hosting في شهر وInfrastructure في الذي يليه، وفجأةً لم تعد مجاميع فئاتك قابلة للمقارنة بمجاميع الشهر الماضي. العلاج ليس إعادة شرح دليل حساباتك في كل prompt؛ بل استخراج القواعد مرّة واحدة في ملف categorization-rules.md تغذّي به كل مهمّة إنفاق. هذا هو مكافئ Finance لمستند الـ brand voice: ابنِه مرّة واحدة، فيصنّف الـ spend audit ومراجعة الميزانية والإغلاق كلّها بالطريقة نفسها — لأن «فئاتنا» تشير أخيرًا إلى مستند حقيقي بدلًا من تخمين كل شهر.

جهّز هذا أولًا

دليل حساباتك — فئات التقارير الفعلية التي تستخدمها (Payroll وHosting وSoftware وTravel وContractors وMarketing وProfessional Fees) — لا فئات عامّة.
بضعة أشهر من exports مصنّفة مسبقًا — transactions-q1.csv وما شابهها — كي يتعلّم Claude من الطريقة التي كنت تصنّف بها فعلًا، لا الطريقة التي تظن أنك تصنّف بها.
أحكام التقدير التي لا يعرفها إلا أنت: أيّ vendor هو capex وأيّه opex، وأين يقع الـ vendor الغامض (استشاري يكون أحيانًا Marketing وأحيانًا Contractors)، وأي vendor ينبغي دائمًا تقسيمه عبر فئات.

الـ workflow

استنبط القواعد من الطريقة التي تصنّف بها أصلًا

التعرّف على منطق تصنيفك في بيانات حقيقية أسهل بكثير من كتابته من صفحة فارغة. في Claude Desktop، افتح المجلد الذي يحوي exports المصنّفة السابقة واسأل في المحادثة — دون الحاجة إلى Terminal. اجعل Claude يستنتج تخطيط vendor→category الذي كنت تستخدمه بدلًا من أن تحاول سرد كل vendor يدويًا.

أنت تطلب

اقرأ هذه الأشهر الثلاثة من المعاملات المصنّفة. استنبط القواعد التي كنت أستخدمها: ابنِ تخطيط vendor→category (كل vendor صنّفته والفئة التي وقع فيها)، ونبّه إلى أي vendor يظهر في أكثر من فئة، واسرد الفئات التي أستخدمها فعلًا. لا تخترع فئات جديدة — فقط أبلِغ عن القواعد التي تتّبعها بياناتي بالفعل.

ما تحصل عليه مسودة دليل قواعد مبنية على تاريخك الحقيقي: جدول vendor→category («AWS ← Hosting؛ Notion ← Software؛ Delta Air ← Travel»)، وقائمة تنبيه بالـ vendors التي صنّفتها بشكل غير متّسق («Acme Consulting: Marketing في يناير، Contractors في فبراير — اختر واحدة»)، وقائمة فئاتك الحقيقية. التناقضات هي الكنز — فهي بالضبط القواعد التي لم تكتبها قط.

الـ vendors التي صنّفتها بطريقتين مختلفتين هي السبب الكامل لبناء هذا. حسم كلٍّ منها هو ما يجعل مجاميع الشهر القادم قابلة للمقارنة بمجاميع الشهر الماضي.
ثبّت أحكام التقدير والحالات الحدّية

التخطيط يتولّى الـ 80% السهلة. ويثبت دليل القواعد جدارته في الـ vendors الغامضة — تلك التي يظل الإنسان يعيد تقرير أمرها. احسم كلًّا منها الآن، كتابةً، كي تُقرَّر مرّة واحدة لا أن يُعاد الجدال فيها في كل إغلاق.

أنت تطلب

لكل vendor نبّهتَ إليه على أنه غير متّسق، اسألني أيّ فئة هي الصحيحة ولماذا، واكتب القرار كقاعدة. ثم أضِف قواعد للحالات الحدّية: أيّ vendors هي capex وأيّها opex، وأي vendor ينبغي تقسيم مصاريفه عبر فئتين (ومنطق التقسيم)، وما العمل مع vendor لم يظهر من قبل قط. اجعل كل قاعدة محدّدة بما يكفي ليصنّفها شخص آخر تمامًا كما أصنّفها أنا.

ما تحصل عليه مجموعة قواعد صريحة قابلة للاختبار — «Acme Consulting ← Contractors (هم عمالة مشروع، لا إنفاق إعلامي)؛ AWS reserved instances ← تقسيم 70% Hosting / 30% Infrastructure؛ أي vendor جديد ← اتركه دون تصنيف ونبّه للمراجعة، ولا تُسنِد له فئة تلقائيًا أبدًا.» الحكم الذي كان يعيش في رأسك صار الآن على الصفحة.
اجمَع دليل القواعد القابل لإعادة الاستخدام

اسحبه كلّه إلى أصل واحد نظيف يستطيع Claude تطبيقه مباشرةً. وحين يكتب Claude الملف، يعرضه Desktop أولًا كـ diff للقبول أو الرفض — راجِعه، ثم احفظ النسخة المرجعية.

أنت تطلب

اجمَع كل شيء في ملف categorization-rules.md نظيف: غرضٌ من سطر واحد، وقائمة فئاتي مع تعريف من جملة واحدة لما ينتمي إلى كلٍّ منها، وتخطيط vendor→category، وقواعد أحكام التقدير، وتعليمة ختامية «عند الشكّ، نبّه — لا تخمّن أبدًا». أبقِه سهل التصفّح. اعرضه عليّ كـ diff قبل الحفظ.

ما تحصل عليه ملف categorization-rules.md واحد جاهز للّصق — تعريفات الفئات، وخريطة الـ vendors، وقواعد الحالات الحدّية، وبند الصدق — محفوظ كنسخة مرجعية بعد قبولك للـ diff.

احفظ هذا الملف. يصبح أول ما ترفقه بكل spend audit ومراجعة ميزانية وإغلاق من الآن فصاعدًا — غذِّ به المهمّة فيتوقّف التصنيف عن كونه إعادة تخمين شهرية.
اختبره ميدانيًا على export جديد

أثبت أن دليل القواعد يعمل بتطبيقه على export لم يره من قبل، ثم تأكّد أنه ينبّه بدلًا من أن يخمّن في أي شيء جديد فعلًا.

أنت تطلب

باستخدام categorization-rules.md فقط، صنّف ملف transactions.csv الجديد هذا. طبّق القواعد بدقّة، واترك أي شيء لا يغطّيه دليل القواعد دون تصنيف مع ملاحظة عن السبب، وأعطِني عددًا للمصنّف تلقائيًا مقابل المنبَّه عليه للمراجعة. لا تغيّر الملف — أرِني النتيجة كي أؤكّد أن القواعد صامدة.

ما تحصل عليه معاينة مصنّفة إضافةً إلى حصيلة — «312 صفًا صُنّفت تلقائيًا بدليل القواعد، 7 صفوف نُبِّه إليها للمراجعة (5 vendors جديدة، 2 غامضة)» — دليلٌ على أن المستند محدّد بما يكفي ليُطبَّق باتّساق وصادقٌ بما يكفي ليُنبّه إلى ما لا يستطيع وضعه.

اجعله ملكك

زامِنه مع أداة المحاسبة لديك: بمجرّد استقرار الفئات، اعكِس فئات دليل القواعد على دليل حسابات برنامج المحاسبة كي يكون التخطيط نفسه في كل مكان — Claude، ودفاترك، وتقاريرك كلّها تتكلّم لغة واحدة.
متعدّد الكيانات أو متعدّد العملات: إن كنت تدير أكثر من كيان، أضِف قسمًا لكل كيان (أو دليل قواعد منفصلًا) وقاعدة عملة (أي سعر، أي تاريخ) — فتخطيطٌ واحد عبر كيانات غير متطابقة يخلط بصمت بين أمور لا تُقارَن.
كشوف ثنائية اللغة: إن وردت أسماء الـ vendors أو التقارير بالعربية والإنجليزية معًا، سجّل الاسم المعتمد وصيغه المختلفة في التخطيط كي لا تصير «شركة الاستضافة» و«Hosting Co» اثنين من الـ vendors. اكتب الجانب العربي من كشوف عربية حقيقية، لا أن تنقله حرفيًا فحسب.
اجعله skill (Power Track): تستطيع الفرق المتقدّمة تحميل categorization-rules.md كـ skill قابل لإعادة الاستخدام أو command باسم /categorize كي يُطبَّق دائمًا — فكل ملف إنفاق يُفحَص مقابل دليل القواعد تلقائيًا (انظر تبويب Features).

انتبه إلى

*القواعد تجعل الفئات متّسقة، لا صحيحة.* يضمن دليل القواعد أن تقع AWS دائمًا في Hosting — لكنه لا يستطيع أن يخبرك أن Hosting كانت الخيار الصحيح. راجِع التخطيط نفسه، وأعِد التحقّق حين يتغيّر شكل عملك.
دليل قواعد واحد معتمد، ومالك واحد. ملف تصنيف يعدّله الجميع ينحرف عائدًا إلى عدم الاتّساق الذي بُني لإصلاحه. أبقِ مصدر حقيقة واحدًا، ورقّمه بالنسخ، وعامِل التغييرات على أنها تحديث مراجَع — لا تعديلًا صامتًا كل شهر.
لا تدعه يُطبَّق تلقائيًا على vendor جديد أبدًا. أهمّ قاعدة في المستند هي بند الصدق: الـ vendor المجهول يُنبَّه إليه، لا يُحشَر قسرًا في أقرب فئة. صفٌّ مصنَّف خطأً بثقة يشوّه كل مجموع لاحق.
احفظ تفاصيل الـ vendors والحسابات الحسّاسة في مساحة العمل المعتمدة لديك، واستبدل أي شيء خاص فعلًا بـ [placeholder] قبل مشاركة دليل القواعد — فهو مستند مرجعي، لكنه يصف إنفاقك الحقيقي رغم ذلك.

ستحصل في النهاية على ملف `categorization-rules.md` من صفحة واحدة يجعل «فئاتنا» شيئًا ملموسًا قابلًا للاختبار — كي يقع الـ vendor نفسه في الفئة نفسها كل شهر، وتبقى مجاميعك قابلة للمقارنة، ويبدأ كل playbook آخر في قسم Finance من دليل حسابات محسوم بدلًا من تخمين شهري.

أسئلة يطرحها الناس

بمَ يختلف هذا عن playbook الـ spend-audit؟: دليل قواعد التصنيف هو *المرجع* الذي *يستخدمه* الـ spend audit. يمسح الـ audit شهرًا بحثًا عن الشذوذ ويصنّف الأطراف المتفلّتة؛ وهذا الـ playbook يبني الـ `categorization-rules.md` الذي يخبره بأي فئة ينتمي إليها كل vendor. ابنِ دليل القواعد مرّة واحدة (فهو أساس من Stage 1) وغذِّ به كل audit وميزانية وإغلاق كي يكون التصنيف متّسقًا بدلًا من إعادة تقريره كل شهر.
لماذا لا أخبر Claude بفئاتي في كل prompt فحسب؟: لأنك ستصفها بشكل مختلف قليلًا في كل مرة، فينحرف الـ vendor نفسه بين الفئات من شهر لآخر — وهو ما يكسر بصمت كل مقارنة شهر بشهر. دليل قواعد مكتوب ترفقه يجعل التصنيف حتميًا: المُدخَل نفسه يُنتِج الفئات نفسها، فتتقارن مجاميعك فعلًا.
هل سيجعل دليل القواعد تصنيفي صحيحًا؟: يجعله *متّسقًا*، وهو معظم القيمة، لكن ليس *صحيحًا* تلقائيًا. تضمن القواعد أن يقع الـ vendor دائمًا في الفئة نفسها — لكنك ما زلت تراجع التخطيط نفسه لتؤكّد أن تلك الفئة هي الصحيحة، وتحدّثه حين يتغيّر عملك. الاتّساق هو ما يشتريه لك دليل القواعد؛ أما الصحّة فتبقى حُكمًا بشريًا.
ماذا يحدث حين يظهر vendor جديد تمامًا؟: أهمّ قاعدة في دليل القواعد هي أن الـ vendor المجهول يُترَك دون تصنيف ويُنبَّه إليه للمراجعة — لا يُحشَر قسرًا في أقرب فئة أبدًا. أنت تتّخذ القرار، ثم تضيف الـ vendor الجديد إلى التخطيط كي يُحسَم للشهر القادم. التنبيه إلى المجهول بدلًا من تخمينه هو ما يبقي فئة خاطئة واثقة بعيدةً عن مجاميعك.