Review-nu subagentə necə tapşırmaq və hesabatı necə yoxlamaq olar

"Səhifəni yoxla" xahişi bir çox qərarı rəyçinin öhdəsinə buraxır: davranışdakı xətaları axtarmaq, tərtibatı qiymətləndirmək, yoxsa kodu başqa cür yazmağı təklif etmək. Cavabda səliqəli bir iradlar siyahısı ala bilərsiniz, amma o, tapşırığınıza demək olar ki, kömək etməyəcək. Gəlin baxaq: Claude Code subagentinə aydın tapşırığı necə vermək və sonra onun yerinə yetirildiyini necə yoxlamaq olar.

Əgər reviewer hələ qurulmayıbsa, əvvəlcə rolu yaradın və ilk dəfə işə salın. Burada tapşırığın özünə və cavabın tamlığına diqqət yetirəcəyik.

1. Rəyçiyə nəyi ötürmək lazımdır

Rəyçi başqasının işini yoxlayır və iradları əsaslandırma ilə qaytarır. Nümunələrimizdə bu, reviewer adlı, artıq qurulmuş istifadəçi subagentidir; ona yalnız fayllarda oxuma və axtarış əlçatandır: Read, Grep, Glob. O, kodu öyrənir, amma onu düzəltmir və səhifəni brauzerdə işə salmır. Sadəcə reviewer adı belə rolu avtomatik yaratmır: güman edilir ki, o, layihənizdə artıq qurulub.

Yeni adi işəsalmada belə subagent söhbətinizin bütün tarixçəsini avtomatik almır. Ünsiyyət qurduğunuz əsas agent onun üçün ayrıca tapşırıq tərtib edir. Buna görə də "eyni adlı iki alış ayrı-ayrı qeydlər sayılır" kimi vacib tələb tapşırığa və ya rəyçiyə oxumaq tapşırılan sənədə düşməlidir. Bu qayda subagentlərin konteksti haqqında dokumentasiyada təsvir olunub; burada söhbətin surətini daşıyan fork-dan deyil, istifadəçi rolunun işə salınmasından danışırıq.

Müqayisə edin: "Layihəyə bax" və "Qeydlərin silinməsini və sayğacın yenilənməsini yoxla; kodu dəyişmə". İkinci halda hara baxmaq lazım olduğu və hansı hərəkəti gözləmədiyiniz artıq aydındır. Hansı nəticənin düzgün sayıldığını dəqiqləşdirmək qalır.

Qısa birdəfəlik yoxlama üçün mesaj kifayətdir. Meyar çoxdursa və ya yoxlama düzəlişlərdən sonra təkrarlanacaqsa, brif saxlamaq daha rahatdır: layihənin yanında tapşırığın qısa təsviri. On səhifəlik ayrıca spesifikasiya yox. Bir neçə şərt, onlarsız rəyçi təxmin etməli olacaq.

Bütün sualları qabaqcadan görmək alınmayacaq, buna ehtiyac da yoxdur. Giriş məlumatı çatışmayanda rəyçi hesabatda boşluğu qeyd etməlidir. Əsas agent onu sizdən dəqiqləşdirə biləcək. Yaxşı tapşırıq anlaşılmazlıqları azaldır, amma yaxşı cavabı təmin etmir: model aydın tapşırıqda da səhv edə bilər.

2. Tapşırığın dörd hissəsi

Məqsəd hansı davranışı yoxlamaq lazım olduğu sualına cavab verir. Alış-veriş siyahısı səhifəsi üçün bu, əlavə etmə, silmə və qeydlər sayğacıdır. "Layihəni daha yaxşı et" çox genişdir: hansı təkmilləşdirmənin indi vacib olduğu aydın deyil.

Giriş faylları və gözlənilən davranışı göstərir. Koddan eyni adlara icazə verilib-verilmədiyini anlamaq mümkün deyilsə, app.js faylına yolun özü azdır. Bu məhsul qərarını açıq şəkildə ötürmək lazımdır. Eyni zamanda nə ilə yoxlanacağını da göstərin: bizdə bu, yalnız kodu oxumaqdır, brauzersiz.

Sərhədlər bu yoxlamanı qonşu tapşırıqlardan ayırır. Məsələn, üslublar, mobil görünüş və siyahının seanslar arasında saxlanması indi nəzərdən keçirilmir. faylları dəyişmirik. Lazımi fayl yoxdursa, yoxlamanın ondan asılı hissəsini dayandırırıq və bu barədə xəbər veririk, onun məzmununu uydurmuruq.

