Isi CLAUDE.md: 7 template siap tempel dan cara menulis daftar larangan

“CLAUDE.md itu cukup ditulisin tech stack-nya aja, kan?”

Dulu saya juga berpikir begitu. Astro, TypeScript, Tailwind, sudah saya tulis semua, dan saya merasa puas. Lalu saya minta Claude Code mengerjakan satu tugas dan hasilnya: kesalahan yang sama diulang tiga kali. Tesnya dilewati terus. Tangannya menjangkau file konfigurasi yang tidak boleh disentuh. Bilang “Sudah diperbaiki!” padahal build-nya belum lolos.

CLAUDE.md yang isinya cuma daftar stack itu sama seperti memberi tahu karyawan baru “kantor kita pakai Java” lalu langsung melepasnya ke lapangan. Dia tahu apa yang dipakai, tapi sama sekali tidak tahu bagaimana harus bekerja.

Di artikel ini saya menaruh tujuh template CLAUDE.md yang benar-benar saya pakai di proyek nyata, dalam bentuk yang bisa langsung disalin. Bukan penjelasan stack, melainkan template yang fokus penuh pada “urutan kerja” dan “hal yang tidak boleh dilakukan”.

Poin penting

• Yang benar-benar manjur di CLAUDE.md bukan tech stack, melainkan dua hal: urutan kerja (Working Rules) dan larangan (Do Not).
• Saya menyiapkan tujuh template per kebutuhan: app solo, situs konten, API, tim, legacy, automasi, dan monorepo. Pilih satu yang paling mirip repo Anda, lalu tempel saja.
• Untuk setiap template, wajib tambahkan tiga baris Do Not versi Anda sendiri setelah menempelnya. Inilah yang menghentikan kecelakaan.
• Anggapan “semakin panjang semakin bagus” itu keliru. CLAUDE.md bukan manual, melainkan file operasional. Aturan tindakan yang pendek selalu menang.
• Kalau Claude Code mengulang kesalahan yang sama tiga kali, jangan menyalahkan AI-nya, curigai dulu tingkat detail CLAUDE.md Anda.

Halaman ini saya buat sebagai “katalog barang nyata” yang mengisi celah antara panduan pemula Claude Code dan panduan lengkap menulis CLAUDE.md. Teorinya baca di sana, dari sini silakan bawa pulang barang jadinya.

Hal sederhana yang diam-diam dikerjakan CLAUDE.md yang bagus

CLAUDE.md yang kuat bukan karena menulis hal-hal pintar. Dia hanya diam-diam menambal tiga “kecelakaan yang sering terjadi” berikut:

• Lokasi editnya sudah benar, tapi konvensi khas proyek itu malah dilanggar
• Perbaikannya sendiri berhasil, tapi tes atau pengecekan yang harusnya dijalankan dilewati
• Batas tanggung jawabnya kabur, eksplorasi melebar terlalu jauh, dan waktu habis sia-sia

Untuk mencegah ketiganya, item minimal yang Anda butuhkan adalah seperti ini.

Item	Peran	Tingkat manjur
Tech stack & command utama	Menyamakan asumsi	Sedang
Peran direktori	Mempersempit area eksplorasi	Sedang
Aturan khas proyek	Menjaga konvensi dipatuhi	Besar
Urutan kerja (langkah)	Mencegah pengecekan terlewat	Besar
Larangan (Do Not)	Menghentikan kecelakaan	Sangat besar

Dua item teratas hanyalah pelengkap; yang benar-benar manjur adalah tiga di bawah. Khususnya, begitu Anda menulis urutan kerja dan larangan, Claude Code langsung jadi setenang orang yang berbeda. “Bagaimana harus jalan” dan “apa yang tidak boleh dilakukan” pada akhirnya sama persis dengan manual yang Anda berikan ke karyawan baru manusia.

Mulai dari sini barang nyatanya. Salin isi blok kode ke CLAUDE.md Anda apa adanya.

1. Untuk web app pengembangan solo

Kalau Anda menjalankan layanan kecil sendirian, mulailah dari yang ini.

# Project Overview

Customer-facing Astro site with a small Node API.

## Tech Stack

- Frontend: Astro 5 + TypeScript
- Styling: Tailwind CSS
- Backend: Node.js 22
- Tests: Vitest

## Key Directories

- `site/src/pages/` route entrypoints
- `site/src/components/` reusable UI
- `site/src/content/` blog and docs content
- `scripts/` operational scripts

## Common Commands

- Build: `cd site && npm run build`
- Test: `npm run test`
- Search content: `rg "keyword" site/src/content`

## Working Rules

