Perintah Slash Kustom Claude Code: Jadikan /review, /handoff, dan /release Standar Tim

Anda menempelkan checklist review yang sama lagi. Menjelang release, Anda mencoba mengingat ulang langkah-langkahnya. Setelah sesi Claude Code yang panjang, Anda tetap harus menulis apa yang berubah, apa yang sudah diverifikasi, dan risiko apa yang tersisa. Semakin sering tim memakai agen coding, semakin penting pola kecil yang berulang ini dijadikan prosedur.

Perintah slash kustom mengubah prompt berulang menjadi nama pendek yang dimiliki bersama oleh tim. /review, /handoff, atau /release bukan sekadar jalan pintas. Jika dirancang dengan benar, perintah itu menjadi standar kerja: bagaimana kode direview, bagaimana konteks diserahkan, dan bagaimana tim memutuskan apakah sesuatu siap dirilis.

Artikel ini mengikuti dokumentasi resmi Claude Code Skills dan referensi Commands, diverifikasi pada 3 Juni 2026. Poin pentingnya: custom commands telah digabungkan ke Skills. File lama di .claude/commands/*.md tetap berjalan, tetapi workflow tim baru biasanya lebih rapi jika dibuat sebagai .claude/skills/<name>/SKILL.md.

Intinya: command adalah prosedur kerja yang bisa dipakai ulang

Di Claude Code, command adalah pesan yang dimulai dengan / di dalam sesi. Referensi resmi menjelaskan bahwa command dikenali di awal pesan, dan teks setelah nama command diteruskan sebagai argumen. Artinya, /release 1.8.0 dapat memakai 1.8.0 sebagai versi, sedangkan /handoff frontend reviewer dapat memberi tahu untuk siapa catatan handoff dibuat.

Skill adalah paket instruksi yang dapat digunakan ulang oleh Claude. Dalam bahasa sederhana, ini adalah playbook kecil: kapan digunakan, langkah apa yang harus diikuti, input apa yang penting, dan format output seperti apa yang diharapkan. File lama di .claude/commands/ masih valid, tetapi Skills memberi struktur direktori, frontmatter, file pendukung, argumen bernama, dan alur review yang lebih jelas.

Perhatian pertama adalah konflik nama. Instalasi Claude Code saat ini mungkin sudah menampilkan /review, /code-review, atau /security-review. Sebelum membuat /review sendiri, ketik / dan cek menu. Jika nama sudah ada, gunakan /team-review, /review-note, atau nama khusus tim. Artikel ini membahas pola review; nama akhirnya harus aman untuk lingkungan Anda.

Tata letak file: utamakan Skills, simpan Commands untuk kompatibilitas

Aturan tim sebaiknya berada di proyek, bukan hanya di direktori home satu orang. Project Skills dapat di-commit, direview lewat pull request, dan berevolusi bersama repository. Personal Skills tetap berguna, tetapi jangan dijadikan sumber aturan yang dibutuhkan semua orang.

Lokasi	Contoh	Cocok untuk
Project Skill	.claude/skills/team-review/SKILL.md	Review, release, investigasi, dan onboarding bersama
Project Command	.claude/commands/handoff.md	Command ringan yang sudah ada atau kompatibilitas saat migrasi
Personal Skill	~/.claude/skills/my-note/SKILL.md	Catatan pribadi dan rutinitas privat
Personal Command	~/.claude/commands/my-command.md	Shortcut sementara

Struktur repository yang bersih bisa seperti ini:

.claude/
├── commands/
│   └── handoff.md
└── skills/
    ├── team-review/
    │   ├── SKILL.md
    │   └── checklists/
    │       └── review.md
    └── release-prep/
        ├── SKILL.md
        └── scripts/
            └── collect-release-notes.sh

Modelnya sederhana: repository menyimpan prosedur, menu / menampilkannya sebagai command, pengguna memberi argumen, lalu Claude Code menggabungkan instruksi itu dengan konteks tugas saat ini.

flowchart LR
  A[".claude/skills atau .claude/commands"] --> B["Command seperti /team-review"]
  B --> C["Argumen: $ARGUMENTS atau $version"]
  C --> D["Claude Code memuat instruksi"]
  D --> E["Review, handoff, atau persiapan release"]
  E --> F["Manusia memeriksa dan memutuskan merge atau publish"]

Setelah menambah atau mengubah Skill, cek apakah muncul di menu /. Jika sesi saat ini belum mendeteksi perubahan, gunakan /reload-skills atau buka sesi Claude Code baru. Periksa juga deskripsinya, karena tim akan menemukan workflow dari teks itu.

Template awal yang bisa disalin

Mulai dari yang kecil. Contoh berikut membuat /team-review, sehingga tidak bertabrakan dengan kemungkinan /review bawaan.

mkdir -p .claude/skills/team-review
cat > .claude/skills/team-review/SKILL.md <<'EOF'
---
description: Review the current change with the team's checklist before a pull request or merge.
argument-hint: [target-branch-or-path]
disable-model-invocation: true
---

You are performing a read-only team review.

Target: $ARGUMENTS

If the target is empty, ask which diff, branch, or path to review before scanning broadly.
Do not edit files.
Do not run destructive commands.

Review from these perspectives:
1. Correctness bugs and edge cases
2. Security and privacy risks
3. Test coverage and missing verification
4. Consistency with existing code patterns
5. Documentation, migration notes, and user-facing copy

Output:
- Findings first, ordered by severity
- File path and line number when available
- One short suggestion for each issue
- "No blocking findings" only if you found none
EOF

Panggil dengan /team-review main, /team-review src/auth, atau target lain yang sempit. disable-model-invocation: true mencegah Claude memilih Skill ini secara otomatis. Untuk review dan release, itu lebih aman karena workflow semacam ini seharusnya dimulai secara eksplisit oleh manusia.

Use case 1: jadikan /review checklist tim

Nilai utama command review adalah konsistensi. Tanpa checklist bersama, satu orang fokus pada penamaan, orang lain pada keamanan, dan yang lain pada test. Command harus mendefinisikan severity, scope, dan format output agar Claude dan manusia membaca dengan standar yang sama.

Jika lingkungan Anda sudah memiliki /review, gunakan team-review.md atau Skill team-review. Jika tidak ada konflik, .claude/commands/review.md masih dapat membuat /review.

---
description: Team review checklist for the current branch or specified path.
argument-hint: [branch-or-path]
disable-model-invocation: true
---

Review target: $ARGUMENTS

Read the diff or files related to the target and report only review findings.
Do not rewrite code unless the user asks for fixes after the review.

Severity:
- P0: data loss, auth bypass, secret leak, production outage
- P1: correctness bug, missing validation, broken user flow
- P2: maintainability, unclear naming, duplicated logic
- P3: optional cleanup

Required checks:
1. Is the change scoped to the request?
2. Are tests or manual verification enough for the risk?
3. Are error paths and empty states handled?
4. Does the code follow existing local patterns?
5. Could the change break monetization links, analytics, or release notes?

Return a short summary after the findings.

Baris terpenting adalah “Do not rewrite code”. Review yang diam-diam mengubah file bukan lagi review, tetapi tugas implementasi. Jalankan pass pertama secara read-only, lalu buka tugas perbaikan terpisah setelah finding diterima.

Use case 2: gunakan /handoff untuk orang atau agen berikutnya

Sesi panjang kehilangan nilai jika akhirnya tidak jelas. /handoff mengubah penutup tugas menjadi catatan terstruktur untuk Anda besok, rekan tim, atau agen berikutnya.

---
description: Create a concise handoff note for the current task.
argument-hint: [next-owner-or-audience]
disable-model-invocation: true
---

Create a handoff note for: $ARGUMENTS

Include these sections:
1. Goal: what the task was trying to achieve
2. Changed files: important files and why they changed
3. Decisions: tradeoffs or assumptions made during the work
4. Verification: commands run, screenshots checked, or checks not run
5. Risks: unresolved issues, fragile areas, or things needing human review
6. Next steps: the smallest useful next action

Keep it factual. Do not hide failed attempts. If something was not verified, say so clearly.

Ini sangat berguna untuk situs yang dimonetisasi dan aplikasi produksi. Internal link, CTA, event analytics, screenshot, dan pengecekan manual mudah terlewat saat pekerjaan menyentuh banyak file. Handoff membuat detail itu tetap terlihat.

Use case 3: gunakan /release untuk persiapan, bukan publikasi

Command release harus konservatif. Tujuannya bukan membiarkan Claude memublikasikan sesuatu untuk Anda. Tujuannya adalah mengumpulkan konteks, menyiapkan catatan, mencatat blocker, dan membiarkan keputusan akhir pada manusia.

Template ini memakai argumen bernama. Dokumentasi saat ini menjelaskan arguments sebagai nama yang dipetakan ke input posisional; argumen pertama di sini menjadi $version.

---
description: Prepare a release checklist and changelog draft without publishing.
argument-hint: [version]
arguments: [version]
disable-model-invocation: true
---

Prepare release $version.

Allowed work:
1. Inspect the current diff, package metadata, and changelog
2. Draft a changelog section for $version
3. Suggest verification commands
4. List release blockers and rollback notes
5. Propose a commit message

Safety rules:
- Do not run git push
- Do not publish packages
- Do not deploy to production
- Do not delete files
- Ask before changing version files

Output:
- Release summary
- Checklist
- Blockers
- Commands the user should run manually

Ini adalah command persiapan release, bukan tombol release. Jika tim ingin mengotomatisasi publikasi, tempatkan itu di CI/CD dengan approval, log, dan aturan rollback yang jelas.

Argumen: mulai dari $ARGUMENTS

Untuk sebagian besar command kustom, $ARGUMENTS sudah cukup. /handoff backend reviewer akan mengisi $ARGUMENTS dengan backend reviewer. Dokumentasi saat ini juga mendukung $ARGUMENTS[0], $0, dan argumen bernama seperti $issue atau $branch jika dideklarasikan di frontmatter.

---
description: Prepare an issue-specific work plan.
argument-hint: [issue] [branch]
arguments: [issue, branch]
disable-model-invocation: true
---

Issue: $issue
Branch: $branch
All arguments: $ARGUMENTS

Create a plan that:
1. Restates the issue in plain language
2. Lists files to inspect first
3. Identifies likely tests
4. Names one thing that should not be changed

Gunakan tanda kutip jika satu argumen berisi beberapa kata: /plan-issue "login redirect bug" fix-login. Hati-hati dengan contoh lama yang menganggap $1 sebagai argumen pertama. Dokumentasi saat ini menjelaskan $0 sebagai singkatan untuk argumen posisional pertama.

Versioning dan workflow review

Perlakukan Project Skills dan Commands seperti kode. Keduanya memengaruhi apa yang direview, apa yang terlewat, dan apa yang dianggap “selesai” oleh tim. Perubahan pada .claude/skills/release-prep/SKILL.md sebaiknya terlihat dalam pull request, bukan tersembunyi di diff fitur yang tidak terkait.

Aturan	Tujuan
Commit .claude/skills/ ke Git	Riwayat perubahan workflow terlihat
Izinkan PR khusus command	Perubahan proses tidak tercampur dengan app code
Daftar command di README atau CLAUDE.md	Anggota baru mudah menemukan workflow
Larang aksi destruktif di prompt	Mencegah push, publish, deploy, atau delete tidak sengaja
Review daftar command tiap bulan	Command usang tidak membingungkan tim

Untuk rollout tim, baca juga panduan mulai Claude Code, praktik terbaik CLAUDE.md, dan panduan Claude Code Hooks.

Jebakan dan catatan keamanan

Kesalahan terbesar adalah menganggap command kustom aman hanya karena pendek. Command tetap prompt yang kuat. Jika Anda memakai injeksi konteks dinamis dengan backtick !, Claude Code menjalankan command shell lalu memasukkan output sebelum Claude membaca Skill. Ini berguna, tetapi harus dibatasi read-only.

---
description: Collect read-only git context for release notes.
disable-model-invocation: true
---

Current status:
!`git status --short`

Recent commits:
!`git log --oneline -20`

Summarize the release notes from the information above.
Do not run write operations.

Batasi perintah seperti ini pada inspeksi aman seperti git status dan git log. Jangan memasukkan rm, git clean, git push, npm publish, curl ... | sh, atau script yang berdampak pada produksi. Hati-hati juga dengan allowed-tools: akses Bash yang terlalu luas dapat mengurangi konfirmasi ketika tim justru mengharapkan jeda. Mulailah dari alat read-only, lalu tambah izin hanya jika workflow benar-benar membutuhkannya.

Kegagalan konkret mudah terjadi. /review kustom bertabrakan dengan command bawaan. Skill hanya ada di home satu orang. Isi Skill terlalu panjang dan membuang konteks setiap kali dimuat. Argumen kosong membuat Claude memindai seluruh repository. Command release berisi publish. Semuanya berasal dari otomatisasi yang terlalu cepat. Mulai read-only, batasi target, dan jadikan konfirmasi manusia bagian dari desain.

CTA: ubah template menjadi operasi tim

Template ini bernilai jika disesuaikan dengan repository Anda. Developer solo bisa mulai dari cheatsheet Claude Code gratis dan menyimpan pola aman di dekat workflow harian. Untuk template review, release, dan handoff yang bisa dipakai ulang, lihat produk ClaudeCodeLab. Jika tim Anda perlu merancang permission, CLAUDE.md, review Skill, batas CI, dan onboarding sekaligus, gunakan halaman training dan konsultasi Claude Code.

Saat dicoba dalam workflow Masa, hasilnya jelas: tiga command sudah cukup. /team-review, /handoff, dan /release-prep menutup sebagian besar pekerjaan berulang tanpa mengubah Claude Code menjadi alat deployment yang berbahaya. Perbaikan terbesar datang dari mendefinisikan /release sebagai command yang mengumpulkan bukti untuk keputusan manusia, bukan command yang langsung memublikasikan. Perintah slash kustom paling berguna ketika membantu tim berhenti, memeriksa, dan menyerahkan konteks dengan standar yang sama.