Turn a ticket into a real user story حوّل التذكرة إلى user story واضحة
هنا يُحسم الأمر. فالـuser story الدقيقة هي أعلى رافعة يمكنك أن تعطيها لوكيل ذكيّ، لأنها تتحوّل حرفياً إلى المواصفة التي يخطّط كلود على أساسها. والتذكرة الغامضة تعطيك كوداً غامضاً، مهما بلغت براعة النموذج.
The one-line format · الصيغة الأساسية
As a <role>, I want <capability>, so that <benefit>. — مَن، وماذا، ولماذا. ولماذا هو أهمّ الأجزاء وأكثرها حذفاً؛ فمنه يفهم كلود أي تنازل مقبول حين يواجه خيارين.
Given / When / Then · معايير القبول
Given الوضع الابتدائي، وWhen الإجراء الذي يحدث، وThen النتيجة المتوقّعة. وينبغي أن يكون كل بند قابلاً للتجريب لتقول «نجح» أو «لم ينجح» دون نقاش.
Scope, edges, done · الحدود والحالات والخلاص
اكتب صراحةً ما هو out of scope، وما هي الـedge cases، وما هو الـdefinition of done. فبدونها يملأ الوكيل الفراغات بتخمينه، وتخمينه معقول لكنه ليس بالضرورة ما تريده.
Before → after · قبل وبعد
المهمّة نفسها بالضبط، مرّتين. والفارق ليس في الطول، بل في أن النسخة الثانية لا تحتمل أكثر من قراءة واحدة.
Before · قبل The raw ticket · التذكرة كما هي
- «الإشعارات مزعجة — ينبغي أن يستطيع المستخدم إيقافها»
- مَن المستخدم؟ وما الذي يوقفه بالضبط: كل الإشعارات أم نوعاً بعينه؟
- لا معايير قبول، أي لا تعريف لـ«اكتمل العمل»
- لا حدود، فقد يقرّر الوكيل إعادة بناء نظام الإشعارات كلّه
- لا حالات حدّية ولا سلوك متوقَّع عند الفشل
After · بعد The sharpened story · القصة بعد التدقيق
- دور واضح، وقدرة واحدة محدَّدة، وفائدة مذكورة
- ثلاثة معايير قبول بصيغة Given / When / Then، كلّها قابلة للاختبار
- قائمة out of scope صريحة توقف تمدّد النطاق قبل أن يبدأ
- حالات حدّية مذكورة بالاسم، لا متروكة للتخمين
- تعريف اكتمال يستطيع أي فرد في الفريق التحقّق منه
The rewrite prompt · طلب إعادة الصياغة
بعد أن يقرأ كلود التذكرة، يحوّلها هذا الطلب إلى مواصفة. ولاحظ السطر الأخير؛ فهو ما يمنع أخطر شيء: أن يخمّن ويمضي بهدوء.
من الـ work item الذي قرأته، اكتب لي user story واضحة: - الصيغة: As a [role], I want [capability], so that [benefit] - Acceptance criteria بصيغة Given / When / Then — كل بند قابل للاختبار - اذكر صراحةً ما هو out of scope - عدّد الـ edge cases التي قد تكسر المهمّة - وحدّد definition of done قابلاً للقياس وإن كان في التذكرة أي نقص أو غموض، فاسألني قبل أن تخمّن.
What a finished story looks like · كيف تبدو القصة الجاهزة
مثال محايد: ميزة «إيقاف إشعارات البريد لمشروع معيّن». اقرأها وكأنك الوكيل؛ فكل سؤال قد يخطر لك تجد إجابته حاضرة.
## Story As a project member, I want to switch off email notifications for one specific project, so that my inbox only reflects the work I actually follow. ## Acceptance criteria 1. Given I am on a project's Settings page, When I switch "Email notifications" off, Then the change saves immediately and I see a confirmation. 2. Given email is off for Project A, When new activity happens in Project A, Then I receive no email for it — and my other projects are completely unaffected. 3. Given I switched it off earlier, When I reload the page or sign in on another device, Then the switch still reads off. ## Out of scope - In-app and push notifications — email only - Per-event granularity (comments vs. mentions vs. status changes) - Anything in the admin-level notification settings ## Edge cases - A member of 40+ projects — the settings page still loads fast - Switch flipped twice quickly — last write wins, no duplicate rows - An email already queued when the switch flips — it may still send ## Definition of done - Acceptance criteria 1–3 verified by hand, in the running app - Unit tests on the preference logic + one test on the sender path - Zero change to notification behaviour for every other project
A sharp user story is the highest-leverage input you can hand an agent — it becomes the spec Claude plans against.