- Prefer minimal diffs over wide refactors
- Keep copy changes aligned with existing brand tone
- When editing UI, verify mobile width before calling the task done

## Do Not

- Do not rename routes unless required
- Do not delete analytics or SEO fields
- Do not claim deploy success without checking the public URL

Yang paling manjur di sini bukan penjelasan stack, melainkan dua baris terakhir di Working Rules dan Do Not. “Jangan bilang selesai sebelum cek lebar mobile” dan “Jangan klaim deploy berhasil sebelum buka URL publik”. Sebelum dua baris ini ada, saya beberapa kali kena: UI yang di layar PC kelihatan rapi ternyata jebol semua waktu dibuka di ponsel. Begitu syarat sukses diikat dalam kalimat, kecelakaan itu hilang.

2. Untuk situs konten dengan artikel, PDF, dan jalur produk

Blog ini sendiri contohnya, tapi situs yang punya jalur monetisasi terlalu lemah kalau pakai template pengembangan umum.

# Project Overview

Multilingual Claude Code content site with free PDF lead magnet, Gumroad products, and consultation funnel.

## Business Goal

- Priority 1: free PDF registration
- Priority 2: Gumroad product clicks and purchases
- Priority 3: consultation inquiries

## Content Rules

- Every new article must include internal links
- Every article must include free PDF, product, and consultation CTA paths
- Use the same slug across all locales when publishing multilingual posts

## Verification Workflow

1. Build the site
2. Deploy the site
3. Open the public URL
4. Check mobile layout
5. Confirm CTA destination links

## Do Not

- Do not publish only one locale when the article requires all locales
- Do not treat build success as release success
- Do not prioritize pageviews over conversion path quality

Kuncinya ada di baris terakhir Do Not, yang dengan tegas menulis “utamakan kualitas jalur konversi di atas pageview”. Tanpa baris ini, Claude Code akan condong membuat “artikel yang sepertinya banyak dibaca”, lalu memproduksi massal halaman dengan CTA yang tipis. Cukup beri prioritas pada business goal dan taruh di paling atas, arah output langsung berubah total.

3. Untuk API backend

Untuk API yang nyawanya ada di integritas data, paksakan “baca dulu sebelum memperbaiki” dan “verbalkan setelah memperbaiki”.

# Project Overview

Internal TypeScript API for billing and account management.

## Tech Stack

- Node.js 22
- Fastify
- PostgreSQL + Prisma
- Zod
- Vitest

## Directory Map

- `src/routes/` HTTP handlers
- `src/services/` business logic
- `src/repositories/` DB access
- `src/lib/` shared utilities

## Required Workflow

1. Read the route or service first
2. Check for existing schema and tests
3. Make the smallest safe change
4. Run unit tests or type checks
5. Summarize risk in plain English

## Do Not

- Do not bypass Zod validation
- Do not edit migrations casually
- Do not touch billing logic without tests

Yang paling saya suka di sini adalah satu baris Summarize risk in plain English, yang artinya “rangkum risikonya dengan bahasa biasa”. Begitu ini dimasukkan, Claude Code tidak berhenti di “sudah diperbaiki”, tapi otomatis memverbalkan dampaknya: misalnya “perubahan ini dekat dengan batas logika billing, jadi berpotensi memengaruhi batch bulanan”. Langkah pertama review jadi jauh lebih ringan.

4. Untuk pengembangan tim

Yang benar-benar menyusahkan di kerja tim bukan kurangnya produktivitas, melainkan diff yang susah direview. Template ini mengantisipasinya lebih awal.

# Team Workflow

- Work on the current branch only
- Do not revert changes you did not make
- Call out uncertainty before making broad edits
- Prefer review-friendly patches over large rewrites

## Pull Request Expectations

- Mention user-facing behavior changes
- Mention test coverage gaps
- Flag security, permissions, and deploy risks first

## Approval Boundaries

- Ask before deploy commands
- Ask before editing CI, infra, or secrets-related files
- Ask before changing lockfiles unless required

Do not revert changes you did not make (jangan seenaknya mengembalikan perubahan yang bukan kamu buat) kelihatan sepele, tapi manjur. AI kadang ingin “sekalian” merapikan kode di dekatnya, lalu malah mengembalikan tulisan orang lain yang sebenarnya disengaja. Soal pemisahan batas approval saya tulis detail di panduan setting Approval / Sandbox, jadi kalau operasi tim, baca itu juga.

5. Untuk kode legacy

Saat memperbaiki kode lama, “tidak merusak” lebih benar daripada “kerapian”.

# Legacy Repo Notes

- This codebase has inconsistent patterns
- Prefer compatibility over elegance
- Preserve behavior unless the task explicitly allows change

## Investigation First

