# Episode 4: Build and evaluate a reusable review skill

Production decision, 2026-10-17: English AI-cloned owner narration with English captions and Arabic translated subtitles. The Egyptian Arabic blocks below provide localized translation source text; Arabic audio is deferred. Natural length estimate: 7–9 minutes, including useful demonstrations and exercises. Measure rehearsal; never pad to a minimum. No release day assigned.

## Slide 1: the review you keep repeating

On screen: the same review questions beside two different illustrated save actions. Keep the technical scope visible: `Save concurrency and retry`.

English:

We've reviewed the save flow by checking ownership, overlapping calls, failure recovery, and evidence. Another screen may need the same review. Instead of reconstructing those questions from memory each time, we can write a reusable procedure for an assistant to follow. That's the skill we'll build here. Its job is narrow: review a save flow and report supported findings. It won't fix code automatically or certify an entire application. A focused job gives us something concrete to evaluate.

Egyptian Arabic:

راجعنا الحفظ من ناحية مكان البوابة، والاستدعاءات المتداخلة، والتعافي بعد الفشل، والدليل. شاشة تانية ممكن تحتاج نفس المراجعة. نقدر نكتب خطوات للمساعد يتبعها، بدل ما نعيد تجميع الأسئلة من الذاكرة كل مرة. دي الـ skill اللي هنعملها هنا. شغلها محدد: تراجع عملية حفظ وتطلع ملاحظات عليها دليل. مش هتصلّح الكود تلقائيًا، ومش هتحكم على التطبيق كله. التحديد ده بيخلينا نعرف نقيّم نتيجتها.


## Slide 2: the skill folder

On screen: an editable file tree: review-skill, SKILL.md, cases.md. Show only name and description from the frontmatter.

English:

The skill lives in a folder with SKILL.md. Its metadata gives it a name and describes when it is useful. The body contains the review procedure and expected output. Supporting files can hold examples or references when they help. In our prepared sample, the name is review-save-flow. The description mentions save concurrency and retry, so the purpose is clearer than a generic name like code expert. We'll read the procedure explicitly during the lesson; automatic discovery depends on the chosen tool.

Egyptian Arabic:

الـ skill موجودة في فولدر فيه SKILL.md. البيانات في أوله بتديها اسم، وبتشرح إمتى نستخدمها. وجسم الملف فيه خطوات المراجعة وشكل النتيجة المطلوبة. ممكن نضيف ملفات فيها أمثلة أو مراجع لما نحتاجها. في المثال اسمها review-save-flow. الوصف بيذكر تداخل الحفظ وإعادة المحاولة، فالغرض أوضح من اسم عام زي خبير كود. في الشرح هنطلب قراءة الخطوات صراحة، والتحميل التلقائي بيعتمد على الأداة اللي هتختارها.


## Slide 3: checks someone can follow

On screen: selected procedure lines: find owner, trace second call, follow rejection, inspect caller, run supplied checks.

English:

The procedure should tell the assistant what to inspect. First identify the owner and lifetime of the in-flight state. Follow two calls before the first finishes. Then follow success, rejection, and a synchronous throw. Inspect the caller because a correct helper can still be used incorrectly. Finally, run the project's supplied checks if execution is available. A sentence saying review carefully doesn't explain any of this. Specific questions let us compare the assistant's report with the behavior in the code.

Egyptian Arabic:

الخطوات لازم تقول للمساعد يراجع إيه. يبدأ بمكان الحالة اللي بتقول فيه حفظ شغال، وعمرها قد إيه. يمشي مع استدعاءين قبل ما الأول يخلص. وبعدها يراجع النجاح، والخطأ، والخطأ اللي بيترمي فورًا. ويفتح الكود اللي بينادي الدالة، لأن دالة صح ممكن تتستخدم غلط. وفي الآخر يشغّل الفحوصات الموجودة لو التنفيذ متاح. جملة «راجع كويس» ما بتشرحش ده. الأسئلة المحددة بتخلينا نقارن التقرير بالسلوك الموجود في الكود.


## Slide 4: a finding needs a trigger

On screen: finding fields: file/line, triggering sequence, code path, effect, suggested correction. Beside them show a brief Case B finding.

English:

A useful finding connects code to a triggering sequence. For the missing finally case, it identifies the reset after await, explains that rejection skips it, and states the effect: this owner stays blocked on later calls. The suggested correction is to release the retained flag in finally. That is easier to review than a broad warning about reliability. The report should also separate supported findings from questions that need runtime evidence. We should be able to follow the reasoning without trusting the label alone.

Egyptian Arabic:

الملاحظة المفيدة بتربط الكود بتسلسل بيظهر المشكلة. في حالة finally الناقصة، هتحدد إعادة الحالة بعد await، وتشرح إن الخطأ بيتخطاها، وتوضح النتيجة: المكان ده يفضل مقفول في المحاولات اللي بعدها. والاقتراح يكون إعادة نفس الحالة في finally. ده أسهل في المراجعة من تحذير عام عن الاعتمادية. التقرير كمان يفصل الملاحظات المدعومة عن الأسئلة اللي محتاجة دليل وقت التشغيل. نقدر نمشي مع السبب من غير ما نثق في التصنيف لوحده.


