Meningkatkan Kualitas Pull Request dengan Claude Code
Gunakan Claude Code untuk template PR, CI gate, bukti tes, dan handoff agar PR AI tidak penuh noise.
Pull Request adalah tempat tim mengusulkan, meninjau, dan menggabungkan perubahan kode. Dokumentasi resmi GitHub juga menempatkan PR sebagai fitur utama untuk kolaborasi. Saat Claude Code mempercepat implementasi, masalah baru muncul: deskripsi PR terlalu tipis, diff terlalu besar, bukti tes tidak jelas, dampak keamanan tidak ditulis, dan komentar review berulang karena konteksnya kabur.
Panduan ini memakai Claude Code sebagai asisten kualitas PR, bukan sekadar pembuat teks. diff berarti daftar baris yang berubah, CI adalah gerbang otomatis untuk build dan tes, diff-size budget adalah batas ukuran PR, dan handoff adalah catatan singkat agar reviewer berikutnya bisa lanjut tanpa membaca ulang semuanya. Untuk dasar yang terkait, baca juga code review dengan Claude Code dan strategi testing Claude Code.
flowchart LR
A["Implementasi dengan Claude Code"] --> B["Isi template PR"]
B --> C["Batasi diff di CI"]
C --> D["Tambahkan bukti tes"]
D --> E["Siapkan handoff reviewer"]
E --> F["Buat release notes"]
Referensi resmi yang dipakai di artikel ini adalah GitHub Pull Requests, membuat template Pull Request, sintaks workflow GitHub Actions, protected branches, secrets di GitHub Actions, Claude Code docs, dan jika memakai kategori commit, Conventional Commits.
Kunci standar PR di template
Meminta Claude Code “buat deskripsi PR yang bagus” setiap kali akan menghasilkan kualitas yang berubah-ubah. Lebih aman jika standar review ditaruh di .github/pull_request_template.md. GitHub dapat menampilkan template ini otomatis di body PR, sehingga aturan tim tidak bergantung pada ingatan orang.
## Apa yang berubah
<!-- Pisahkan implementasi, konfigurasi, dokumentasi, dan file generated. -->
## Mengapa perubahan ini diperlukan
<!-- Tautkan issue, insiden, permintaan user, atau keputusan desain. -->
## Fokus review
- [ ] Logika bisnis
- [ ] UI/UX
- [ ] Kontrak API atau database
- [ ] Keamanan dan privasi
## Bukti tes
- [ ] Tes otomatis:
- [ ] Pemeriksaan manual:
- [ ] Screenshot atau rekaman:
## Ukuran diff
- Jumlah file berubah:
- Baris ditambah/dihapus:
- Alasan tidak dipecah:
## Keamanan dan operasi
- [ ] Tidak berisi secret, token, atau data pribadi
- [ ] Log tidak membocorkan kredensial atau data pribadi
- [ ] Permission, environment variable, dan feature flag sudah dicek
- [ ] Rencana rollback ditulis
## Handoff untuk reviewer
<!-- File yang dibaca dulu, keputusan terbuka, risiko, dan PR lanjutan. -->
Field “alasan tidak dipecah” dan “rencana rollback” sering paling berguna. Jika kosong, PR biasanya terlalu besar atau belum siap dari sisi operasional. Claude Code boleh mengisi template, tetapi template yang menentukan standar minimum review.
Buat body PR dari fakta, bukan tebakan
Setelah template tersedia, minta Claude Code membaca diff dan mengisi template. Prompt harus melarang klaim tanpa bukti. Jika tes belum dijalankan, tulis “belum dijalankan”, bukan “aman”.
git diff origin/main...HEAD | claude -p "
Baca diff ini dan buat body Pull Request memakai format .github/pull_request_template.md dalam bahasa Indonesia.
Aturan:
- Jangan membuat fakta yang tidak terlihat di diff
- Jika bukti tes tidak ada, tulis 'belum dijalankan'
- Jelaskan istilah teknis saat pertama kali muncul
- Batasi fokus review ke 3 file atau area terpenting
- Cek secret, token, data pribadi, dan log berisiko
- Akhiri dengan item yang masih harus diverifikasi manusia
"
Hasilnya adalah peta review. Reviewer bisa mulai dari fungsi otorisasi, layar yang berubah, atau file migrasi, bukan membaca seluruh branch tanpa arah. Claude Code cepat membaca diff, tetapi klaim akhir tetap tanggung jawab manusia.
Pakai CI untuk membatasi ukuran PR
PR besar menurunkan kedalaman review. Claude Code bisa melakukan rename, formatting, refactor, test, dan dokumentasi dalam satu sesi. Itu membantu, tetapi mudah mencampur banyak tujuan. diff-size budget membuat batasnya eksplisit.
Untuk proyek Node, tambahkan scripts/check-pr-size.mjs. Script ini mengabaikan lockfile dan output generated, lalu menghitung perubahan yang perlu direview.
#!/usr/bin/env node
import { execFileSync } from "node:child_process";
const [range = "origin/main...HEAD", maxLinesRaw = "700", maxFilesRaw = "35"] =
process.argv.slice(2);
const maxLines = Number(maxLinesRaw);
const maxFiles = Number(maxFilesRaw);
const ignored = [
/^package-lock\.json$/,
/^pnpm-lock\.yaml$/,
/^yarn\.lock$/,
/^dist\//,
/^coverage\//,
];
function numeric(value) {
const parsed = Number(value);
return Number.isFinite(parsed) ? parsed : 0;
}
const output = execFileSync("git", ["diff", "--numstat", range], {
encoding: "utf8",
}).trim();
let files = 0;
let lines = 0;
for (const row of output.split(/\r?\n/).filter(Boolean)) {
const [added, deleted, file] = row.split("\t");
if (ignored.some((pattern) => pattern.test(file))) continue;
files += 1;
lines += numeric(added) + numeric(deleted);
}
if (files > maxFiles || lines > maxLines) {
console.error(
`PR is too large: ${files} files / ${lines} changed lines. ` +
`Budget is ${maxFiles} files / ${maxLines} lines.`,
);
console.error("Split formatting, generated files, and behavior changes into separate PRs.");
process.exit(1);
}
console.log(`PR size OK: ${files} files / ${lines} changed lines.`);
Sambungkan ke GitHub Actions. File workflow berada di .github/workflows, dan job ini bisa dijadikan required status check di protected branch.
name: PR quality
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
permissions:
contents: read
pull-requests: read
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Install dependencies
run: npm ci
- name: Run project checks
run: |
npm run lint --if-present
npm test --if-present
- name: Enforce PR size budget
run: node scripts/check-pr-size.mjs "origin/${{ github.base_ref }}...HEAD" 700 35
Angka bisa disesuaikan. Saya biasanya mulai dari 700 baris dan 35 file, lalu meminta alasan khusus untuk migrasi atau refactor mekanis. Tujuannya bukan melarang PR besar, tetapi membuat alasan PR besar terlihat.
Buat bukti tes yang bisa diulang
“Tes lolos” terlalu lemah. Body PR perlu command, hasil, pemeriksaan manual, screenshot untuk UI, dan daftar yang belum dicek. Claude Code bisa merapikan bagian ini, tetapi tidak boleh menyatakan command sudah jalan jika belum.
claude -p "
Siapkan bagian bukti tes untuk Pull Request branch ini.
Format:
## Tes otomatis
- Command:
- Hasil:
- Penyebab gagal, jika ada:
## Pemeriksaan manual
- Layar, API, atau job yang dicek:
- Data input:
- Hasil yang diharapkan:
- Hasil aktual:
## Belum diverifikasi
- Item yang belum dicek:
- Siapa yang harus mengecek sebelum merge:
Gunakan fakta saja. Jangan tandai command yang belum dijalankan sebagai lolos.
"
Ada tiga use case umum. PR UI membutuhkan screenshot, ukuran viewport, dan catatan aksesibilitas. PR API membutuhkan kompatibilitas, respons error, dan perilaku log. Migrasi atau batch membutuhkan dry run, rollback, dan estimasi waktu. Dengan memisahkan kasus ini, reviewer bisa langsung masuk ke area yang dikuasai.
Tambahkan review keamanan dan privasi
Kode yang dibuat dengan bantuan AI bisa menyentuh lebih banyak file dari yang diperkirakan. Secret dapat muncul di contoh, log, fixture, atau screenshot. GitHub Actions secrets memang untuk nilai sensitif dalam workflow, tetapi bukan berarti aman untuk mencetak nilainya di log atau body PR.
Review diff ini dari sudut keamanan dan privasi.
Checklist:
1. Secrets, tokens, API keys, cookies, session IDs
2. Data pribadi di logs, fixtures, screenshots, atau error messages
3. Permission check dilakukan di server, bukan hanya disembunyikan di UI
4. GitHub Actions permissions terlalu luas
5. Error response membocorkan path internal atau kredensial
6. Feature flags atau environment variables mengubah rollout
Berikan severity High/Medium/Low dan nama file yang tepat.
Tambahkan juga area mencurigakan yang belum bisa dipastikan.
Kalimat terakhir penting. Dalam review keamanan, daftar area yang belum pasti sering lebih berguna daripada jawaban “tidak ada masalah” yang terlalu cepat.
Siapkan handoff dan balasan komentar
Handoff membuat reviewer berikutnya tidak perlu membaca ulang semua percakapan. Ini berguna untuk tim lintas zona waktu, PR panjang, atau rotasi reviewer. Berikan komentar PR dan ringkasan diff ke Claude Code.
PR_NUMBER=123
{
gh pr view "$PR_NUMBER" --comments
gh pr diff "$PR_NUMBER" --stat
} | claude -p "
Buat catatan handoff untuk reviewer Pull Request ini.
Sertakan:
- Tujuan dalam maksimal dua kalimat
- Maksimal 3 file untuk dibaca lebih dulu
- Komentar review yang sudah ditangani
- Komentar yang masih menunggu keputusan
- Risiko CI, tes manual, dan release
Catatan harus bisa dipahami reviewer dalam lima menit.
"
Balasan komentar juga harus konkret. “Sudah diperbaiki” jarang cukup. Balasan yang baik menyebut apa yang berubah, file mana, tes apa yang menutupinya, dan mengapa saran tertentu tidak diambil. Claude Code boleh membuat draft; manusia harus memangkas bagian defensif, spekulatif, atau terlalu panjang.
Hubungkan PR ke release notes
PR tidak selesai saat merge. Perubahan untuk pengguna, perubahan internal, dan breaking change perlu masuk release notes. Conventional Commits membantu pengelompokan, tetapi bahasa akhir tetap harus mudah dipahami.
gh pr list --state merged --base main --limit 20 \
--json number,title,body,mergedAt \
| claude -p "
Buat draft release notes dari Pull Request yang sudah merged ini dalam bahasa Indonesia.
Bagian:
## Fitur baru
## Perbaikan
## Performance
## Dokumentasi
## Perubahan developer
Aturan:
- Pertahankan nomor PR
- Ringkas perubahan internal
- Sorot breaking changes, migrasi, dan feature flags
- Jangan membuat dampak yang tidak didukung body PR
"
Jika body PR tidak bisa diubah menjadi release note, biasanya PR itu juga tidak cukup jelas untuk reviewer. Memikirkan komunikasi release sejak awal membuat alasan perubahan lebih tajam.
Hindari PR AI yang penuh noise
Kegagalan paling umum adalah noise. Formatting yang tidak diminta, rename besar, refactor spekulatif, komentar duplikat, deskripsi seperti materi marketing, dan klaim tes tanpa bukti membuat review lambat.
Aturan sederhana cukup efektif. Pisahkan formatting. Jaga diff generated sekecil mungkin. Tulis fakta saja di body PR. Jelaskan mengapa saran Claude Code diterima. Pisahkan perubahan mekanis, perubahan perilaku, dan test jika memungkinkan.
| PR AI penuh noise | PR yang bisa direview |
|---|---|
| “Claude memperbaiki modul” | “Memindahkan authorization checks ke server/auth.ts” |
| Formatting dan logic bercampur | PR formatting dipisah dari PR fitur |
| “Semua aman” tanpa bukti | Command, hasil, dan gap ditulis |
| Fokus review kosong | File dan risiko disebut di awal |
Masukkan ke alur monetisasi ClaudeCodeLab
Topik ini cocok untuk template, training, dan konsultasi implementasi. Tim tidak hanya butuh prompt; mereka butuh template PR, aturan CLAUDE.md, CI gate, dan kebiasaan review. Hubungkan artikel ini ke template CLAUDE.md, aturan handoff tim, dan training atau konsultasi, sehingga pembaca punya langkah implementasi berikutnya.
Terapkan bertahap. Minggu pertama: template PR. Minggu kedua: gate ukuran diff. Minggu ketiga: handoff reviewer. Minggu keempat: release notes dari PR merged. Jika semua aturan datang sekaligus, tim akan menolak proses sebelum kualitas naik.
Hasil setelah dicoba
Saya mencoba alur ini di proyek Node kecil. Kombinasi template PR dan size gate memberi efek terbesar. Claude Code saja menghasilkan teks panjang tetapi tidak stabil; template memunculkan tes yang belum dijalankan, review keamanan, file prioritas, dan rollback. Budget 700 baris dan 35 file juga membantu memisahkan formatting dari perubahan perilaku sebelum meminta review.
Ringkasan
Claude Code meningkatkan kualitas Pull Request jika diberi batas yang jelas: template ketat, budget diff di CI, bukti tes yang bisa diulang, checklist keamanan dan privasi, handoff reviewer, dan release notes. Tujuannya bukan membuat PR terdengar lebih rapi, melainkan membuat perubahan berbantuan AI mudah direview, diverifikasi, dan dirilis.
PDF gratis: cheatsheet Claude Code
Masukkan email dan unduh satu halaman berisi command, kebiasaan review, dan workflow aman.
Kami menjaga datamu dan tidak mengirim spam.
Tentang penulis
Masa
Engineer yang berfokus pada workflow Claude Code praktis dan adopsi tim.
Artikel terkait
Permission safety ladder Claude Code: perluas akses tanpa kehilangan kontrol
Naik dari read-only ke edit terbatas, command bukti, dan cek deploy dengan kontrol yang jelas.
Claude Code Small PR Proof Pack: perubahan kecil yang mudah direview
Paket bukti untuk PR Claude Code: diff, check, URL publik, jalur CTA, dan rollback.
Review gate Claude Code sebelum commit: diff, test, URL publik, dan CTA
Cara memakai Claude Code sebelum commit: diff scope, build, URL publik, link Gumroad, CTA konsultasi, missing test, dan file tidak terkait.