Prompt المراجعة بـ 3 تصنيفات

Prompt "راجع الكود ده" بشكل حر بيطلّع blob حر من الـ feedback. مش هتقدر تتصرّف بناءً عليه — bug fixes مخلوطة مع style nits، مشاكل الأمان مدفونة تحت آراء التسمية، والموديل بيختار أي ترتيب بيحس إنه طبيعي للحوار. لما تبقى فهمت الرد، كنت ممكن قريت الـ diff بنفسك.

الحل إنك تقسم المراجعة على تصنيفات. 3 تصنيفات بتغطي معظم المراجعات: SECURITY، PERFORMANCE، READABILITY. كل اكتشاف بيدخل bucket واحد بالظبط. كل اكتشاف فيه format محدد. الـ reviewer اللي بيقراه عارف يبص فين الأول.

المراجعة بـ 3 تصنيفات، متراكمة حسب اللي كل طبقة بتمسكه:

Review this code in 3 categories. For each category, list 0–3 issues, each as: SEVERITY (high/med/low) — issue (line N) — fix in one line.

Categories: SECURITY, PERFORMANCE, READABILITY.

import sqlite3

def get_user(conn, name):
    cur = conn.cursor()
    q = "SELECT id, email FROM users WHERE name = '" + name + "'"
    cur.execute(q)
    return cur.fetchone()

End with a 1-line verdict: APPROVE / REQUEST_CHANGES / BLOCK.

Claude Sonnet 4.5 رجّع:

## SECURITY
1. HIGH — SQL injection vulnerability (line 5) — Use parameterized query:
   `cur.execute("SELECT id, email FROM users WHERE name = ?", (name,))`

## PERFORMANCE
1. LOW — Cursor not closed (line 4) — Use context manager or call
   `cur.close()` after fetchone()
2. LOW — No index consideration (line 5) — Ensure `name` column is indexed
   for query performance

## READABILITY
1. LOW — Variable name too short (line 5) — Rename `q` to `query` for clarity
2. MED — No input validation or error handling (line 3) — Add type check for
   `name` parameter and handle exceptions

---

Verdict: BLOCK — Critical SQL injection vulnerability must be fixed before merge.

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

لاحظ التخطيط. مشكلة الـ SQL injection عايشة تحت SECURITY، مش مدفونة في نص style nits. الـ verdict في الآخر كلمة واحدة. الـ reviewer يقدر يمسح ده في 15 ثانية: high-severity security finding → BLOCK → خلصنا. مش بيضطر يناقش الأولويات؛ البنية بتناقشها قبله.

"0–3 issues" upper bound بيشتغل فعلاً. من غيره، الموديل بيلاقي حاجة يقولها في كل تصنيف، حتى لو مفيش حاجة غلط. LOW readability issue في كود فعلاً سليم بيعمل ضوضاء. الحد عند 3 بيجبر الموديل يختار أهم اكتشافات، والحد عند 0 بيخلّي التصنيفات فاضية لما تكون كده.

3 أنماط تاخدها معاك:

النمط	بيعمل إيه
تصنيفات ثابتة	الـ reviewers دايماً عارفين يبصوا فين الأول
Severity tag (high/med/low)	بيرتّب الشغل من غير قراية زيادة
(line N)	بتقدر تـclick على المكان
Verdict سطر واحد آخر	بيجبر قرار؛ مفيش لف ودوران

Verdict line هي أهم constraint. من غيرها، بتجيب list من الـ issues من غير توصية شاملة، وبتضطر تجمع الاكتشافات بنفسك. مع الـ verdict، الموديل ملتزم — APPROVE يعني "كنت هـmerge ده،" REQUEST_CHANGES يعني "صلّح high/med الأول،" BLOCK يعني "high-severity finding، ما تـmergeش."

أحياناً هتختلف مع الـ verdict. ده تمام. الهدف مش outsource للقرار — الهدف خلي تفكير الموديل قابل للمراجعة عشان تقدر تتجاوزه بوعي. موديل بيقول "APPROVE رغم SQL injection" بيدّيك حاجة تعارض فيها. موديل بيلف بيدّيك ولا حاجة.

التالي: إزاي تستخدم severity tags كويس. :::