Sebagian besar website ini ditulis oleh agen AI. Saya yang merencanakan, mereka yang membangun, lalu saya yang mereview. Setelah beberapa bulan, saya melihat pola yang sama di catatan rilis saya: jenis bug yang sama terus muncul lagi. Handler baru berjalan lebih lama dari batas write timeout server (15 detik), lalu nginx menjawab 502. Saya memperbaikinya di v0.17.1, lalu di v0.17.2, lalu di v0.35.1, dan sekali lagi di v0.37.7. Setiap kali, agen yang merencanakan handler itu juga yang mereviewnya, di sesi yang sama, dengan asumsi yang sama: "panggilan ini cepat."

Itulah masalah yang mau diselesaikan Elephant-Goldfish Model (EGM) dari Google. Google merilisnya sebagai open source pada 22 Oktober 2026, berupa plugin untuk Claude Code, Codex, Antigravity, dan beberapa harness agen lain. Saya membaca repositorinya, pengumuman resminya, esai asli Dave Rensin, dan beberapa ulasan yang bagus, lalu menjalankannya pada perubahan nyata di situs ini. Catatan ini adalah tutorial yang saya cari waktu mulai: apa itu EGM, cara memakainya langkah demi langkah, apa yang ditemukannya di setup saya sendiri, dan di mana kelemahannya.

Idenya dalam satu paragraf

Sesi agen yang panjang pelan-pelan menyerap asumsi kita. Setelah dua jam mendengar "edge sudah meneruskan path itu", agen berhenti mempertanyakannya. EGM membagi pekerjaan menjadi tiga peran:

  • Elephant (gajah): sesi panjang yang kaya konteks. Ia memegang memori proyek dan keputusan-keputusannya, lalu menulis dokumen desain. Ia tidak menulis kode.
  • Goldfish (ikan mas koki): sesi baru tanpa ingatan. Masing-masing hanya menerima dokumen desain dan file yang ditautkan di dalamnya, lalu mereviewnya. Kalau Goldfish tidak bisa memahami rencana dari dokumen itu saja, dokumennya belum selesai.
  • Kita sendiri: yang memutuskan trade-off, memilih temuan mana yang penting, dan menyetujui desain sebelum apa pun dibangun.

Rensin merangkumnya dalam dua kalimat di esainya: "Design is the new code" dan "Feed the Elephant; test it against the Goldfish." Walaupun namanya begitu, EGM bukan model AI. Isinya Markdown: skill, persona reviewer, dan rubrik review, berlisensi Apache 2.0. README-nya juga terus terang menyebut bahwa ini "not an officially supported Google product".

Isi paketnya

Plugin ini punya tiga lapisan.

Tujuh skill (perintah yang kita jalankan):

  • egm-brainstorm: menjelajahi ide dengan aturan tanpa kode; enam Goldfish dengan sudut pandang berbeda menantang ide itu; hasilnya concepts_brief.md.
  • egm-draft: mengubah brief atau catatan menjadi dokumen desain, satu bagian per langkah, berhenti untuk minta persetujuan di setiap bagian.
  • egm-review: protokol Goldfish, lima tahap (lihat di bawah).
  • egm-review-loop: dispatcher yang menjalankan sekelompok reviewer secara paralel; dipakai oleh egm-review.
  • egm-resolve: mengolah temuan; setiap temuan diklasifikasikan propose fix atau contest, dan hanya perubahan yang disetujui yang diterapkan.
  • egm-bootstrap: menulis README.md per direktori dari bawah ke atas, untuk codebase tanpa dokumentasi (Rensin menyebut README ini "peanuts and hay", pakan untuk si gajah).
  • egm-drift-report: membandingkan dokumen desain dan README dengan kode terkini, lalu menandai yang sudah melenceng.

Sembilan persona di agents/: zoom-out, comprehension, design critic, structural, style, implementation readiness, codebase details, synthesizer yang menyebar reviewer lalu menggabungkan temuannya, dan bootstrap orchestrator.

Standar dokumen di resources/document_standards/: rubrik yang dipakai para reviewer. Dua di antaranya layak dikutip karena mengubah cara saya menulis rencana. Standar spesifikasi fitur punya Alternatives Rule: spesifikasi gagal kalau hanya mengusulkan satu jalan tanpa membuktikan bahwa desain lain sudah dipertimbangkan dan ditolak dengan alasan jelas. Standar kesiapan implementasi punya Zero-Decision Rule: rencana tidak boleh menyisakan satu pun keputusan desain atau arsitektur untuk orang yang mengimplementasikan.