Nəticə nə almaq istədiyinizi təsvir edir: yoxlanmış həcm, əsaslandırılmış tapıntılar və məhdudiyyətlər. Mütləq beş xəta tapmağı tələb etməyin. Claude Code-un review üzrə tövsiyələrində belə qoyuluşun riski ayrıca qeyd olunur: qüsur axtarmaq tapşırığı iş düzgün görüldüyü yerdə də irad yazmağa təhrik edir.

Hər qol digərlərinin vermədiyini əlavə edir: fayla yol gözlənilən davranışı müəyyən etmir, məqsəd isə düzəliş qadağasını müəyyən etmir. Bu şərtləri bir yerə toplayın ki, rəyçi yoxlama zamanı onları tutuşdura bilsin.

Beləliklə, "Alış-veriş siyahısı səhifəsini yoxla" əvəzinə aşağıdakı tapşırığı ötürək. Onu mesajla göndərmək və ya layihənin kökündə REVIEW_BRIEF.md faylında saxlamaq olar:

# Alış-veriş siyahısının yoxlanması
Məqsəd: əlavə etməni, silməni və sayğacı kod üzrə yoxlamaq.
Giriş: layihənin kökündəki index.html və app.js.
Gözlənilir: əlavə edilmiş bənd siyahıda görünür;
sayğac bəndlərin sayına bərabərdir; bir qeydin silinməsi
eyni adlı digər qeydi silmir.
Sərhədlər: faylları dəyişmə; üslublar, mobil görünüş və siyahının
seanslar arasında saxlanması bu yoxlamaya daxil deyil.
Lazımi fayl və ya tələb çatışmırsa, boşluğu göstər,
onu uydurma və əlçatan hissə üzrə nəticəni qaytar.
Nəticə: reviewer formatına əməl et; nəyin yoxlandığını
və nəyin yoxlanmamış qaldığını göstər. Tapıntı olmaya da bilər.

Elə aşağıda reviewer-in formatına baxacağıq. Rolunuzun hələ daimi formatı yoxdursa, onu elə həmin birdəfəlik mesaja daxil etmək olar. Sahələrin adları vacib deyil: vacib olan, unutmamağa kömək etdikləri məlumatdır.

"Hesabatda əvvəlcə ən vacib üç tapıntını göstər" xahişi yoxlamanın dərinliyini yox, cavabın həcmini məhdudlaşdırır. Belə limit lazımdırsa, başqa tapıntıların olub-olmadığını ayrıca göstərməyi xahiş edin. Üçüncü iraddan sonra dayanıb tapşırığı yoxlanmış elan etmək olmaz.

3. Fayllarda nəyi saxlamalı

Konkret tapşırığın şərtləri dəyişir: bu gün sayğacı, sabah siyahının saxlanmasını yoxlayırıq. Onların yeri brifdir. Xətanın yerini və əsaslandırmanı göstərmək xahişi isə demək olar ki, hər review-da lazımdır. Onu bir dəfə rolun təlimatında yazmaq daha rahatdır.

Output contract, yəni nəticə müqaviləsi, burada razılaşdırılmış cavab formatı deməkdir. Olduğundan daha təntənəli səslənir: bunlar rəyçi üçün adi təlimatlardır, Claude Code-un xüsusi ayarı və ya avtomatik keyfiyyət yoxlaması deyil. Format hesabatda lazımi məlumatı tapmağa kömək edir, amma onu etibarlı etmir.

Yuxarıdakı iki qol müxtəlif işlərə cavabdehdir: brif yoxlamanın məzmununu, rolun təlimatı isə o cümlədən hesabatın formasını müəyyən edir. Rəyçi saxlanmış brifdən istifadə etsin deyə, ona faylı oxumağı tapşırın. Özü ora baxmayacaq. Aşağıda hesabat alınır, onun əsaslarını və tamlığını hələ qiymətləndirmək lazımdır.

Budur, mövcud .claude/agents/reviewer.md rol faylının mətn hissəsinə, ayarlarından sonra əlavə etmək olan bölmə:

## Nəticə formatı
Yoxlanmış faylları və meyarları göstər.
Hər tapıntı üçün: yer, gözlənilən davranış, əsas,
yoxlama şərtləri və təsiri; prioriteti izah et.
Kodla təsdiqlənəni yoxlanmamış fərziyyələrdən ayır.
Məhdudiyyətləri və çatışmayan məlumatı ayrıca qeyd et.
Meyarlar üzrə problem tapmasan, belə də yaz.