## Slide 5: rules and exceptions

On screen: `disabled={false}` beside a retained handler guard. Reveal `Feedback concern` separately from `Duplicate request claim`.

English:

The skill must handle exceptions too. A button with disabled set to false doesn't, by itself, prove that repeated requests can start. A retained handler guard might still block the extra task. There may be a separate problem with missing busy feedback, depending on the requirement. We should report that specific issue rather than invent a concurrency defect. The existing RTL audit pattern uses a similar idea: a scan finds candidates, then context determines whether each candidate represents a real problem.

Egyptian Arabic:

الـ skill محتاجة تفهم الاستثناءات برضه. زرار فيه disabled بقيمة false ما يثبتش لوحده إن الطلبات هتتكرر. ممكن يبقى فيه حارس ثابت في الدالة بيمنع المهمة الزيادة. وفي نفس الوقت ممكن يبقى فيه نقص في إظهار التحميل، حسب المطلوب. نكتب المشكلة المحددة دي من غير ما نخترع عيب تداخل. نفس الفكرة موجودة في نمط مراجعة RTL: البحث بيطلع احتمالات، وبعدها السياق بيحدد أنهي واحدة مشكلة فعلًا.


## Slide 6: a skill that repeats an answer

On screen: familiar example versus fresh case, labelled `Training example` and `Evaluation input`. Avoid any invented model score.

English:

A skill can sound excellent when it reviews the same example used to write it. That doesn't tell us how it handles a different call site or a valid exception. We need cases with known expectations that the reviewer hasn't already been given as answers. Today we'll walk through a small evaluation set and its answer key. These are prepared teaching cases. If you run an assistant on them, save its actual report separately so you can compare observed behavior with our expected outcomes.

Egyptian Arabic:

الـ skill ممكن تطلع كلام ممتاز وهي بتراجع نفس المثال اللي كتبناها عليه. ده ما يقولناش هتتعامل إزاي مع مكان استدعاء مختلف أو استثناء صحيح. محتاجين حالات عارفين المتوقع فيها، من غير ما ندي الإجابات للمراجع مسبقًا. النهارده هنمشي على مجموعة تقييم صغيرة ومفتاح إجاباتها. دي حالات مجهزة للشرح. لو شغّلت مساعد عليها، احفظ تقريره الفعلي منفصل، عشان تقارن اللي حصل بالنتائج المتوقعة.


## Slide 7: new gate on each press

On screen: Case A. Highlight the gate creation inside handlePress. Pause for the learner to classify it before revealing the expected issue.

English:

Case A creates a gate inside the press handler. Each press receives a separate pending value. Two presses therefore don't share admission state, even though the gate function itself is correct. A useful finding identifies that lifetime problem and suggests retaining the gate for the appropriate owner. The report shouldn't just say a ref is missing. It should explain why the current location allows overlapping tasks and why the proposed lifetime matches the intended behavior.

Egyptian Arabic:

الحالة A بتعمل بوابة جوه دالة الضغط. كل ضغطة ليها pending منفصلة. عشان كده ضغطتين مش بيشتركوا في الحالة اللي بتسمح بالحفظ، حتى لو دالة البوابة نفسها صح. الملاحظة المفيدة تحدد مشكلة العمر دي، وتقترح الاحتفاظ بالبوابة للمكان المناسب. التقرير ما يكتفيش يقول ref ناقصة. يشرح ليه المكان الحالي بيسمح بمهام متداخلة، وليه العمر المقترح يناسب السلوك المطلوب.


## Slide 8: retry blocked after rejection

On screen: Case B. Highlight await and the skipped reset. Display `Expected: supported recovery defect`.

English:

Case B has retained pending state but resets it only after a successful await. When the task rejects, that reset is skipped. We expect the review to identify blocked retry and point to finally as the correction. Compare this with Case A: the symptom is different because the lifetime is correct but the release path is incomplete. A useful skill follows the actual sequence. It doesn't reuse the same generic finding for every piece of code that contains pending.

Egyptian Arabic:

الحالة B فيها pending بتفضل موجودة، بس بترجعها بعد نجاح await بس. لما المهمة ترمي خطأ، سطر الإعادة ما بيتنفذش. متوقعين المراجعة تكتشف إن المحاولة الجديدة هتتقفل، وتقترح finally للتصحيح. قارنها بالحالة A: العيب مختلف، لأن العمر هنا مناسب، بس طريق فتح البوابة ناقص. الـ skill المفيدة بتمشي مع التسلسل الفعلي، ومش بتكرر نفس الملاحظة العامة مع كل كود فيه pending.


## Slide 9: a valid pattern deserves a different answer

On screen: Case C. Show `No concurrency/retry defect established here`. Small note: `Caller error handling is assumed by the exercise`.

English:

