ConfigDeck (https://configdeck.dev/ko) adında küçük bir araç yaptım.
Yapılandırma dosyası oluşturucu başlı başına yaygın bir konu ama yapım şekli biraz deneysel olduğu için deneyimi paylaşmak istedim.
Nedir
Her proje başlangıcında .eslintrc, prettier.config, tsconfig gibi yapılandırma dosyalarını önceki projeden kopyala-yapıştır yapmak uğraştırıcı olduğundan, seçenekleri seçip indirilen bir yapı hazırladım.
- 9 tür yapılandırma dosyası desteği: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
.gitignore,.editorconfig,.env.example - Yığın önayarları: React+Vite, Next.js, Astro, Node.js vb. ile tek seferde birden fazla dosya oluşturma
.eslintrc→eslint.config.mjsgeçişi (Flat Config dönüşümü)- Korece / İngilizce desteği
- %100 statik site (Cloudflare Pages, içerik sayfalarında JS 0KB)
- Girdi değerleri yalnızca tarayıcı içinde işlenir, dışarı aktarılmaz
Teknoloji yığını: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict
Nasıl yaptım — yapay zekaya epey görev verdim
Bu kez Claude Code kullanarak geliştirme sürecinin kendisini düzenlemeyi denedim.
Yön belirleme ve ara kontrol gibi işleri insan yaptı; uygulamayı ise olabildiğince yapay zekaya bıraktım. İyi giden taraflar da oldu, çok sayıda deneme-yanılma da yaşandı; ama süreci paylaşmanın benzer denemeler yapanlara faydalı olabileceğini düşündüğüm için toparladım.
Depodaki .claude/ dizininde kullandığım tüm ayarları açık bıraktım:
https://github.com/jsg3121/configDeck/tree/main/.claude
- Harness belgeleri (
CLAUDE.md, conventions, ADR vb.) - Alan bazlı ajanlar (
config-maker,ui-publisher,ux-designer,
qa-agent,seo-specialistvb.) - Slash skill'ler (
/lint-check,/code-review,/seo-audit,/researchvb.) - Teknik kararların ADR ile kaydı
- Otomasyon hook'ları (PostToolUse formatting, Stop build/lint doğrulaması)
Yazarken özellikle dikkat ettiğim şey “Why-First” yaklaşımıydı. Sadece kuralları yazmak yerine nedenlerini de birlikte yazınca, yapay zekanın edge case'lerde daha tutarlı karar verdiği hissi oluştu.
Ajanları kabaca şu akışta birlikte çalışacak şekilde kurguladım:
product-planner → ux-designer → ui-publisher → qa-agent
(planlama) (tasarım) (uygulama) (doğrulama)
QA tarafında unit-tester / e2e-tester / static-analyzer alt ajanları var; qa-agent bunların sonuçlarını toplayıp rapor oluşturan yapı olarak çalışıyor.
Deneme-yanılmalar
İyi tarafları
- Kararları ADR ile kaydedince, zaman geçse bile “Bunu neden böyle yazmıştım?” diye dönüp bakmak kolay oldu.
- Harness içine convention'ları yazınca, oturum değişse bile çıktılar nispeten tutarlı görünmeye başladı.
- Ajanları alanlara göre ayırınca, planlama ile uygulama aynı bağlam içinde birbirine karışmadığı için süreci takip etmek kolaylaştı.
Zor tarafları
- Başta harness olmadığı için çıktıların stili her seferinde dalgalanıyordu; şu anki hale gelene kadar birkaç kez yeniden düzenledim.
- Token maliyeti düşündüğümden daha yüksekti; bu yüzden işin ölçeğine göre ana sohbet / skill / ajan kullanımını seçmek için ayrı bir rehber hazırlayıp kullanıyorum.
- Yapay zeka bazen sanki her şey yolundaymış gibi raporlayabildiği için, Stop hook ile build / lint doğrulamasını otomatik yapmak faydalı oldu.
Henüz doğru cevabı bulduğumu söylemek zor; muhtemelen daha iyi bir yöntem vardır.
Bağlantılar
- Site: https://configdeck.dev/ko
- Depo: https://github.com/jsg3121/configDeck
- Harness dizini: https://github.com/jsg3121/configDeck/tree/main/.claude
1 yorum
İlginç bir fikir. Her zaman sadece greenfield projeler yapmadığımız için, tersine mevcutta darmadağın olmuş bir config dosyasını verince bunun hangi seçenekler olduğunu açıklayıp açıp kapatmanıza da izin verse eğlenceli olurdu.