Lima tahap review

egm-review menjalankan tahap-tahap ini berurutan, masing-masing dengan subagen baru:

  1. Initial Zoom Out: apakah ini desain paling sederhana? YAGNI, memakai ulang kode yang sudah ada.
  2. Comprehension Test: pembaca naif menceritakan ulang desainnya. Kalau ceritanya keliru, dokumennya ambigu. Tahap ini sengaja tidak diberi rubrik.
  3. Critic Review: reviewer design critic, structural, dan style bekerja paralel: mode kegagalan, batas skala, alternatif yang terlewat.
  4. Intermediate Zoom Out: memeriksa ulang apa saja yang ditambahkan karena tahap sebelumnya, supaya perbaikan tidak membuat desain membengkak.
  5. Implementation Readiness: apakah path file, signature, dan test case cukup spesifik untuk langsung diterjemahkan jadi kode?

Temuan diberi tingkat 🔴 Blocker, 🟡 Major, atau 🟢 Nit, lalu digabung dalam satu laporan konsolidasi dengan traceability matrix. Ada dua aturan di skill ini yang menarik perhatian saya. Pertama, laporan ditulis ke file, tidak pernah ditumpahkan ke chat ("chat dump prohibition"). Kedua, kalau harness tidak bisa membuat subagen dengan konteks baru, review berhenti, karena review dalam konteks yang sama bukan review Goldfish.

Tutorial: instal dan jalankan

1. Instal plugin secara utuh

Di Claude Code (versi 2.1.271 ke atas; dokumentasi plugin memintanya supaya reviewer bisa dijalankan tanpa CLAUDE.md kita):

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm
# hanya kalau setup kamu butuh aktivasi:
claude plugin enable egm@egm

Di Codex:

codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm

Di Antigravity: agy plugin install https://github.com/google/elephant-goldfish-model.

Instal plugin secara utuh, jangan hanya folder skills/, karena skill membaca persona dan standar saat berjalan. Lalu buka sesi baru, karena plugin dimuat saat sesi dimulai. Di Claude Code dan agy, perintahnya memakai awalan /egm:; di Codex pilih skill dari picker.

2. Brainstorm (opsional, untuk ide yang masih kabur)

/egm:egm-brainstorm Add webhook delivery to this project.

Agen akan bertanya, menolak menulis kode, lalu menjalankan enam Goldfish untuk menyerang ide itu (untuk webhook: bagaimana kalau pengiriman gagal, atau event datang dua kali?). Arah yang disepakati disimpan di concepts_brief.md.

3. Tulis draf desain

/egm:egm-draft

Si Elephant menulis design_draft.md per bagian: overview, masalah, goals dan non-goals, pertanyaan terbuka, critical user journey (given/when/then), rencana teknis, alternatif, kebutuhan non-fungsional, dan Detailed Implementation Plan yang menyebut setiap file yang akan dibuat atau diubah. Ia berhenti di setiap bagian. Desain yang disetujui disimpan di docs/designs/<fitur>.md.

4. Review dengan para Goldfish

/egm:egm-review docs/designs/<fitur>.md

Pilih preset: interaktif (berhenti setiap tahap), konsolidasi (lima tahap sekaligus, satu laporan), hanya spesifikasi fitur, atau hanya rencana implementasi. Skill ini memotong dokumen di heading ## Detailed Implementation Plan: tahap 1 sampai 4 mereview bagian di atasnya, tahap 5 bagian di bawahnya. Siapkan diri untuk banyak output. Rensin memperkirakan hanya sekitar 30% saran Goldfish yang layak ditindaklanjuti. Itu wajar, bukan tanda gagal.

5. Selesaikan temuan, lalu libatkan manusia

Pilih Resolve findings with agent di checkpoint (atau jalankan egm-resolve), lalu terima atau bantah setiap temuan. Setiap tahap hanya boleh diaudit ulang sekali; sisanya dicatat sebagai trade-off yang diterima. Setelah itu buka pull request supaya ada orang yang mereview desainnya. EGM tidak menggantikan pengawasan manusia, justru mendorongnya.