Bu, subagentin tam faylı deyil, təlimatın bir parçasıdır. Bizim rolun yalnız oxuma və axtarış imkanı var, ona görə daimi "dəyişdirilmiş fayllar" sahəsi ona lazım deyil. Daha geniş hesabatda dəyişikliklər barədə məlumat faktları əks etdirməlidir: nə baş verməsindən asılı olmayaraq "dəyişdirilmiş fayllar: yoxdur" sətrini əvvəlcədən yazdırmaq olmaz.

Brif saxlandıqdan sonra əsas agentə belə sorğu göndərin:

reviewer-ə layihənin kökündəki REVIEW_BRIEF.md faylını oxumağı
və göstərilən faylları onun meyarları üzrə yoxlamağı tapşır.
Yekun hesabatı tam şəkildə qaytar.

Biz sənədin adını sadəcə çəkmədik, onu oxumağı açıq şəkildə tapşırdıq. Amma fayl özlüyündə heç nəyə zəmanət vermir: rəyçi yenə də hansısa şərti buraxa bilər. Saxlanmış brifin rahatlığı ondadır ki, nəticəni onunla tutuşdurmaq və yoxlamanı təkrarlamaq olur. Tələblər dəyişəndə əvvəlcə sənədi yeniləyin, yoxsa növbəti keçid köhnə tapşırığı qiymətləndirəcək.

4. Hesabatı necə yoxlamalı

Əvvəlcə baxın, həqiqətən nə yoxlanıb. Brifdə əlavə etmə, silmə, sayğac və eyni adlı qeydlərin bir-birindən asılı olmaması var idi. Hesabat yalnız sayğacdan danışırsa, bu hələ bütün tapşırıq üzrə nəticə deyil. Hətta yeganə tapıntı tamamilə doğru olsa belə.

Brifin hər meyarını cavabla tutuşdurmaq rahatdır. Məsələn, tədris məqsədli natamam hesabatda belə alındı:

Eyni adlar barədə sətrin olmaması xətanın olmadığı demək deyil. Bununla belə, sayğac haqqında bir əsaslı tapıntı tapşırığın buraxılmış hissəsini bağlamır. Hesabatı konkret dəqiqləşdirmə ilə geri qaytarın:

Brifdə eyni adlı iki qeyddən birinin silinməsi var.
Hesabatda bu meyar əks olunmayıb. Onu əlindəki vasitələrlə yoxla
və nəticənin əsasını, ya da niyə yoxlaya bilmədiyinin səbəbini göstər.
Qalan nəticələri dəyişmədən təkrarlamağa ehtiyac yoxdur. Kodu dəyişmə.

Vacib tapıntıların etibarlılığını ayrıca qiymətləndirin: göstərilən yeri, tələbi və nəticənin əsasını tutuşdurun. Ətraflı nümunə review hesabatını oxumaq haqqında məqalədədir. Burada hər iki yoxlama lazımdır: tapşırığın əhatəsi və nəticənin əsaslı olması. Təklif olunan işəsalma ssenarisi artıq icra olunmuş testlə eyni şey deyil.

Birinci budaqlanmada tapşırığımız üçün kifayət qədər yoxlanıb-yoxlanmadığına qərar veririk. Yoxlanmayıbsa, çatışmayanı istəyirik və ya yalnız yoxlanmış hissəni qəbul edirik, onun da əsaslarını qiymətləndirərək. İkinci budaqlanmada əsaslı nəticələri mübahisəli və yanlış olanlardan ayırırıq. Aydın olmayan əsası dəqiqləşdirmək yaxşıdır; yanlışlığı sübut olunmuş iradı və ya tapşırığa aid olmayan məsləhəti rədd etmək olar.

Tapıntısız hesabat da bu yoxlamadan keçə bilər. Məsələn: "index.html və app.js-də əlavə etmə və silmə yolları, eyni adlı qeydlərin asılı olmaması və sayğacın yenilənməsi yoxlanıldı. Bu meyarlar üzrə problem tapmadım; brauzerdə işə salmadım". Belə yekun layihədə heç bir xəta olmayacağını vəd etmir. O, adı çəkilən hədlər daxilində nəticəni bildirir, lazım gələrsə, əsas yolları özünüz tutuşdurursunuz.

