Plane onboarding satu pintu: logika di pusat, data di tepi
Nyaris menyalin folder skill plane-init ke tiap repo. Ternyata satu pintu lebih sehat: logika di satu repo, config dan template di repo konsumen.
Ringkasan
Gue hampir copy-paste skill plane-init ke tiap repo biar mandiri tapi sadar itu bakal jadi mimpi buruk maintenance. Akhirnya skill dibikin terpusat aja, repo lain cuma simpan config ringan dan template. Enak soalnya skill berat tetap murah diload, logic di pusat data di pinggiran.
Tangan saya udah di atas keyboard, siap ngetik cp -r buat menduplikat folder skill plane-init ke repositori kedua. Untung berhenti duluan.
Insting awal saya simpel: portabilitas berarti tiap repo harus bawa salinan lengkap skill-nya. Mandiri, nggak perlu tarik-menarik antar repo. Kedengarannya masuk akal, sampai saya bayangkan enam bulan ke depan. Satu bug fix di skill, lima repo harus diingat buat di-update satu-satu. Copy-paste ke mana-mana bukan portabilitas, itu utang pemeliharaan yang dibungkus rapi.
Jadi desain finalnya justru kebalikannya: Plane onboarding satu pintu. Skill plane-init tinggal di satu repo dan jadi satu-satunya titik masuk onboarding. Repo konsumen cuma bawa tiga barang ringan: config .pm/plane.json, template markdown, dan aturan proyek. Nggak ada fork, nggak ada salinan SKILL.md tersebar.
Logika di pusat, data di tepi
Keputusan ini ada alasannya, dan alasannya kecil aja: cara Claude Code memuat skill. Body skill baru dimuat saat dipakai [3], jadi numpukin materi referensi panjang di satu skill pusat itu murah. Repo yang jarang ngobrol sama Plane nggak kena penalti apa-apa.
Semua yang butuh jaringan, kayak resolusi proyek, pencarian modul dan label, sampai bikin work item, jadi tanggung jawab protokol di SKILL.md dan dijalankan lewat panggilan MCP. Permukaan MCP Plane sendiri nyediain 28 tools dengan 183 actions [2]. Sementara itu helper init.py sengaja dibuat murni offline, stdlib doang. Dia nggak tahu cara ngobrol sama server, dan justru itu poinnya: bagian yang bisa dites tanpa jaringan terpisah total dari bagian yang butuh kredensial.
Saya makin yakin pola ini berlaku buat skill apa pun yang nyentuh banyak repo: helper offline dulu, protokol online belakangan. Nggak boleh kebalik, karena yang online susah dites dan yang offline nggak butuh server.
Wujud konkretnya di repo konsumen sekarang cuma segini: folder .pm/ berisi config, folder template yang di-scaffold saat onboarding, dan beberapa baris aturan di AGENTS.md proyek itu. Nggak ada folder skill, nggak ada script yang ikut versioning dobel. Skill bisa berkembang tiap minggu, sedangkan repo konsumen hidup bertahun-tahun; dua ritme hidup yang beda ini justru paling aman nggak disatukan.
Selfcheck ngetes hasil, bukan templatenya
Satu hal yang hampir kepleset pas nulis commit template: selfcheck-nya ngetes scaffolding yang di-generate di root target, bukan file template-nya. Ngetes template doang itu rasa aman palsu. Template bagus nggak menjamin hasil rakitannya bener.
Di helper-nya sendiri ada beberapa yang gampang dianggap remeh. Path safety lewat resolved-path containment, jadi path relatif dari config nggak bisa kabur keluar root repo. Validasi config v2/v3. Terus penulisan config dilakukan atomik: tulis ke file tmp dulu, baru os.replace. Scaffold-nya juga anti-nimpa; file yang udah ada nggak pernah ditimpa, dan kalau dijalanin ulang dia cuma lapor status. Idempoten, jadi re-run itu murah sekaligus aman.
Dua detail favorit saya: marker plane-doc-sync:v2 path=<rel> cuma satu baris teks biasa, dan hash-nya sha256(normalize_body(text)) dihitung dengan aturan yang sama persis di sync.py. Aturan validasinya bahkan sengaja dinyatakan ulang di sana, bukan diimpor lintas direktori skill. Skills nggak bisa saling import antar folder, jadi duplikasi yang disiplin lebih jujur daripada impor yang rapuh.
Identitas yang nggak goyah
Di sisi Plane, deskripsi work-item punya field description_stripped: teks biasa yang di-generate server dan jadi bidang identitas yang stabil [1]. Marker dan hash di repo konsumen nyambung langsung ke kontrak itu. Identitas disimpen sebagai teks yang kelihatan, bukan komentar HTML yang bisa lenyap disapu sanitasi server. Saya pernah kena sendiri pas probe kemarin, dan seluruh onboarding ini dirancang supaya kejadian itu nggak perlu keulang.
Kalau besok muncul skill ketiga yang harus nyentuh banyak repo, saya nggak akan mulai lagi dari pertanyaan cara distribusinya. Mulai dari mana logika yang layak tinggal di satu tempat, dan mana data yang emang harus tinggal di tiap repo. Sisanya ngikut.