6. Implementasi, lalu awasi drift

Baru sekarang agen coding mulai membangun dari dokumen yang sudah disetujui. Kalau hasilnya jauh meleset, saran Rensin: perbaiki dokumennya lalu mulai ulang, jangan berdebat dengan sesinya. Jalankan /egm:egm-drift-report tiap minggu untuk menangkap kode yang menjauh dari desainnya.

Untuk perbaikan satu baris, lewati semua ini. Panduan Google sendiri bilang begitu.

Contoh nyata: agen-agen di balik situs ini

Ini yang sudah dimiliki repositori ini sebelum EGM, dan padanannya:

  • CLAUDE.md, yang dimuat di setiap sesi, adalah memori si Elephant: stack, aturan wajib, dan log keputusan.
  • site-coordinator adalah agen pintu masuk yang membaca CLAUDE.md, memecah permintaan, lalu meneruskannya. Ini yang paling mirip dengan Elephant dan synthesizer EGM.
  • Empat spesialis yang mengimplementasikan: site-frontend-engineer, site-seo-specialist, site-security-engineer, dan site-deployer.
  • Empat skill proyek (site-spec, site-ops, site-seo, site-security) dan tujuh aturan (.claude/rules/: mock first, motion, penamaan bahasa Inggris, tanpa rahasia, alur git, katalog gRPC, keamanan) berfungsi sebagai rubrik.

Yang sudah bagus: aturannya berupa cek yang konkret ("endpoint admin baru menambah baris di katalog gRPC", "setiap href lewat Site.safeUrl"), coordinator adalah titik fan-out yang alami, dan setiap agen wajib melaporkan apa yang sudah diverifikasi beserta perintahnya.

Yang jadi jelas kurang setelah membaca EGM:

  • Tidak ada review tanpa konteks. Setiap rencana direview oleh penulisnya sendiri, di konteks yang sama. Karena itulah bug 502 kembali empat kali.
  • Keputusan ditulis setelah kejadian. Desain sebuah fitur hanya ada di chat sampai fiturnya rilis; baru setelah itu ada satu butir ringkasan di CLAUDE.md. Tidak ada desain yang bisa direview sebelum kode ditulis.
  • Elephant yang terus membesar. Per 3 November 2026, CLAUDE.md berisi 74 butir keputusan, sekitar 61 KB atau kira-kira 15.000 token yang dimuat di setiap sesi, dan menyebut 107 path kode yang tidak pernah dicek. Strukturnya bahkan pernah rusak: butir satu rilis tertempel di tengah kalimat butir rilis lain.
  • Satu model untuk semuanya. Semua agen berjalan di model sesi yang sama, jadi reviewer yang konteksnya baru pun tetap mewarisi kebiasaan si penulis.

Uji coba: Goldfish mereview setup saya sendiri

Supaya ujinya jujur, saya meminta EGM mereview perubahan pada setup ini sendiri. Sebagai Elephant, saya menulis docs/designs/goldfish-review-stage.md dengan template EGM. Desainnya punya tiga bagian: agen reviewer tanpa konteks, langkah design-first di coordinator, dan skrip make drift yang mengecek setiap path yang disebut di CLAUDE.md. Lalu, di sesi baru:

/egm:egm-review docs/designs/goldfish-review-stage.md uninterrupted

uninterrupted adalah preset konsolidasi: lima tahap, tanpa checkpoint, satu laporan akhir. Prosesnya sekitar sepuluh menit dan menjalankan sembilan subagen reviewer: zoom-out dua kali, comprehension sekali, tiga critic, dan tiga reviewer kesiapan. Hasilnya enam file laporan di root repo.

Satu catatan praktis: saya sempat mencoba menjalankannya headless dengan claude -p, dan langsung gagal ("OAuth session expired") karena proses anak tidak ikut memakai login sesi interaktif. Jalankan saja di sesi biasa.

Hasilnya

Sebelum deduplikasi, semua tahap menghasilkan 3 Blocker, 31 Major, dan 42 Nit. Laporan konsolidasi menggabungkannya menjadi 3 Blocker, 9 Major, dan 6 kelompok Nit, masing-masing bisa dilacak ke temuan aslinya. Vonisnya lugas: "Not ready to implement." Ide intinya bertahan di semua tahap. Detailnya tidak.

