Prompt وصف الـ PR

وصف PR كويس ليه 3 أجزاء: اتغيّر إيه، ليه اتغيّر، إزاي تتأكد منه. المهندسين عارفين ده. لسه بيكتبوا PRs سطر واحد عشان الوصف هو آخر حاجة بينهم وبين push التغيير.

الـ diff لوحده context كافي للموديل يكتب وصف كويس. مش المفروض إنت تشتغل ده.

Write a PR description for this change. Format:

Summary

(2-3 bullets)

Why

(1-2 sentences, name the root cause)

Test plan

(checklist of 3-4 items)

Diff:

- function isValidEmail(s) { return s.includes("@") && s.includes("."); }
+ function isValidEmail(s: string): boolean {
+   if (s.trim() !== s) return false;
+   const at = s.indexOf("@");
+   if (at < 1) return false;
+   const dot = s.indexOf(".", at);
+   if (dot < 0) return false;
+   const tld = s.slice(dot + 1);
+   return tld.length >= 2 && /^[a-zA-Z]+$/.test(tld);
+ }

Claude Sonnet 4.5 رجّع:

## Summary
- Improved email validation to check for leading/trailing whitespace, proper
  ordering of `@` and `.` characters, and minimum position requirements
- Added validation for top-level domain (TLD) to require at least 2
  alphabetic characters
- Added TypeScript type annotations for better type safety

## Why
The original implementation was too permissive and would accept invalid email
formats like `".@"`, `"@."`, `" user@example.com "`, or `"test@com.1"`, which
could lead to data quality issues and potential security vulnerabilities.

## Test plan
- [ ] Verify valid emails pass: `"user@example.com"`, `"test@domain.co"`
- [ ] Verify invalid emails fail: `"@example.com"`, `"user@"`, `"user@com"`,
      `"test@domain.c"`, `"user@domain.1om"`
- [ ] Verify whitespace handling: `" user@example.com"`, `"user@example.com "`
      should fail
- [ ] Verify TypeScript compilation succeeds with proper type checking

Captured from Claude Sonnet 4.5 (claude-sonnet-4-5) on 2026-04-27. Re-runs may differ slightly.

ده وصف PR قابل للنشر. الـ summary bullets سهل تمسحها بسرعة. الـ "why" بيسمّي failure mode حقيقي (data quality، security). الـ test plan بيحط inputs محددة الـ reviewer يتحقّق منها، بما فيها edge cases الموديل استنتجها من الـ diff.

Format block هو اللي بيشتغل. من غير ## Summary, ## Why, ## Test plan، كنت هتجيب فقرة واحدة. الـ Markdown headers بتجبر البنية اللي PR template في فريقك بيتوقّعها.

تدفق diff → description → reviewer:

3 مبادئ تتبعها لما تكيّف الـ prompt ده لفريقك:

1. اتبع template فريقك. لو PR template في repo فيه أقسام ## Risk أو ## Rollback plan، ضيفها في format block. الموديل هيملاها.
2. خلي test plans checkboxes. الـ reviewer يقدر يشغّلها ويأشر. الـ reviewer اللي بيقرا prose بيضطر يترجمها لـ checkboxes في دماغه، وبعدين يشغّلها.
3. اطلب root cause في ## Why. "Refactored email validation" وصف، مش سبب. "Original implementation accepted whitespace and short TLDs, leading to bounce rates of 8%" سبب. الـ constraint "name the root cause" بيجبر التاني.

تكنيك متقدم صغير: لو PRs بتاعتك بتعدّي على أداة code review بتدعم labels، ضيف للـ prompt:

Suggest 1-3 labels from this set: bug, feature, refactor, chore, breaking. Output the labels on a final line as Labels: ....

اقتراحات الـ labels عادة صح. بتوفّرلك الكليكة. لسه بتراجعها — الموديل ممكن يغلط في إذا كان التغيير breaking ولا لأ — بس الاقتراح جاهز لما تـcommit.

Module جاي: تحويل نفس الـ skeleton لـ review prompts. :::