Saya membuat sebuah alat kecil bernama ConfigDeck (https://configdeck.dev/ko).
Generator file konfigurasi sendiri adalah topik yang umum, tetapi karena cara membuatnya agak eksperimental, saya ingin membagikan pengalamannya.
Apa itu
Setiap kali memulai proyek, menyalin-tempel file konfigurasi seperti .eslintrc, prettier.config, dan tsconfig dari proyek sebelumnya terasa merepotkan, jadi saya membuatnya dalam bentuk memilih opsi lalu mengunduh hasilnya.
- Mendukung 9 jenis file konfigurasi: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
.gitignore,.editorconfig,.env.example - Preset stack: React+Vite, Next.js, Astro, Node.js, dll. untuk membuat beberapa file sekaligus
- Migrasi
.eslintrc→eslint.config.mjs(konversi Flat Config) - Mendukung bahasa Korea / Inggris
- Situs 100% statis (Cloudflare Pages, JS halaman konten 0KB)
- Nilai input hanya diproses di dalam browser, tidak dikirim ke luar
Tech stack: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict
Cara membuatnya — banyak dipercayakan ke AI
Kali ini saya mencoba merapikan proses pengembangan itu sendiri dengan memanfaatkan Claude Code.
Yang dikerjakan manusia kurang lebih hanya menentukan arah perencanaan dan melakukan pengecekan di tengah jalan, sedangkan implementasinya sebisa mungkin saya serahkan ke AI. Ada bagian yang berjalan baik dan ada juga banyak trial and error, tetapi saya merangkumnya karena rasanya proses ini bisa menjadi referensi bagi orang-orang yang mencoba hal serupa.
Semua konfigurasi yang digunakan saya buka di direktori .claude/ pada repositori:
https://github.com/jsg3121/configDeck/tree/main/.claude
- Dokumen harness (
CLAUDE.md, conventions, ADR, dll.) - Agen per domain (
config-maker,ui-publisher,ux-designer,
qa-agent,seo-specialist, dll.) - Slash skill (
/lint-check,/code-review,/seo-audit,/research, dll.) - Pencatatan keputusan teknis dengan ADR
- Hook otomatis (formatting
PostToolUse, verifikasi build/lint saatStop)
Hal yang paling saya perhatikan saat menulisnya adalah "Why-First". Alih-alih hanya menuliskan aturan, saya juga menuliskan alasannya, dan saya merasa itu membuat AI menilai edge case dengan lebih konsisten.
Agen-agen tersebut saya susun untuk berkolaborasi kira-kira dengan alur seperti ini:
product-planner → ux-designer → ui-publisher → qa-agent
(perencanaan) (desain) (implementasi) (verifikasi)
Untuk QA, saya menempatkan subagen unit-tester / e2e-tester / static-analyzer, lalu qa-agent mengumpulkan hasilnya dan membuat laporan.
Trial and error
Hal yang bagus
- Karena keputusan dicatat dengan ADR, bahkan setelah waktu berlalu, lebih mudah untuk menelusuri kembali, "kenapa implementasinya dibuat seperti ini?"
- Dengan menuliskan convention di harness, hasilnya tampak relatif konsisten meski sesi berganti.
- Dengan memisahkan agen berdasarkan domain, perencanaan dan implementasi tidak bercampur dalam satu konteks, sehingga lebih mudah diikuti.
Hal yang sulit
- Di awal, karena belum ada harness, gaya hasilnya berubah-ubah setiap kali, dan saya harus menyempurnakannya beberapa kali sampai menjadi bentuk seperti sekarang.
- Biaya token ternyata lebih membebani dari perkiraan, jadi saya membuat panduan terpisah untuk memilih antara percakapan utama / skill / agen sesuai skala pekerjaan.
- Karena ada kalanya AI melaporkan seolah-olah semuanya berjalan baik, penggunaan hook
Stopuntuk memverifikasi build / lint secara otomatis sangat membantu.
Saya masih sulit mengatakan bahwa saya sudah menemukan jawaban yang tepat, dan sepertinya masih ada cara yang lebih baik.
Tautan
- Situs: https://configdeck.dev/ko
- Repositori: https://github.com/jsg3121/configDeck
- Direktori harness: https://github.com/jsg3121/configDeck/tree/main/.claude
1 komentar
Ide yang menarik. Kita tidak selalu hanya mengerjakan proyek greenfield, jadi sebaliknya, akan menarik juga kalau kita bisa memasukkan file config lama yang sudah berantakan, lalu sistem menjelaskan tiap opsinya dan memungkinkan kita menyalakan atau mematikannya.