Temuan yang benar-benar penting:

  • 🔴 Coordinator tidak bisa menulis file. Di desain saya, site-coordinator yang menulis dokumen desain, padahal baris tools-nya Bash, Read, Grep, Glob, Agent, Skill: tanpa Write, tanpa Edit. Saya sudah berminggu-minggu bekerja dengan agen itu dan tidak pernah sadar. Reviewer-nya mengecek file aslinya.
  • 🔴 make drift akan gagal di percobaan pertama. CLAUDE.md memuat ` backend/db/apply.sh --schema-only ` lima kali. Ekstraktor saya akan menganggap seluruh perintah itu sebagai path dan melaporkannya hilang. Ada juga lima daftar kurung kurawal dengan opsi kosong yang tidak didefinisikan oleh langkah "expand braces" saya. Saran reviewer Zoom Out: keluarkan saja drift check dari desain ini.
  • 🔴 Tidak ada bagian Risks. Standar spesifikasi fitur mewajibkannya, dan saya melewatkannya.
  • 🟡 Goldfish saya ternyata bukan goldfish. Saya menulis bahwa input reviewer "hanya prompt", padahal subagen Claude Code biasa tetap memuat CLAUDE.md, seluruh 15.000 token memori si Elephant. Solusinya omitClaudeMd: true di frontmatter agen, persis yang dipakai persona reviewer EGM sendiri. Saya hampir membuat kesalahan yang sama saat menjalankan eksperimen ini: ketika run headless gagal, ide pertama saya adalah meniru tahap-tahapnya dengan subagen biasa. Mereka akan membaca CLAUDE.md saya.
  • 🟡 Bug yang jadi alasan utama tidak tercakup aturan mana pun. Seluruh argumen saya berangkat dari 502 yang rilis empat kali, tapi tidak ada file aturan yang menyebut write timeout. Reviewer yang memakai aturan saya sebagai rubrik juga akan melewatkannya. Perbaikannya ada di .claude/rules/site-security.md.
  • 🟡 Batas "fitur atau perbaikan" masih berstatus pertanyaan terbuka, padahal langkah coordinator bergantung padanya seolah sudah pasti. Salah satu kriterianya, "lebih dari 3 file", bahkan tidak bisa diketahui sebelum desainnya ada.
  • 🟡 Tes pemahaman menemukan alur yang tidak terdefinisi. Saya menulis apa yang terjadi sebelum saya menyetujui, tapi tidak untuk kasus ditolak atau setelah diedit, dan coordinator hanya akan menampilkan temuan, bukan parafrasenya. Padahal parafrase itulah cara kita mengecek apakah reviewer memahami maksud kita.

Parafrase dari reviewer Comprehension akurat, jadi dokumennya lolos tes dasar "bisakah orang asing mengikutinya". Enam Major darinya semuanya ada di bagian yang saya andalkan dari ingatan sendiri tanpa pernah ditulis: arti "Elephant", siapa yang menulis laporan, dan apa arti "memperbaiki drift" di butir riwayat.

Apa yang saya lakukan

Saya menerapkan ke-12 action item dalam satu revisi. Drift check dipindah ke "Future Improvements" bersama tiga jebakan yang ditemukan reviewer. Reviewer dibuat read-only lewat daftar tools-nya, bukan sekadar instruksi. Coordinator mendapat Write/Edit yang dibatasi ke docs/designs/. Pelajaran 502 dijadikan aturan. Para reviewer juga menolak lima saran mereka sendiri di tahap 8 (misalnya permission hook untuk file rahasia), lengkap dengan alasannya. Di situlah tahap Intermediate Zoom Out bekerja: mencegah perbaikan hasil review membuat desain membengkak.

Sinyal dan noise: sebagian besar dari 42 Nit hanya soal kata-kata ("fresh eyes", panah di dalam kalimat, footer yang tersesat). Dari 76 temuan mentah, kira-kira seperempat benar-benar mengubah desain, dekat dengan perkiraan Rensin yang "sekitar 30%". Tiga di antaranya bug yang baru akan saya temukan saat implementasi, dan satu (tool Write yang tidak ada) akan muncul sebagai kegagalan membingungkan di tengah sesi.