Case C retains the tested gate in a ref and calls it from the handler. Within the assumptions of the exercise, we haven't established a concurrency or retry defect. The reviewer can still state that it hasn't seen the full UI or native behavior. It should not invent a bug to make the report look substantial. This case matters because a skill that flags every example will find our broken cases, but it will also create unnecessary work on correct code.

Egyptian Arabic:

الحالة C بتحتفظ بالبوابة اللي اختبرناها في ref، وبتناديها من دالة الضغط. في حدود افتراضات التمرين، ما أثبتناش عيب تداخل أو إعادة محاولة هنا. المراجع يقدر يوضح إنه ما شافش الواجهة كاملة ولا سلوك التطبيق الفعلي. بس ما يخترعش مشكلة عشان التقرير يبان كبير. الحالة دي مهمة، لأن skill بتقول كل الأمثلة غلط هتلاقي أمثلتنا المكسورة، وهتعمل شغل زيادة على الكود الصح كمان.


## Slide 10: feedback and admission are separate

On screen: Case D. Highlight disabled false first, then the retained runSave. Reveal two rows: `Duplicate-request claim: unsupported from this prop` and `Busy feedback: review against requirements`.

English:

Case D keeps the handler guard but leaves the button enabled. We shouldn't infer duplicate tasks from that prop alone. The retained gate still controls admission. However, our feature requirements include busy feedback, so the visible interface may need work. The report should name that concern separately. This is the kind of distinction that turns a checklist into a useful review procedure: the same visual clue can suggest an issue without proving the particular failure that first came to mind.

Egyptian Arabic:

الحالة D محتفظة بحارس الدالة، بس سايبة الزرار متاح. ما نستنتجش من الخاصية دي لوحدها إن المهام هتتكرر. البوابة الموجودة لسه بتتحكم في السماح بالحفظ. لكن شروط الميزة عندنا فيها إظهار التحميل، فالشكل الظاهر ممكن يحتاج تعديل. التقرير يسمي القلق ده لوحده. التفرقة دي هي اللي بتخلي خطوات المراجعة مفيدة: علامة في الكود ممكن تشير لمشكلة، من غير ما تثبت أول نوع فشل جه في بالنا.


## Slide 11: compare findings with the answer key

On screen: A issue, B issue, C no demonstrated concurrency issue, D distinguish feedback. Keep `Expected answers` visible. Pause 15 seconds.

English:

The answer key expects the ownership issue in A and the failure-release issue in B. C should avoid an invented concurrency finding. D should distinguish busy feedback from admission control. When you run a real evaluation, count missed issues and false positives separately, and keep the report. If the skill misses A, strengthen the call-site lifetime check. Then test a different lifetime example, not only A again. Four prepared cases help expose weaknesses, but they don't establish universal accuracy.

Egyptian Arabic:

مفتاح الإجابة متوقع مشكلة عمر البوابة في A، ومشكلة فتحها بعد الخطأ في B. وفي C ما نخترعش عيب تداخل. وD محتاجة نفرّق بين إظهار التحميل والتحكم في بداية المهمة. لما تعمل تقييم فعلي، احسب المشاكل اللي فاتت والملاحظات الغلط بشكل منفصل، واحتفظ بالتقرير. لو الـ skill ما اكتشفتش A، وضّح خطوة مراجعة عمر البوابة. وبعدها جرّب مثال مختلف على نفس الفكرة. أربع حالات مفيدين، بس ما يثبتوش دقة عامة.


## Slide 12: the workflow you take away

On screen: the actual downloadable files in sequence: task, context, implementation, tests, skill, evaluation cases. End on the learner exercise, with no new-topic promise.

English:

You now have a complete small workflow to reuse. Describe behavior before asking for code. Provide verified context. Inspect the proposed change and run the checks that match the task. When a review repeats, write it as a focused skill and evaluate it on new cases, including valid code. Your next exercise is to apply the same method to a different action, such as retrying a failed refresh. Define its acceptance cases first, then decide which parts of this save-review skill actually transfer.

Egyptian Arabic:

كده عندك طريقة شغل صغيرة وكاملة تقدر تستخدمها تاني. اوصف السلوك قبل ما تطلب كود. وضّح سياق متراجع. افحص التعديل وشغّل الفحوصات اللي تناسب المهمة. ولما المراجعة تتكرر، اكتبها كـ skill محددة وقيّمها على حالات جديدة، منها كود صحيح. تمرينك الجاي إنك تطبق نفس الطريقة على إجراء مختلف، زي إعادة تحديث فشلت. حدد شروطه الأول، وبعدها قرر أنهي أجزاء من مراجعة الحفظ تنفع معاه.


## Recording and evidence

Slide cues are not narration. Use the matching task, context, implementation, verification, skill-authoring and evaluation prompts in [prompts.md](../sample/prompts.md). The exercise answers are in the spoken blocks and [evaluation answer key](../sample/review-skill/cases.md). Keep that answer key out of a real blind evaluation. Samples are teaching adaptations; no native app or actual AI evaluation result is claimed. Record slide by slide and time the selected takes.