Claude Code हार्नेस से बनाया गया config file generator - ConfigDeck

ConfigDeck (https://configdeck.dev/ko) नाम का एक छोटा टूल बनाया है.
Config file generator अपने आप में कोई नया विषय नहीं है, लेकिन इसे बनाने का तरीका थोड़ा प्रयोगात्मक था, इसलिए यह अनुभव साझा करना चाहता था.

यह क्या है

हर बार प्रोजेक्ट शुरू करते समय .eslintrc, prettier.config, tsconfig जैसी config files को पिछले प्रोजेक्ट से copy-paste करना झंझट लगता था, इसलिए इसे ऐसे बनाया कि आप options चुनकर डाउनलोड कर सकें.

• 9 तरह की config files का समर्थन: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
  .gitignore, .editorconfig, .env.example
• stack presets: React+Vite, Next.js, Astro, Node.js आदि, जिनसे एक साथ कई files generate की जा सकती हैं
• .eslintrc → eslint.config.mjs migration (Flat Config conversion)
• कोरियाई / अंग्रेज़ी समर्थन
• 100% static site (Cloudflare Pages, content pages JS 0KB)
• input values केवल browser के अंदर process होते हैं, बाहर कहीं भेजे नहीं जाते

tech stack: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict

बनाने का तरीका — AI को काफ़ी ज़्यादा सौंपकर देखा

इस बार Claude Code का उपयोग करके development process को ही व्यवस्थित करने की कोशिश की.
दिशा तय करना और बीच-बीच में review करना इतना हिस्सा इंसान ने किया, और implementation जितना संभव हो AI को सौंपने की कोशिश की. कुछ हिस्से अच्छे रहे और trial and error भी बहुत हुआ, लेकिन सोचा कि अगर यह प्रक्रिया साझा करूँ तो ऐसे ही प्रयोग करने वालों के लिए यह उपयोगी संदर्भ बन सकती है, इसलिए इसे लिखा.

repository की .claude/ directory में इस्तेमाल की गई सभी settings सार्वजनिक कर दी हैं:
https://github.com/jsg3121/configDeck/tree/main/.claude

• harness docs (CLAUDE.md, conventions, ADR आदि)
• domain-specific agents (config-maker, ui-publisher, ux-designer,
  qa-agent, seo-specialist आदि)
• slash skills (/lint-check, /code-review, /seo-audit, /research आदि)
• ADR के ज़रिए technical decision records
• automation hooks (PostToolUse formatting, Stop build/lint verification)

इसे लिखते समय मैंने खास तौर पर "Why-First" पर ध्यान दिया. सिर्फ़ rules लिखने की बजाय उनके पीछे का कारण भी साथ लिखा, तो लगा कि edge cases में AI थोड़ा अधिक consistent तरीके से निर्णय लेता है.

agents को मोटे तौर पर इस flow में collaborate करने के लिए व्यवस्थित किया गया:

product-planner → ux-designer → ui-publisher → qa-agent
(planning) (design) (implementation) (verification)

QA में unit-tester / e2e-tester / static-analyzer sub-agents रखे गए हैं, और qa-agent उनके results इकट्ठा करके report बनाता है.

trial and error

अच्छी बातें

• ADR में decisions दर्ज रहने से, समय बीतने के बाद भी "इसे ऐसे क्यों बनाया था?" पर वापस जाना आसान रहा.
• harness में conventions लिख देने से session बदलने पर भी outputs काफ़ी हद तक consistent मिलते हैं.
• domain के हिसाब से agents अलग रखने पर planning और implementation एक ही context में उलझते नहीं, इसलिए उन्हें follow करना आसान था.

चुनौतियाँ

• शुरुआत में harness न होने की वजह से output style हर बार बदल जाती थी, और इसे मौजूदा रूप में व्यवस्थित करने तक कई बार फिर से सुधारना पड़ा.
• token cost उम्मीद से ज़्यादा भारी निकली, इसलिए काम के पैमाने के अनुसार main chat / skill / agent चुनकर इस्तेमाल करने के लिए अलग guide बनाकर उपयोग कर रहा हूँ.
• कभी-कभी AI काम ठीक होने जैसा report कर देता है, इसलिए Stop hook से build / lint को automatically verify करवाना मददगार रहा.

अभी यह कहना मुश्किल है कि सही जवाब मिल गया है; शायद इससे बेहतर तरीका भी हो सकता है.

लिंक

• साइट: https://configdeck.dev/ko
• repository: https://github.com/jsg3121/configDeck
• harness directory: https://github.com/jsg3121/configDeck/tree/main/.claude

[heycalmdown]

काफ़ी मज़ेदार आइडिया है। हमेशा सिर्फ़ greenfield project ही नहीं होते, तो उल्टा अगर पहले से बिगड़ी हुई config file डालें, तो वह यह समझा दे कि कौन-कौन से options हैं और उन्हें on/off करने दे, तो वह भी मज़ेदार होगा।