Yang saya ubah (dan yang bisa kamu tiru)

Desain yang sudah direview menambahkan separuh Goldfish yang hilang ke setup saya, tanpa menjadikan plugin itu dependensi:

  • Agen site-goldfish-reviewer dengan tools: Read, Grep, Glob dan omitClaudeMd: true. Ia hanya menerima path dokumen desain, membaca dokumen itu, file yang ditautkan, dan semua aturan di .claude/rules/, lalu mengembalikan parafrase plus temuan 🔴/🟡/🟢 yang disimpan coordinator di docs/designs/reviews/.
  • Design first, hanya untuk fitur. Ada daftar pemicu yang tetap: endpoint atau RPC baru, halaman atau tab admin baru, migrasi, host pihak ketiga baru, agen, skill, atau aturan baru. Kalau salah satu cocok, coordinator menulis docs/designs/<fitur>.md, menjalankan reviewer, menunjukkan parafrase dan temuan 🔴/🟡 ke saya, dan baru meneruskan pekerjaan setelah saya setujui. Perbaikan bug tetap memakai alur lama.
  • Aturan baru untuk handler yang berjalan lama (perpanjang write deadline atau jalankan async), supaya bug yang memulai semua ini akhirnya bisa dicek reviewer.
  • Drift check untuk CLAUDE.md menunggu desainnya sendiri, karena review menunjukkan ternyata lebih rumit dari kelihatannya.

Pelajaran umum yang berlaku untuk setup agen apa pun:

  1. Jadikan aturan sebagai rubrik. Goldfish tanpa acuan hanya menghasilkan opini. Punya saya mengecek terhadap tujuh file aturan.
  2. Tambahkan reviewer keamanan. EGM tidak membawanya. Kalau desainmu menyentuh autentikasi, token, atau input pengguna, buat personanya (reviewer kustom cukup berupa file Markdown dengan nama dan deskripsi).
  3. Pastikan Goldfish-mu benar-benar goldfish. Di Claude Code, subagen memuat CLAUDE.md kecuali frontmatter-nya berisi omitClaudeMd: true. Isolasi juga hanya soal konteks, bukan filesystem: Goldfish yang punya Read dan Grep bisa membaca file mana pun di repo. Sebutkan file yang terlarang (.env, rahasia deploy) dan keluarkan dari cakupannya.
  4. Kalau bisa, pakai model lain untuk reviewer. Konteks baru menghapus transkrip kita, bukan titik buta modelnya. Di Claude Code, frontmatter agen bisa mengatur model.
  5. Jaga si Elephant tetap ramping. Kalau CLAUDE.md sudah jadi changelog, setiap sesi ikut membayarnya. Pindahkan riwayat ke dokumen desain, dan sisakan aturan serta keputusan yang masih berlaku.

Catatan kritis

  • Tidak resmi, tidak terukur. Klaim "ribuan engineer Google memakainya" datang dari Google sendiri; baik repo maupun pengumumannya tidak menerbitkan angka produktivitas.
  • Independensinya hanya sebagian. Secara default, reviewer di Claude Code mewarisi model sesi. Digital Applied menyebutnya dengan tepat: konteks baru mengurangi bawaan transkrip, bukan kelemahan di level model.
  • Butuh token dan waktu. Satu siklus penuh terdiri dari brainstorm enam sudut pandang, draf per bagian, lima tahap review, dan PR untuk manusia. Review menjalankan banyak subagen; seorang penguji bahkan kena rate limit di Claude Cowork.
  • Dokumen jadi codebase kedua. Folder docs/designs/ yang tidak pernah dibaca lebih buruk daripada tidak ada. Laporan drift hanya membantu kalau ada yang menjalankannya.
  • Butuh subagen. Harness yang tidak bisa mendelegasikan ke konteks baru memang tidak bisa menjalankan review Goldfish sama sekali, dan itu disengaja.

Pendapat saya: seremoninya terlalu berat untuk sebagian besar yang saya rilis, tapi langkah intinya murah dan berhasil. Tuliskan rencananya, serahkan ke seseorang yang tidak ingat percakapanmu, dan dengarkan ketika ia tidak bisa mengikutinya.

Sumber

Pembaruan, 4 November 2026

