Tulisan sebelumnya berpendapat CLAUDE.md hanya untuk invarian. Lalu apa yang masuk ke memory? Saya buka 5 file memory yang aktif di proyek ini dan audit satu per satu—mana yang layak bertahan, mana yang harus dihapus, dan di mana sebenarnya garis antara CLAUDE.md dan memory.
Tulisan sebelumnya berpendapat bahwa CLAUDE.md hanya boleh berisi hal-hal yang tidak bisa dilihat Claude dari membaca kode. Seorang pembaca langsung bertanya: lalu bagaimana dengan memory? Memory juga konteks — apa bedanya sebenarnya?
Banyak orang akhirnya memperlakukan memory sebagai "ekstensi cadangan" CLAUDE.md — mereka menjejalkan apa saja yang terpikir. Seiring waktu memory membengkak, Claude membacanya setiap sesi, dan keputusan diambil berdasarkan informasi yang sudah basi.
Tulisan ini melewatkan definisi abstrak. Saya buka kelima file memory yang sedang aktif di proyek ini dan audit satu per satu — mana yang tinggal, mana yang pergi, mana yang seharusnya tidak pernah ditulis. Di sepanjang jalan, pertanyaan CLAUDE.md vs memory menjawab dirinya sendiri.
Pertanyaan yang berguna bukan "ini taruh di mana" — tapi "berapa lama informasi ini hidup, dan siapa yang memperbaruinya."
feedback_commits — tunggu saya bilang "commit" sebelum commit
feedback_article_authenticity — artikel praktis tidak boleh dikarang
project_i18n_strategy — keputusan "rilis semua bahasa sekaligus"
project_howdev_plan — rencana how2claude.dev yang belum selesai
project_article_workflow — pipeline publikasi artikel
Dikelompokkan berdasarkan tipe.
Isinya singkat: "don't auto-commit, wait for user to confirm."
Ini jenis memory dengan ROI tertinggi. Satu koreksi → permanen di semua sesi mendatang.
Kenapa tidak di CLAUDE.md? Itu bukan aturan proyek — itu kebiasaan kerja pribadi saya. Kalau kontributor lain bergabung, mereka tidak harus mengikuti aturan yang sama. CLAUDE.md itu level tim. Memory itu "antara Claude dan saya."
Kenapa tidak mengulanginya di awal setiap percakapan? Karena memory bertahan lintas sesi. Ketika Claude membantu saya minggu depan, dia tetap ingat.
Pemicunya jelas: saya pernah mengoreksi sekali, dan saya ingin koreksi itu bertahan selamanya.
Isi memory ini luar biasa spesifik:
Pada 2026-04-16, saat menulis penutup seri multi-agent, saya mengarang cerita tentang "tiga Agent membangun fitur webhook"... semuanya fiktif. Pengguna bertanya "ini beneran atau karangan?" — yang merupakan standar berbeda dari dua artikel sebelumnya (metodologis)...
Intinya: kolom Why bukan prinsip abstrak — tapi peristiwa spesifik + tanggal + apa yang terjadi.
Kenapa ditulis seperti itu? Enam bulan dari sekarang, "artikel praktis butuh bahan nyata" sebagai aturan abstrak akan membingungkan — kapan ini ditetapkan, kenapa? Tapi "4-16, saya mengarang cerita agent dan ketahuan" memicu ingatan instan, dan memungkinkan saya menilai di tempat apakah aturan itu masih berlaku.
Ini entri paling "berat" dari 5 saya. Bukan sekadar aturan — tapi file insiden yang bisa diakses baik oleh Claude maupun saya.
Isinya: kenapa proyek ini agresif merilis semua bahasa sekaligus — biaya terjemahan via Claude mendekati $0, dan dokumentasi resmi yang hanya bahasa Inggris adalah jendela peluang utama.
Tidak terlihat dari kode. Kode hanya menunjukkan 19 file locale. Kenapa 19, kenapa sekaligus, kenapa Jepang dan Korea prioritas tinggi — semua itu ada di kepala saya.
Memory mengendapkan "keputusan di kepala" itu jadi sesuatu yang tahan lama, sehingga ketika Claude nanti menyarankan fitur, dia bisa bertanya: apakah ini bertabrakan dengan strategi i18n?
Bukan aturan operasional (tidak masuk CLAUDE.md). Latar strategis (masuk memory).
Yang paling temporer: rencana implementasi 9 file untuk situs developer how2claude.dev, diakhiri dengan "dilanjutkan sesi berikutnya."
Jenis memory paling berbahaya — mudah jadi memory zombi. Pekerjaan selesai, lupa menghapus; lain kali, Claude menganggapnya masih aktif dan menasihati berdasarkan rencana usang ("kamu belum step 3").
Memory seperti ini butuh mekanisme keluar eksplisit: saat how2claude.dev diluncurkan, saya harus menghapus entri ini secara manual.
Yang ini punya kepadatan informasi tertinggi. Awalnya saya kira paling berguna — sampai saya baca dengan teliti:
/write-article dan /publish-article → lihat .claude/commands/, selesaidocs/drafts/ sudah jelas.claude/publish-config.jsonClaude bisa menurunkan semua itu dari membaca kode.
Satu-satunya yang memang diberikan memory adalah blok terakhir: "Accounts (production): zh → @how2claude, en → @howtoclaude" — dan ini sudah basi. Sesi terakhir menunjukkan produksi sebenarnya zh=@howtoclaude. Memory merekam snapshot beberapa hari lalu; sudah melenceng.
Kesimpulan: 90% memory ini harus pergi. Bagian yang layak disimpan ("pakai kamal untuk query akun real-time") lebih cocok di CLAUDE.md — atau lebih baik lagi, tidak di mana pun, karena akun yang di-hardcode di memory pasti akan melenceng lagi.
1. Pekerjaan sebenarnya dari memory adalah membuka ruang yang tidak bisa dimasuki Claude.
2. Kalau Claude bisa membacanya dari kode, jangan taruh di memory.
Prinsip yang sama dengan artikel CLAUDE.md sebelumnya. Path file, URL API, struktur direktori — semuanya bisa dijawab kode. Menjejalkannya ke memory karena malas menjalankan grep sekali berarti bertaruh bahwa informasi itu tidak akan pernah berubah.
3. Memory membusuk.
project_article_workflow adalah buktinya — ditulis beberapa hari lalu, info akun sudah salah. Semakin tua memory, semakin tidak bisa dipercaya. Audit berkala > tambah tanpa henti.
4. Kolom Why yang menyelamatkan Anda.
Bandingkan kedua feedback saya:
feedback_article_authenticity: "4-16, saya mengarang cerita di artikel multi-agent" → enam bulan kemudian saya bisa langsung menilai apakah masih berlaku.feedback_commits: hanya "user wants to review" — enam bulan kemudian saya tidak yakin koreksi mana yang melahirkan ini.Yang kedua jauh lebih lemah. Prinsip abstrak tidak bertahan — tidak ada yang ingat kenapa diberlakukan.
Saat informasi baru muncul, tanyakan tiga hal:
Pertanyaan ketiga adalah jebakan. Sebagian besar hal "tidak berubah" yang ingin Anda catat sebenarnya bisa diturunkan dari kode — Anda hanya malas menyuruh Claude grep lagi.
Setelah saya telusuri, beberapa hal muncul:
project_article_workflow bisa diturunkan dari kode. Yang ini paling butuh operasi.project_howdev_plan adalah handoff sementara — secara teori harus punya mekanisme keluar.project_i18n_strategy adalah keputusan strategis — layak ditinjau ulang beberapa bulan lagi.feedback_commits lemah; menempelkan peristiwa spesifik akan membuatnya lebih kokoh.Pengamatan sampingan: distribusi tipe saya adalah feedback×2 + project×3, tanpa satu pun tipe user atau reference. Artinya saya belum memberi tahu Claude "siapa saya" atau "sistem eksternal mana yang saya baca statusnya." Mungkin ini kelompok berikut yang perlu ditulis.
Jebakan terbesar memory bukan "apa yang seharusnya saya tulis tapi tidak saya tulis." Tapi "apa yang saya tulis yang sekarang sudah basi." Dengan 5 entri, satu yang melenceng saja cukup — Claude diam-diam menggunakan info usang untuk memutuskan, dan dia tidak akan menandai kelengserannya.
Di 5 saya, saya sudah melihat beberapa hal yang pantas diubah. Bagaimana dengan punya Anda?