1. Explain current behavior
2. Locate the smallest responsible file set
3. Identify risks before editing

## Do Not

- Do not rename public methods casually
- Do not introduce new frameworks
- Do not rewrite files only to match modern style

Prefer compatibility over elegance (utamakan kompatibilitas di atas keindahan). Di proyek legacy, ini sering jadi hal yang paling penting. Kalau dibiarkan, Claude Code dengan niat baik akan bilang “saya tulis ulang ke gaya terbaru, ya”, padahal di legacy itulah pintu masuk kecelakaan. Masukkan Do not rewrite files only to match modern style ke larangan untuk menutup niat baik tersebut.

6. Untuk script automasi dan operasi

Kirim email, deploy, menulis ke API eksternal, kalau Anda menyerahkan script yang punya efek samping, kandidat pertamanya adalah ini.

# Automation Rules

- Dry-run whenever the script supports it
- Log intended side effects before executing
- Prefer idempotent operations
- Keep secrets out of logs and generated files

## Required Checks

- Confirm environment variables used
- Confirm target environment
- Confirm output path or destination service

## Do Not

- Do not send emails, deploy, or publish without explicit approval
- Do not delete generated assets unless cleanup is requested

Log intended side effects before executing (sebelum eksekusi, tuliskan apa yang akan kamu lakukan) adalah katup pengamannya. Kalau dipaksa mendeklarasikan dulu “saya akan mengirim 120 email ke produksi”, manusia bisa menyetop “tunggu”. Dipasangkan dengan Dry-run whenever the script supports it, setiap operasi yang tak bisa ditarik balik pasti melewati satu jeda dulu.

7. Untuk monorepo

Kalau beberapa aplikasi dan paket bersama tinggal serumah, tulis lebih dulu “paket mana yang bertanggung jawab”.

# Monorepo Map

- `apps/web/` customer app
- `apps/admin/` internal admin tool
- `packages/ui/` shared UI
- `packages/config/` lint and tsconfig presets

## Ownership Rules

- Web UI work should stay inside `apps/web/` unless the task clearly needs a shared component change
- Shared package edits require checking downstream usage
- Avoid version or config churn unless necessary

## Verification

- Run the narrowest relevant build or test command first
- Describe cross-package impact before editing shared code

Cukup dengan menulis Ownership Rules, kecelakaan edit lintas-paket berkurang drastis. Tadinya cuma perbaikan kecil di apps/web/, tahu-tahu tangannya masuk ke komponen bersama di packages/ui/, lalu menyeret apps/admin/ ikut rusak. Inilah kecelakaan khas monorepo. Paksa dia mendeklarasikan batas tanggung jawab di awal, dan selipkan satu kalimat “jelaskan dampak ke hilir” sebelum menyentuh kode bersama.

Template mana yang harus dipilih

Tujuh template terlalu banyak dan bikin bingung, jadi cara memilihnya saya rangkum jadi satu baris per kasus.

• Berpusat pada UI atau produk → template app solo
• Ada jalur artikel, PDF, dan Gumroad → template situs konten
• Integritas data adalah nyawa → template API
• Biaya koordinasi tinggi → template tim atau monorepo
• Biaya kecelakaan tinggi → template legacy atau automasi

Anda tidak perlu mencampur ketujuhnya. Justru kalau dicampur, isinya jadi panjang dan kemanjurannya turun. Jadikan satu template sebagai fondasi, lalu tambahkan hanya aturan yang benar-benar mengubah perilaku di lapangan Anda. Inilah jawaban yang benar.

Empat kesalahan yang sering terjadi di CLAUDE.md

Saya bagikan apa adanya ranjau yang benar-benar saya injak sendiri.

Kesalahan 1. Menulis panjang seperti wiki perusahaan. Anggapan “semakin panjang penjelasannya semakin bagus” ternyata sepenuhnya keliru. CLAUDE.md bukan manual, melainkan file operasional. Daripada penjelasan latar belakang yang panjang, aturan tindakan yang pendek berkali-kali lipat lebih manjur. Kita sering lupa premisnya: yang membaca bukan manusia, melainkan AI.

Kesalahan 2. Cuma menulis command, tanpa menulis langkah. Menulis “kalau menyentuh billing, wajib jalankan test” jauh lebih kuat daripada cuma menulis npm run test. Command hanya menyampaikan “keberadaannya”. Langkah menyampaikan sampai “kapan harus dipakai”.

Kesalahan 3. Tidak ada larangan. Ini yang paling disayangkan. Jangan sentuh .env, jangan klaim deploy berhasil sebelum cek URL publik, jangan force push. Satu kalimat saja bisa mencegah kecelakaan semalaman. Bagian Do Not bukan hiasan, melainkan asuransi.