Amma "Göstərilən yolda app.js-i tapmadım, silmənin davranışını yoxlaya bilmədim" xətanın olmaması yox, məlumat çatışmazlığı deməkdir. Burada düzgün yolu ötürüb yoxlamanı davam etdirmək lazımdır. Qısa, dürüst cavab boşluğu gizlədən uzun hesabatdan daha faydalıdır.

Hesabatı qəbul etmək sadalananların hamısını düzəltməyi tapşırmaq demək deyil. Siz yoxlamanın nəticəsini əsaslı saydınız; indi hansı dəyişiklikləri etmək lazım olduğuna ayrıca qərar verirsiniz.

5. Nə vaxt daha bir keçid lazımdır

Hesabatda əsaslandırma çatışmırsa, review-nu yenidən başlamaq vacib deyil. Konkret boşluğu geri qaytarın. Məsələn, sayğac tapıntısının qısaldılmış variantında çağırışların təhlili olmadan yalnız xətanın adı var. Onda əsas agentə sorğu belə ola bilər:

Hesabatı dəqiqləşdirmək üçün reviewer-ə qaytar: sayğac tapıntısında
silmədən sonra onun yenilənmə yolu göstərilməyib.
Qoy bu yolu yoxlasın və nəticə üçün əsas əlavə etsin.
Kodu dəyişməsin.

Yenilənmənin artıq başqa funksiyada baş verdiyi aydın olsa, iradı geri götürmək lazımdır. Əvvəlki bənd sayını saxlamaq xatirinə ona əvəz axtarmayın. Xəta təsdiqlənsə, konkret tapıntını və dəyişikliklərin icazəli həcmini göstərərək düzəlişi ayrıca sorğu ilə əsas agentə tapşırmaq olar.

Düzəlişdən sonra eyni brif üzrə daha bir keçid faydalıdır:

reviewer-ə REVIEW_BRIEF.md faylını yenidən oxumağı və silmə ilə
sayğacın cari kodunu yoxlamağı tapşır. Əvvəlki tapıntı:
silmədən sonra sayğac yenilənmirdi.
Qoy problemin aradan qalxıb-qalxmadığını və nəticənin nəyə əsaslandığını göstərsin,
həmçinin eyni adlı qeydlərin bir-birindən asılı olmamasının
pozulmadığını yoxlasın. Kodu dəyişməsin.

İndi konkret sualın cavabını axtarırıq: problem aradan qalxıbmı və düzəlişin toxuna biləcəyi qonşu davranış pozulmayıbmı. Səhifədəki davranışı təsdiqləmək üçün eyni ssenarini brauzerdə təkrarlayın. Təkrar review yalnız kod üzrə aparılıbsa, bu məhdudiyyət yeni hesabatda da qalır.

Hesabat qısala, uzana və ya yeni tapıntısız ola bilər. Uğur bunda deyil. Vacib olan budur ki, əvvəlki qüsur aradan qalxsın, nəticə cari koda əsaslansın, yoxlanmamış hissələr isə görünən qalsın. Düzəlişi təxirə salmağa qərar verdiniz? Onda təsdiqlənmiş tapıntını və təxirin səbəbini saxlayın; dəyişməmiş kodun review-nu yalnız yeni cavab xatirinə təkrarlamağın mənası yoxdur.

6. Tapşırıqdan yoxlanmış nəticəyə

Claude Code ilə işdə əsas agent tapşırığı rəyçiyə ötürərkən brif gözləntinizi qoruyub saxlamağa kömək edir. Daimi format cavabı oxumağı asanlaşdırır. Amma yenə də iştirak etməli olacaqsınız, həm də belə:

• əsas agent tapşırığı tərtib edir və uyğun rola ötürür; gözlənilən davranışı və sərhədləri siz müəyyən edirsiniz;
• rəyçi faylları öyrənir və nəticələrinin əsaslarını qaytarır; əhatəni və vacib tapıntıları isə artıq siz yoxlayırsınız;
• əsas agent ayrıca tapşırıqla hesabatı dəqiqləşdirə və ya təsdiqlənmiş xətanı düzəldə bilər; nəyi dəyişməyi və nəticəni necə təsdiqləməyi siz həll edirsiniz.

Alış-veriş siyahısı üçün yekun sadəcə "funksiya çağırışı əlavə et" məsləhəti yox, yoxlanmış izah olacaq: hansı hərəkətdə say köhnəlirdi, yenilənmə harada pozulurdu və düzəlişdən sonra nə dəyişdi. Belə nəticə ilə artıq işləmək olar.