Catatan Penulis: Saya telah mengumpulkan 25 petunjuk Code Review untuk Claude Code yang telah teruji di lapangan, mencakup 7 skenario utama seperti tinjauan keamanan, analisis performa, tinjauan arsitektur, deteksi bug, PR Review, dan banyak lagi, lengkap dengan rumus penulisan petunjuk.
Claude Code hadir dengan perintah bawaan /security-review dan sistem multi-agen untuk Code Review, namun output tinjauan default sering kali terlalu bertele-tele dan membahas hal-hal yang tidak perlu. Petunjuk Review yang baik haruslah presisi seperti kasus uji—mendefinisikan cakupan, menetapkan prioritas, serta meminta baris kode spesifik dan saran perbaikan. Artikel ini merangkum 25 petunjuk Code Review yang mencakup 7 skenario utama, mulai dari tinjauan keamanan hingga tinjauan arsitektur, yang semuanya bisa langsung Anda salin dan gunakan.
Nilai Inti: 25 petunjuk yang mencakup skenario Code Review paling sering ditemui, disertai rumus penulisan petunjuk serta perbandingan antara yang baik dan buruk.
Ulasan Rumus Penulisan Petunjuk
Petunjuk ulasan yang baik itu presisi seperti kasus uji. Petunjuk ulasan yang buruk itu seperti pesan Slack yang samar.
Rumus Lima Elemen
[Peran] Sebagai insinyur {bahasa/bidang} senior
[Cakupan] Tinjau {file/direktori/PR} dari {konten perubahan}
[Fokus] Fokus pada {keamanan/performa/logika/arsitektur}
[Format] Format output: {daftar bernomor/tabel/komentar inline}
[Level] Tandai tingkat keparahan: {Critical/High/Medium/Low}
| Elemen | Contoh Buruk | Contoh Baik |
|---|---|---|
| Peran | (Tidak diatur) | "Sebagai insinyur backend senior" |
| Cakupan | "Lihat kode ini" | "Tinjau git diff terbaru di src/auth/" |
| Fokus | "Berikan masukan" | "Fokus pada injeksi SQL dan bypass autentikasi" |
| Format | (Output bebas) | "Daftar bernomor, setiap item berisi file:nomor baris, deskripsi masalah, saran perbaikan" |
| Level | (Tidak diminta) | "Tandai Critical/High/Medium/Low" |
Skenario 1: Tinjauan Keamanan (4 Petunjuk)
Tinjauan keamanan adalah skenario dengan prioritas tertinggi dalam Code Review. Claude Code sudah dilengkapi perintah /security-review, tetapi petunjuk kustom bisa memberikan hasil yang lebih mendalam.
Petunjuk #1: Pemindaian Komprehensif OWASP Top 10
Sebagai insinyur audit keamanan, tinjau semua file yang baru diubah di direktori src/.
Periksa satu per satu berdasarkan OWASP Top 10:
1. Injeksi (SQL/NoSQL/Injeksi perintah)
2. Cacat autentikasi
3. Paparan data sensitif
4. XXE
5. Cacat kontrol akses
6. Kesalahan konfigurasi keamanan
7. XSS
8. Deserialisasi
9. Penggunaan komponen dengan kerentanan
10. Pencatatan dan pemantauan yang tidak memadai
Format output: Daftar bernomor, setiap item berisi [file:nomor baris] [tingkat keparahan] [deskripsi masalah] [saran perbaikan].
Hanya laporkan masalah yang benar-benar ada, jangan laporkan risiko teoretis.
Petunjuk #2: Tinjauan Keamanan Endpoint API
Tinjau semua file rute API (routes/, controllers/), fokus pada pemeriksaan:
- Apakah ada endpoint yang kehilangan middleware autentikasi
- Apakah parameter sudah divalidasi dan dibersihkan
- Apakah ada risiko penugasan massal (mass assignment)
- Apakah pembatasan laju (rate limiting) sudah dikonfigurasi
- Apakah respons kesalahan membocorkan informasi internal
Format tabel: Jalur endpoint | Masalah | Tingkat keparahan | Solusi perbaikan
Petunjuk #3: Deteksi Kebocoran Informasi Sensitif
Pindai seluruh proyek, periksa apakah informasi sensitif berikut di-hardcode atau tidak sengaja terekspos:
- Kunci API, Secret, Token
- String koneksi database
- Kunci privat dan sertifikat
- IP dan domain internal
- Kata sandi atau kredensial di dalam komentar
Cakupan pemeriksaan meliputi: kode sumber, file konfigurasi, .env.example, docker-compose.yml, README
Tandai jalur file dan nomor baris untuk setiap temuan.
Petunjuk #4: Tinjauan Logika Autentikasi dan Otorisasi
Sebagai pakar keamanan, tinjau kode terkait autentikasi dan otorisasi:
1. Apakah logika verifikasi token JWT lengkap (kedaluwarsa, tanda tangan, manipulasi)
2. Apakah penyimpanan kata sandi menggunakan hashing yang aman (bcrypt/argon2)
3. Apakah manajemen sesi memiliki risiko serangan sesi tetap (fixed session)
4. Apakah konfigurasi CORS terlalu longgar
5. Apakah callback OAuth memverifikasi parameter state
Hanya laporkan masalah tingkat Critical dan High, sertakan contoh kode perbaikan.
Skenario 2: Deteksi Bug (4 Petunjuk)
Petunjuk #5: Pointer Null dan Kondisi Batas
Tinjau file yang baru diubah, cari potensi Bug berikut:
- Akses properti tanpa memeriksa null/undefined
- Akses indeks di luar batas array (out-of-bounds)
- Kesalahan pembagian dengan nol
- String kosong yang tidak ditangani
- parseInt/parseFloat yang tidak menangani NaN
Untuk setiap temuan, berikan kondisi pemicu (input apa yang menyebabkan crash) dan kode perbaikannya.
Petunjuk #6: Masalah Asinkron dan Konkurensi
Tinjau semua kode asinkron dalam proyek (async/await, Promise, callback), periksa:
- Apakah ada Promise tanpa penanganan error catch
- Apakah ada race condition
- Apakah ada await di dalam loop yang menyebabkan eksekusi serial (seharusnya menggunakan Promise.all)
- Apakah ada callback hell yang bisa direfaktor
- Apakah transaksi menangani rollback dengan benar
Tandai dengan [File:Nomor Baris] [Masalah] [Dampak] [Solusi Perbaikan]
Petunjuk #7: Pemburu Kesalahan Logika
Baca dengan teliti logika bisnis fungsi berikut, cari:
- Apakah cabang if/else sudah mencakup semua kondisi
- Apakah kondisi terminasi loop sudah benar
- Apakah operator perbandingan sudah tepat (== vs ===, > vs >=)
- Apakah cakupan variabel (scope) sudah benar
- Apakah nilai kembalian (return value) sudah didefinisikan di semua jalur
Jangan fokus pada gaya penulisan kode, fokuslah hanya pada kebenaran logika.
Petunjuk #8: Tinjauan Penanganan Error
Tinjau mekanisme penanganan error proyek:
1. Apakah blok try/catch menangkap pengecualian spesifik, bukan Error generik
2. Apakah blok catch hanya menelan error (catch kosong)
3. Apakah error disebarkan ke lapisan atas dengan benar
4. Apakah pesan error yang terlihat oleh pengguna sudah ramah (tidak mengekspos informasi internal)
5. Apakah operasi kritis (pembayaran, perubahan data) memiliki mekanisme rollback jika gagal
Urutkan output berdasarkan tingkat keparahan.
Skenario 3: Analisis Performa (3 Petunjuk)
Petunjuk #9: Performa Kueri Basis Data
Tinjau semua kode kueri basis data (models/, repositories/, panggilan ORM), periksa:
- Masalah kueri N+1 (menjalankan kueri di dalam loop)
- Bidang kueri yang tidak memiliki indeks
- Apakah SELECT * harus diganti dengan bidang spesifik
- Apakah kueri data besar memiliki penomoran halaman (pagination)
- Apakah ada kueri berulang yang bisa dioptimalkan dengan cache
Untuk setiap masalah, perkirakan dampak performa (rendah/sedang/tinggi), dan berikan kode yang telah dioptimalkan.
Petunjuk #10: Kebocoran Memori dan Sumber Daya
Tinjau kemungkinan kebocoran memori dan sumber daya dalam proyek:
- Apakah pendengar acara (event listener) dihapus saat komponen dilepas
- Apakah timer (setInterval/setTimeout) dibersihkan
- Apakah koneksi basis data ditutup dengan benar
- Apakah handle file dilepaskan di dalam finally
- Apakah array/objek besar dibatalkan referensinya setelah digunakan
Fokus pada pembersihan useEffect di komponen React dan pemrosesan stream di Node.js.
Petunjuk #11: Tinjauan Kompleksitas Algoritma
Tinjau fungsi yang baru diubah, analisis kompleksitas waktu dan ruang:
- Apakah ada implementasi O(n²) atau lebih tinggi yang bisa dioptimalkan
- Apakah ada tempat yang bisa menggunakan hash map sebagai pengganti pencarian linear
- Apakah ada deep copy yang tidak perlu
- Apakah penggabungan string harus menggunakan StringBuilder/join
- Apakah pengurutan menggunakan algoritma yang tepat
Tandai dengan Kompleksitas saat ini → Kompleksitas yang bisa dicapai → Solusi optimasi spesifik.
Skenario 4: Tinjauan Arsitektur (4 petunjuk)
Petunjuk #12: Analisis Dependensi dan Kopling
Analisis hubungan dependensi modul di src/:
1. Gambarkan diagram dependensi antar modul (modul mana yang mengimpor modul apa)
2. Temukan dependensi melingkar (circular dependency)
3. Temukan modul dengan tingkat kopling tertinggi (paling banyak diandalkan oleh modul lain)
4. Sarankan dependensi mana yang harus dipisahkan (decoupling) melalui interface/abstraksi
Output: Tabel hubungan dependensi + daftar dependensi melingkar + saran pemisahan.
Petunjuk #13: Pemeriksaan Kepatuhan Arsitektur Berlapis
Periksa apakah kode mematuhi prinsip arsitektur berlapis:
- Apakah layer Controller berisi logika bisnis (seharusnya hanya menangani routing dan validasi parameter)
- Apakah layer Service langsung mengoperasikan database (seharusnya melalui Repository)
- Apakah layer Model/Entity berisi logika terkait HTTP
- Apakah ada pemanggilan lintas layer (Controller langsung memanggil Repository)
Cantumkan setiap file yang melanggar prinsip arsitektur berlapis beserta lokasi kode spesifiknya.
Petunjuk #14: Tinjauan Desain API
Tinjau semua endpoint API dari sudut pandang praktik terbaik desain RESTful API:
- Apakah penamaan URL mengikuti konvensi REST (kata benda jamak, hubungan hierarkis)
- Apakah penggunaan metode HTTP sudah benar (GET untuk baca, POST untuk buat, PUT untuk perbarui, DELETE untuk hapus)
- Apakah format respons konsisten (kode kesalahan, format paginasi, format waktu)
- Apakah kontrol versi API sudah memadai
- Apakah ada endpoint redundan yang bisa digabungkan
Output: Tabel saran perbaikan (Saat ini → Saran → Alasan)
Petunjuk #15: Penilaian Utang Teknis (Technical Debt)
Lakukan penilaian komprehensif terhadap utang teknis proyek:
1. Paket dependensi dan versi framework yang usang
2. Pemanggilan API yang sudah tidak digunakan (deprecated)
3. Nilai konfigurasi yang di-hardcode (seharusnya menggunakan variabel lingkungan)
4. Blok kode duplikat hasil copy-paste
5. Modul krusial yang kekurangan unit test
6. Fungsi yang terlalu kompleks (cyclomatic complexity > 15)
Urutkan berdasarkan urgensi perbaikan: Memblokir (harus segera diperbaiki) > Tinggi > Sedang > Rendah
Skenario 5: Tinjauan PR (4 petunjuk)
Petunjuk #16: Tinjauan Cepat PR Diff
Tinjau diff antara cabang saat ini dengan main, evaluasi dari sudut pandang insinyur senior:
1. Apa tujuan dari PR ini (simpulkan dari diff)
2. Apakah perubahan sudah lengkap (apakah ada file atau logika yang terlewat)
3. Apakah ada bug baru atau regresi yang diperkenalkan
4. Apakah cakupan pengujian (test coverage) sudah memadai
5. Apakah ada perubahan yang tidak perlu (kode debug, noise pemformatan)
Laporkan hanya masalah tingkat Tinggi dan Kritis. Jangan nit-pick gaya penulisan kode.
Petunjuk #17: Pemeriksaan Kompatibilitas Mundur (Backward Compatibility)
Tinjau semua perubahan pada PR saat ini, periksa apakah ada perubahan yang tidak kompatibel ke belakang:
- Apakah tanda tangan (signature) atau nilai balik interface API publik berubah
- Apakah skema database memiliki perubahan yang merusak (breaking change)
- Apakah format file konfigurasi berubah
- Apakah fungsi yang digunakan modul lain telah dihapus
- Apakah nama atau format variabel lingkungan berubah
Untuk setiap ketidakkompatibelan, evaluasi cakupan dampak dan rencana migrasinya.
Petunjuk #18: Tinjauan Kecukupan Pengujian
Bandingkan perubahan kode pada PR saat ini dengan perubahan pengujian:
1. Apakah fungsi baru sudah memiliki unit test yang sesuai
2. Apakah logika yang diubah sudah memperbarui pengujian yang ada
3. Apakah kondisi batas (boundary) dan jalur pengecualian sudah tercakup dalam pengujian
4. Apakah pengujian integrasi sudah mencakup endpoint API baru
5. Apakah data pengujian masuk akal (bukan sekadar 123, abc acak)
Cantumkan saran kasus uji yang hilang: Nama Fungsi | Skenario Pengujian yang Hilang | Prioritas
Petunjuk #19: Tinjauan Kualitas Commit
Tinjau riwayat commit pada PR saat ini:
1. Apakah pesan commit menjelaskan isi perubahan dengan jelas
2. Apakah setiap commit bersifat atomik (satu commit untuk satu tujuan)
3. Apakah ada commit sepele yang bisa di-squash
4. Apakah ada commit sementara seperti "fix typo", "wip" yang harus dibersihkan
5. Apakah urutan commit logis (infrastruktur dulu, baru logika bisnis)
Sarankan commit yang perlu dirapikan dan struktur commit akhir.
Skenario 6: Keterbacaan (3 petunjuk)
Petunjuk #20: Tinjauan Penamaan
Tinjau penamaan semua variabel, fungsi, dan kelas dalam file yang baru diubah:
- Apakah ada nama yang maknanya ambigu (data, info, temp, res, obj)
- Apakah ada singkatan yang berlebihan (usr → user, btn → button)
- Apakah ada penamaan nilai boolean yang tidak diawali dengan is/has/should
- Apakah nama fungsi diawali dengan kata kerja untuk mendeskripsikan perilaku secara akurat
- Apakah nama kelas diawali dengan kata benda untuk mendeskripsikan tanggung jawab secara akurat
Untuk setiap penamaan yang kurang baik, berikan nama alternatif yang lebih baik.
Petunjuk #21: Tinjauan Kualitas Komentar
Tinjau kualitas komentar dalam kode:
- Apakah ada komentar "apa" (what) yang seharusnya diubah menjadi komentar "mengapa" (why)
- Apakah ada komentar usang (tidak konsisten dengan kode)
- Apakah ada komentar yang seharusnya diekstrak menjadi nama fungsi
- Apakah logika bisnis yang kompleks kekurangan komentar penjelasan
- Apakah API publik memiliki JSDoc/docstring
Jangan sarankan penambahan komentar yang sudah jelas (seperti "// increment counter").
Petunjuk #22: Saran Pemecahan Fungsi
Tinjau semua fungsi yang melebihi 30 baris, evaluasi apakah perlu dipecah:
- Apakah fungsi memiliki banyak tanggung jawab (melakukan beberapa hal yang tidak relevan)
- Apakah tingkat bersarang (nesting) melebihi 3 lapis
- Apakah jumlah parameter melebihi 4
- Apakah ada logika berulang yang bisa diekstrak
Berikan rencana pemecahan yang konkret: fungsi asli → daftar fungsi setelah dipecah → tanggung jawab masing-masing fungsi.
Skenario 7: Saran Refaktorisasi (3 petunjuk)
Petunjuk #23: Deteksi Pelanggaran DRY
Pindai kode duplikat dalam proyek:
- Temukan blok kode duplikat lebih dari 3 baris
- Temukan kode dengan logika serupa namun penulisan berbeda
- Temukan pola publik yang bisa diekstrak menjadi fungsi utilitas
Untuk setiap kelompok kode duplikat, berikan implementasi kode konkret untuk diekstrak menjadi fungsi publik.
Petunjuk #24: Optimalisasi Pola Desain
Tinjau kode dari sudut pandang pakar pola desain:
- Apakah banyak if/else atau switch yang seharusnya menggunakan pola strategi (strategy pattern)
- Apakah pembuatan objek kompleks seharusnya menggunakan pola pabrik/pembangun (factory/builder pattern)
- Apakah kode templat yang berulang seharusnya menggunakan pola metode templat (template method pattern)
- Apakah callback bersarang banyak seharusnya menggunakan pola rantai tanggung jawab (chain of responsibility)
- Apakah manajemen status global seharusnya menggunakan pola pengamat (observer pattern)
Sarankan hanya jika peningkatan pola dapat secara signifikan mengurangi kompleksitas, jangan melakukan desain berlebihan.
Petunjuk #25: Modernisasi Kode Warisan
Tinjau kode warisan dalam proyek, temukan bagian yang bisa ditulis ulang dengan sintaks modern:
- var → const/let
- Callback function → async/await
- for loop → map/filter/reduce
- Penggabungan string → template string
- require → import
- Class → Function Component + Hooks (React)
Berikan perbandingan kode sebelum dan sesudah refaktorisasi, serta evaluasi risiko refaktorisasi (rendah/sedang/tinggi).
🎯 Saran Penggunaan: Disarankan untuk menyimpan petunjuk Review yang paling sering digunakan ke dalam
CLAUDE.mdatau.claude/skills/agar standar tim seragam. Melalui/loop, Anda dapat menjalankan tinjauan keamanan dan PR Review secara otomatis.
Jika Anda membangun sistem Review otomatis melalui API, disarankan untuk mengakses Claude Opus 4.6 dengan diskon 20% melalui APIYI di apiyi.com.
Pertanyaan Umum
Q1: Apa yang harus dilakukan jika /code-review bawaan terlalu bertele-tele?
Buat file REVIEW.md di direktori root proyek atau tambahkan aturan Review di CLAUDE.md untuk memberi tahu Claude secara spesifik apa yang harus diperhatikan dan apa yang tidak. Contohnya: "Hanya laporkan masalah tingkat Kritis dan Tinggi. Jangan nit-pick gaya kode atau penamaan. Jangan sarankan penambahan komentar." Claude Code akan membaca file ini secara otomatis setiap kali melakukan Review.
Q2: Bagaimana cara menyimpan petunjuk agar bisa digunakan kembali sebagai Skill?
Simpan petunjuk tinjauan keamanan Anda di .claude/skills/security-review/SKILL.md, lalu atur user-invocable: true. Ini akan mendaftarkannya sebagai perintah garis miring /security-review. Nantinya, Anda cukup mengetik /security-review untuk menjalankannya tanpa perlu copy-paste berulang kali. Anda bisa menyimpan banyak petunjuk sebagai Skill yang berbeda.
Q3: Bisakah PR Review dikirim otomatis ke komentar GitHub?
Bisa. Ada dua cara: 1) Ketik @claude review di komentar PR, Claude akan otomatis menganalisis diff dan memposting temuan sebagai komentar inline; 2) Gunakan perintah /code-review --comment, Claude akan memposting hasil Review sebagai komentar PR. Pada Maret 2026, Anthropic merilis sistem multi-Agen khusus Code Review yang mampu menjadwalkan sekelompok Agen profesional untuk meninjau PR dari berbagai sudut pandang seperti keamanan, logika, dan pengujian.
Q4: Berapa banyak Token yang dihabiskan untuk petunjuk Review?
Tergantung pada cakupan tinjauan. Tinjauan per file sekitar 2000-5000 Token, sedangkan pemindaian keamanan seluruh proyek bisa memakan 10000-30000 Token. Disarankan untuk membatasi cakupan tinjauan pada file/direktori tertentu agar tidak membuang-buang Token dengan "memindai semua file". Anda bisa menggunakan APIYI (apiyi.com) untuk mengakses Claude Opus 4.6 dengan diskon 20%, yang dapat menurunkan biaya Review secara signifikan.
Kesimpulan
Poin utama dari petunjuk Code Review Claude Code:
- 25 petunjuk mencakup 7 skenario utama: Tinjauan keamanan (4), deteksi Bug (4), analisis performa (3), tinjauan arsitektur (4), PR Review (4), keterbacaan (3), saran refactoring (3) — siap pakai.
- Formula lima elemen untuk petunjuk yang baik: Peran + Cakupan + Fokus + Format + Tingkat Keparahan. Harus presisi seperti kasus uji, bukan samar seperti pesan Slack.
- Sistem Review tiga lapis: Perintah bawaan (/security-review) → Petunjuk kustom (25 poin dalam artikel ini) → Otomatisasi Review berkelanjutan dengan /loop.
Direkomendasikan untuk menggunakan APIYI (apiyi.com) guna mengakses API Claude Opus 4.6 dengan diskon 20% untuk membangun sistem Code Review otomatis Anda.
📚 Referensi
-
Dokumentasi Resmi Claude Code Code Review: Penjelasan lengkap fitur Review bawaan
- Tautan:
code.claude.com/docs/en/code-review - Penjelasan: Mencakup PR Review, sistem multi-Agen, dan metode kustomisasi
- Tautan:
-
Claude Code Security Review: Skema tinjauan keamanan resmi dari Anthropic
- Tautan:
github.com/anthropics/claude-code-security-review - Penjelasan: Mencakup implementasi lengkap perintah /security-review
- Tautan:
-
7 Petunjuk PR Review Claude: Petunjuk review yang telah divalidasi oleh komunitas
- Tautan:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - Penjelasan: Berisi templat petunjuk terstruktur untuk tinjauan PR
- Tautan:
-
Pusat Dokumentasi APIYI: Akses API Claude Opus 4.6 dengan diskon 20%
- Tautan:
docs.apiyi.com - Penjelasan: Solusi API terbaik untuk membangun sistem review otomatis
- Tautan:
Penulis: Tim Teknis APIYI
Diskusi Teknis: Silakan berdiskusi di kolom komentar, untuk materi lebih lanjut kunjungi pusat dokumentasi APIYI di docs.apiyi.com