Kesalahan 4. Tidak pernah diperbarui. Kalau Claude Code mengulang kesalahan yang sama tiga kali, biasanya bukan salah AI, melainkan tingkat detail di sisi CLAUDE.md yang kurang. Saat itu, jangan memarahi, tapi tambahkan satu baris aturan. CLAUDE.md bukan ditulis sekali lalu selesai, melainkan file yang dirawat dan dibesarkan.

Pertanyaan umum

T. CLAUDE.md harus ditaruh di mana dalam proyek? J. Taruh di root repo dengan nama CLAUDE.md, maka Claude Code memuatnya otomatis. Untuk monorepo, Anda juga bisa menaruhnya tepat di bawah tiap paket, dan yang lebih dekat akan diprioritaskan. Cara menaruh dan mengecek apakah ia manjur cukup dengan dua command ini.

# Cukup taruh di root proyek. Claude Code memuatnya otomatis saat start
cat > CLAUDE.md <<'EOF'
# Project
(tempel template di atas apa adanya)
EOF

# Cek apakah manjur: minta dia menyebutkan kembali aturannya
claude -p "Sebutkan 3 Do Not yang ada di CLAUDE.md proyek ini"

Untuk aturan penempatan yang lebih detail, cek dokumentasi resmi Claude Code.

T. Apakah menulis dalam bahasa Indonesia tetap manjur? J. Manjur. Saya kadang menulis larangan dan langkah dalam bahasa sendiri. Tapi templatenya saya tulis dalam bahasa Inggris karena lebih mudah disamakan dengan anggota tim luar negeri maupun contoh-contoh referensi, sehingga di artikel ini saya pakai basis Inggris. Selama isinya tersampaikan, mau bahasa apa pun tidak masalah.

T. CLAUDE.md panjang vs pendek, mana yang lebih baik? J. Yang pendek. Patokannya kira-kira muat dalam satu layar. Begitu mulai memanjang, itu tanda untuk memecahnya ke dokumen terpisah. Di CLAUDE.md, sisakan hanya “aturan yang mengubah perilaku”.

T. Setelah menempel template, apa yang pertama harus saya tambahkan? J. Tiga baris Do Not untuk proyek Anda sendiri. Masing-masing satu baris untuk “file yang repot kalau disentuh”, “operasi yang repot kalau dilakukan”, dan “kebohongan yang repot kalau diucapkan (mis. lapor sukses padahal belum diverifikasi)”. Di sinilah tambahan dengan return terbesar.

T. Apa bedanya CLAUDE.md dengan permissions (setting izin)? J. CLAUDE.md adalah “permintaan & kebijakan”, sedangkan permissions adalah “daftar izin yang punya daya paksa”. Kalau Anda serius ingin larangan dipatuhi, pakai keduanya bersamaan. Cara membagi izin juga disinggung di panduan pemula Claude Code.

Hasil setelah saya benar-benar mencobanya

Waktu CLAUDE.md saya cuma berisi tech stack, saya selalu deg-degan setiap kali melihat output Claude Code. “Kali ini dia mau jalankan test dengan benar nggak, ya?”

Setelah menambahkan Working Rules dan Do Not, kecemasan itu nyaris hilang. Khususnya satu baris “jangan klaim deploy berhasil sebelum buka URL publik” memberi efek yang jelas terlihat di angka. Sebelumnya, beberapa kali sebulan saya mengalami: setelah “deploy berhasil” ternyata kenyataannya 404. Setelah baris itu masuk, jadi nol.

Kesimpulannya sederhana. CLAUDE.md bukan file untuk membuat AI lebih pintar, melainkan file untuk mencegah AI bikin kecelakaan. Daripada menambah stack, menambah tiga baris larangan terasa sepuluh kali lebih manjur. Mulailah dengan menempel satu template yang paling mirip repo Anda, lalu tambahkan saja tiga baris Do Not.

Kalau Anda ingin mendalami filosofi desain CLAUDE.md itu sendiri, baca panduan lengkap menulis CLAUDE.md; kalau Anda ingin gambaran utuh soal “kerangka kerja” untuk menyerahkan tugas ke AI dengan aman, baca menyuruh AI “kerjakan semuanya” adalah awal kecelakaan. Kalau Anda ingin menyimpan kumpulan template dan contoh setting di dekat editor, Claude Code Quick Reference Cheatsheet gratis dan The Complete Claude Code Setup & Configuration Guide yang masuk sampai hooks dan permissions akan sangat membantu. Mau melihat seluruh materi belajar, buka daftar materi; mau membereskan standardisasi tim bersama, mampir ke konsultasi penerapan.