Sehari setelah catatan ini terbit, saya menjalankan Goldfish pada setup yang saya bangun dari catatan ini, lalu memperbaiki temuannya. Dua poin di atas kini sudah usang: desainnya sudah diimplementasikan, dan celah "Satu model untuk semuanya" serta butir "drift check menunggu" tidak berlaku lagi seperti tertulis.

Goldfish mereview desainnya sendiri. Saya menjalankan site-goldfish-reviewer pada dokumen desain yang melahirkannya: tanpa blocker, 6 major, 6 nit. Major-nya jenis yang tidak terlihat oleh saya sendiri. Dokumen tertulis "Implemented" padahal belum ada pengecekannya yang dijalankan. Isolasi bertumpu pada satu kunci frontmatter dan pengakuan model bahwa ia tidak membaca CLAUDE.md. Kasus gagal belum ada (laporan rusak, menyetujui saat blocker masih terbuka, review saling menimpa). "Endpoint yang berubah" terlalu kabur untuk diterapkan. Akses tulis coordinator hanya dibatasi satu kalimat di prompt-nya. Dan aturan handler panjang belum pernah diuji.

Yang berubah

  • Reviewer memakai model yang dipatok. Keduanya dipatok ke Opus, bukan model sesi. Kalau sesi saya sudah memakai Opus, modelnya sama; itu saya terima.
  • Reviewer kedua untuk keamanan. site-goldfish-security berjalan di samping yang pertama kalau desain menyentuh autentikasi, token, input pengguna, field rahasia, endpoint baru atau yang berubah, origin baru, atau handler yang berjalan lama. Ia punya skala keparahan dan format temuan yang tetap. Sebagian strukturnya saya adopsi dari agen-agen di repositori privat saya yang lain.
  • Isolasi diuji, bukan diasumsikan. Saya menanam satu baris unik di CLAUDE.md lalu menjalankan kedua reviewer: baris itu tidak muncul di laporan mana pun. Aturan izin menolak pembacaan file uji .env, dan pencarian isinya tidak mengembalikan apa-apa. Reviewer keamanan juga menemukan bahwa repo ini sama sekali belum punya .gitignore. Sekarang sudah ada.
  • Yang tidak bisa dibuktikan oleh tes ini. Mengeluarkan CLAUDE.md dari pencarian reviewer hanyalah instruksi, bukan blokir keras, dan pembacaan file yang tidak pernah ditampilkan akan lolos dari tes penanda.
  • Elephant-nya sudah ramping. CLAUDE.md turun dari 409 baris (61 KB) menjadi 79 baris (9,7 KB). Ke-66 butir riwayat per rilis dipindahkan apa adanya ke docs/history/, dikelompokkan per area, dan yang masih berlaku tetap ada di daftar singkat "Current rules". Sebuah skrip memeriksa bahwa ke-344 baris aslinya masih ada semua. Pemindahan itu punya desainnya sendiri, dan Goldfish mereviewnya dua kali (satu blocker dan sepuluh major, lalu satu blocker dan enam major) sebelum saya menyentuh satu file pun.

Pemeriksa drift sudah dibuat. make drift adalah skrip Node kecil yang juga dijalankan oleh make test. Skrip ini gagal kalau sebuah path atau tautan di CLAUDE.md sudah tidak ada, atau kalau file melewati 140 baris atau 15.000 byte. Jebakan yang dulu membuat saya mencoretnya dari desain pertama justru jadi hal pertama yang saya tulis tesnya: perintah dengan argumen, daftar kurung kurawal dengan opsi kosong, dan path singkat. Goldfish juga mereview desain ini dan menemukan blocker yang terlewat oleh saya: daftar file git masih menampilkan file yang diganti namanya dengan mv biasa sampai file itu di-stage, jadi kasus yang justru menjadi alasan alat ini ada akan lolos. Dijalankan pada CLAUDE.md lama yang 409 baris, skrip ini menandai satu rujukan ke blog.html yang sudah basi. Batasnya: ia memeriksa bahwa nama itu ada, bukan bahwa kalimat di sekitarnya masih benar, dan nama yang ada dua kali (misalnya README.md) tetap lolos selama satu salinan masih ada.

Pelajaran yang akan saya tambahkan: jalankan reviewer pada setup-nya sendiri lebih dulu. Ia menemukan lebih banyak di desain reviewer itu daripada saya.

Baca juga