Claude Code Greenfield वर्कफ़्लो: खाली रिपो से पहली स्लाइस तक

आप जो greenfield शुरुआत से बचना चाहते हैं

खाली repo से शुरू करना आज़ादी जैसा लगता है, लेकिन अक्सर यह गड़बड़ी में बदल जाता है: बहुत सारी जनरेट की हुई फाइलें, आधा-चलने वाला बिल्ड, और अगली बदल दिए जाने वाली चीज़ का कोई स्पष्ट स्थान नहीं। Claude Code greenfield वर्कफ़्लो का उद्देश्य उस पहले सप्ताह की अराजकता से बचना है।

कुछ असफलताएँ बार-बार दिखती हैं:

• कोड जो "मेरी मशीन पर काम करता है" क्योंकि सेटअप किसी की याद में रहता है, स्क्रिप्ट में नहीं।
• एक फ़ोल्डर ट्री जो चीज़ों के बनने के क्रम को दर्शाता है, न कि ऐप के बढ़ने के तरीके को।
• हर नए प्रॉम्प्ट के साथ पिछली पसंदें फिर से लिख दी जाती हैं, इसलिए कुछ भी स्थिर नहीं होता।

शुरुआती फैसले उलटने में मुश्किल होते हैं क्योंकि सब कुछ उनके ऊपर जमा हो जाता है। एक उलझा हुआ स्ट्रक्चर बार-बार मजबूत होता रहता है। एक मैन्युअल बिल्ड दस अलग सेटअप में बदल जाता है। अगर आप जल्दी में एक सरल dev कमांड लॉक इन नहीं करते, तो आपको पता नहीं चलेगा कि कोई बदलाव ऐप तोड़ रहा है या सिर्फ़ वातावरण ही टूट गया है।

जब यह पोस्ट "running app" कहती है, तो इसका एक स्पष्ट मतलब है: एक कमांड जो प्रोजेक्ट शुरू करे, अनुमानित आउटपुट दिखाए, और जब कुछ गायब हो तो ज़ोर से फ़ेल करे। आपको यह सक्षम होना चाहिए कि लोकल इंस्टॉल हटाकर, रिपो क्लोन करें, वह कमांड चलाएँ, और वही परिणाम देखें।

एक "vertical slice" सबसे छोटी एंड-टू-एंड फ़ीचर होती है जो सिद्ध करे कि आपका ऐप असली है। न कि सिर्फ़ UI मॉक। न ही सिर्फ़ डेटाबेस टेबल। यह पूरे सिस्टम में एक पतली रेखा है: एक पेज जिसमें फ़ॉर्म, एक API endpoint जो डेटा सेव करे, एक डेटाबेस राइट और रीड, और पेज पर एक दिखने वाला परिणाम।

अगर आप एक कमांड से ऐप चला सकते हैं और एक वर्टिकल स्लाइस शिप कर सकते हैं, तो आपके पास ऐसा बेस होता है जिस पर आप अनुमान लगाए बिना इटरेट कर सकते हैं।

कुछ भी जनरेट करने से पहले पहले स्लाइस का फैसला करें

एक स्पष्ट पहला स्लाइस आपके रिपो को साफ़ रखता है और आपके प्रॉम्प्ट को फोकस्ड। यह वह क्षण है जब आपको तय करना है कि आप किस चीज़ का end-to-end डेमो दिखाना चाहते हैं, न कि पूरा प्रोडक्ट क्या बनेगा।

सबसे छोटे यूज़र स्टोरी को चुनें जो साबित करे कि ऐप पूरे पथ में काम करता है। एक अच्छा स्लाइस UI, डेटा और एक असली ऐक्शन को छूता है। उदाहरण: "एक यूज़र के रूप में, मैं एक टास्क जोड़ सकता हूँ और रिफ्रेश के बाद उसे लिस्ट में देख सकता हूँ।" यह छोटा है, लेकिन यह रूटिंग, वैलिडेशन, स्टोरेज और एक बेसिक स्क्रीन की मांग करता है।

पहले सप्ताह के लिए एक लक्ष्य प्लेटफ़ॉर्म चुनें और वही रखें। अगर आप वेब से शुरू करते हैं, तो केवल वेब करें। "शायद मोबाइल" न जोड़ें। भले ही आप बाद में Koder.ai का उपयोग करने की योजना बनाते हों, पहले स्लाइस को एक ही लेन में रखना बेहतर परिणाम देगा (React वेब, या एक Go API, या Flutter)।

"सप्ताह 1 के लिए पूरा" का मतलब सादे शब्दों में परिभाषित करें:

• एक ताज़ा clone से एक कमांड पर लोकली चलना
• एक काम करने वाला फीचर जिसे आप end-to-end क्लिक कर सकें
• त्रुटियाँ एक मानवीय संदेश दिखाएँ (स्टैक ट्रेस नहीं)
• डेटा कहीं सरल जगह पर टिके (यहाँ तक कि लोकल डेटाबेस भी चलेगा)

फिर तीन non-goals लिखें जो स्कोप की रक्षा करें। उदाहरण: कोई auth नहीं, कोई theme सिस्टम नहीं, कोई बैकग्राउंड जॉब नहीं।

एक बार ये फैसले लिखे गए, तो आपका जनरेशन प्रॉम्प्ट सख्त हो सकता है: केवल वही बनाएं जो स्लाइस का समर्थन करे, और बाकी सब TODO छोड़ दें।

कुछ पहले के फैसले जो रीवर्क बचाते हैं

Claude से किसी चीज़ को जनरेट करने से पहले कुछ डिफ़ॉल्ट लॉक इन करें। ये छोटे लगते हैं, लेकिन वे बाद में "सब कुछ फिर से नामकरण" की गड़बड़ी रोکتے हैं।

पहले, ऐप की आकृति तय करें। अगर आपको सचमुच ब्राउज़र UI और बैकएंड दोनों चाहिए, तो दो स्पष्ट हिस्सों (frontend + API) के साथ शुरू करें और कॉन्ट्रैक्ट्स के लिए साझा जगह रखें (API types या एक सरल schema)। अगर ऐप एक सिंगल सर्वर-रेंडर्ड वेब ऐप बन सकता है, तो उसे एक कोडबेस में रखें ताकि लोकल डेवलपमेंट सरल रहे।

अगला, configuration नियमों पर सहमति बनाएं। एक लोकल env फ़ाइल का उपयोग करें, इसे git से बाहर रखें, और एक टेम्पलेट कमिट करें (उदाहरण के लिए, .env.example) जिसमें सुरक्षित प्लेसहोल्डर और छोटे कमेंट्स हों। इससे ऑनबोर्डिंग आसान होती है और सीक्रेट्स लीक होने की संभावना कम होती है।

डिफ़ॉल्ट dev पोर्ट चुनें और उन्हें स्थिर रखें। पोर्ट स्क्रिप्ट्स, डॉकस और त्रुटि संदेशों में पड़ जाते हैं, इसलिए बाद में बदलना परेशान करेगा। नामकरण के लिए भी यही करें: फ़ोल्डर्स, सर्विसेज और पैकेजेस एक कन्वेंशन का पालन करें। परफेक्ट कन्वेंशन से ज़्यादा संगति मायने रखती है।

एक सरल आरंभिक निर्णय सेट:

• App shape: single app या frontend + API
• Config: लोकली .env, .env.example कमिट किया गया
• Ports: एक वेब के लिए, एक API के लिए, एक DB के लिए (यदि ज़रूरत हो)
• Names: फ़ोल्डर्स के लिए एक casing स्टाइल, सुसंगत सर्विस नाम
• Secrets: कभी कमिट न करें, अगर लीक हो तो रोटेट करें

उदाहरण: आप web को पोर्ट 3000 और api को 8080 चुनते हैं। आपका env टेम्पलेट API_URL=http://localhost:8080 और DATABASE_URL=... शामिल करता है। जब Claude बाद में स्क्रिप्ट्स और डॉक जनरेट करेगा, तो सब कुछ अपनी जगह पर आ जाएगा बजाय ड्रिफ्ट करने के।

Claude Code को संरचित रखने के लिए कैसे प्रॉम्प्ट करें

रन करने योग्य स्कैफोल्ड मांगे, "पूरा ऐप" नहीं। बेकार आउटपुट का सबसे तेज़ रास्ता फीचर्स मांगना है जब उनके लिए कोई जगह नहीं है।

स्ट्रक्चर के बारे में स्पष्ट रहें। एक फ़ोल्डर लेआउट के साथ कहें और छोटे कमेंट जोड़ें जो बताते हों कि क्या कहाँ रखा जाना चाहिए और क्या नहीं। इससे फैसले पहले होते हैं न कि फ़ाइलें बिखरती जाएँ।

अनुशासित रखने का एक सरल तरीका प्रॉम्प्ट में नियम सेट करना है:

• सबसे छोटा runnable skeleton पहले बनाएँ (hello page, health endpoint, या एक स्क्रीन)
• एक फ़ोल्डर संरचना प्रस्तावित करें और हर फ़ोल्डर का 1 वाक्य में विवरण दें
• स्क्रिप्ट्स जोड़ें जो एक ताज़ा मशीन पर काम करें (install, dev, test, build) और prerequisites बताएं
• बदलाव एक PR-आकार के चंक्स में रखें और ठीक बताएं किन फाइलों को बनाया या एडिट किया जाएगा
• स्कैफोल्डिंग के बाद रुकें और बताएं कि इसे कैसे चलाना है

यहाँ एक प्रॉम्प्ट है जिसे आप फिर से उपयोग कर सकते हैं:

You are working in an empty repo. Create a minimal runnable skeleton.

Constraints:
- Keep it small: no real features yet.
- Propose a clear folder structure and add brief comments in each folder’s README.
- Add scripts for: setup, dev, test, build. They must work on a fresh machine.
- Tell me exactly how to run it, and what output I should see.
- After generating, stop and wait for my “ran it” confirmation.

Output:
1) File tree
2) Key files (only)
3) Run instructions

फिर लूप को तंग रखें। एक बार में पाँच बदलाव न मांगें। एक छोटा बदलाव जनरेट करें, चलाएँ, सटीक त्रुटि (या सफलता) पेस्ट करें, फिर एक минимल फिक्स माँगें। यह जनरेट-रन-एडजस्ट रिदम प्रोजेक्ट को पूर्वानुमेय बनाता है और संरचना के भटकने की संभावना कम करता है।

चरण-दर-चरण: खाली रिपो से एक runnable skeleton तक

एक वादा के साथ शुरू करें: कोई भी रिपो क्लोन करके एक कमांड चला कर कुछ काम करता हुआ देख सके। इससे आप असल फीचर माँगने से पहले एक स्थिर बेस ले लेते हैं।

Repo बनाएं और एक छोटा README लिखें जब सब कुछ ताज़ा हो। व्यावहारिक रखें: prerequisites, वही dev कमांड, और कैसे टेस्ट चलाएँ (यहाँ तक कि अगर टेस्ट खाली हों)।

फिर, उस टॉपर-लेवल लेआउट का चुनाव करें जो आपके चुने हुए ऐप शेप से मेल खाता हो।

अगर आप कई deployable टुकड़े बना रहे हैं (उदाहरण: frontend + API), तो एक workspace लेआउट मदद कर सकता है:

/
  apps/
  packages/
  scripts/
  docs/
  README.md

अगर आप एक सिंगल ऐप बना रहे हैं, तो इसे साधारण रखें और ज़रूरत पड़ने तक अतिरिक्त लेवल से बचें।

अब न्यूनतम गार्डरेइल जोड़ें ताकि कोड सुसंगत रहे। एक formatter और एक linter चुनें, उनके डिफ़ॉल्ट स्वीकार करें, और हर एक के लिए एक कॉन्फ़िग फ़ाइल जोड़ें। उद्देश्य साफ़ diffs हैं, न कि हर चीज़ पर परफेक्ट नियम उस पहले दिन।

डेवलपर अनुभव को प्रेडिक्टेबल बनाएं एक कमांड से जो हमेशा रूट से काम करे। यहाँ एक सरल रूप दिया गया है:

{
  "scripts": {
    "dev": "echo \"start dev server here\"",
    "build": "echo \"build here\"",
    "test": "echo \"tests here\"",
    "lint": "echo \"lint here\""
  }
}

उस dev कमांड को चलाएँ, पुष्टि करें कि यह साफ़ तरीके से निकलता है (या एक प्लेसहोल्डर सर्वर बूट करता है), फिर केवल स्कैफोल्डिंग के साथ पहला commit करें। अगर कोई teammate (या भविष्य का आप) ताज़ा सेटअप दोहराकर चला सके, तो आप पहले स्लाइस का निर्माण करने के लिए तैयार हैं।

जैसा ऐप बढ़ता है वैसे रख सकने वाली फ़ोल्डर संरचना

एक अच्छा greenfield स्ट्रक्चर दो काम करता है: यह कोड जल्दी ढूँढने में मदद करता है, और Claude को हर बार नई पैटर्न गढ़ने की जगह कम देता है। लक्ष्य पूर्णता नहीं है। लक्ष्य स्थिरता है।

यदि आप एक single app में काम कर रहे हैं (या apps/<name>/ फ़ोल्डर के अंदर), एक सरल इंटर्नल लेआउट सामान्यतः अच्छा रहता है:

• src/ ऐप कोड (फीचर्स, साझा हिस्से, एंट्री प्वाइंट)
• config/ गैर-सीक्रेट कॉन्फ़िगरेशन
• tests/ उच्च-स्तरीय टेस्ट जो यूज़र व्यवहार की तरह पढ़ें
• scripts/ हेल्पर स्क्रिप्ट्स (dev setup, db reset, release tasks)
• docs/ छोटे नोट्स और चेकलिस्ट जिन्हें आप वास्तव में मेंटेन करते हैं

src/ के अंदर, फ़ीचर कोड और साझा कोड को परिवर्तन पैटर्न के आधार पर अलग रखें। फीचर कोड अक्सर बदलता है और उसे पास में रखा जाना चाहिए। साझा कोड बोझिल और पुन:उपयोगी होना चाहिए।

एक व्यावहारिक नियम: UI स्क्रीन, हैंडलर्स, और फीचर-विशिष्ट लॉजिक src/features/<featureName>/... के अंतर्गत रखें। लॉगिंग, API क्लाइंट, design system कम्पोनेंट्स, और सामान्य यूटिलिटीज़ src/shared/... के अंतर्गत रखें। अगर कोई हेल्पर केवल एक फीचर के लिए मायने रखता है, तो उसे उसी फीचर में रखें भले ही वह पुन:उपयोगी लगे। जब दूसरे असली उपयोग हों तब उसे हटाएं।

फ़ोल्डर नाम उद्देश्य का वर्णन करें, टेक्नोलॉजी नहीं। “features” और “shared” आपके स्टैक बदलने पर भी अर्थ रखेंगे। “misc” या “new” जैसी नामों से बचें।

docs/ को छोटा रखें। एक अच्छा स्टार्टर docs/checklists.md है जिसमें कुछ पंक्तियाँ हों: कैसे चलाएँ, कैसे टेस्ट करें, कैसे नया फीचर फ़ोल्डर जोड़ें, और "done" का क्या मतलब है।

प्रोजेक्ट को प्रेडिक्टेबल बनाने वाली बिल्ड स्क्रिप्ट्स

एक रिपो तब असली लगता है जब कोई भी वही कमांड चला कर वही परिणाम पाता है। स्क्रिप्ट्स गार्डरेइल हैं: वे अनुमान घटाते हैं, बदलाव छोटे रखते हैं, और यह स्पष्ट करते हैं कब कुछ टूट गया।

छोटे कमांड्स से शुरू करें और उन्हें साधारण रखें। अगर कोई नया जुड़ता है (या आप दो सप्ताह बाद वापस आते हैं), तो उन्हें किसी स्पेशल फ्लैग या छिपे कदम की ज़रूरत न पड़े।

यहाँ एक सरल बेसलाइन है जिसे आप किसी भी स्टैक पर अनुकूलित कर सकते हैं:

{
  "scripts": {
    "dev": "node ./scripts/dev.js",
    "build": "node ./scripts/build.js",
    "test": "node ./scripts/test.js",
    "test:quick": "node ./scripts/test.js --quick",
    "test:full": "node ./scripts/test.js --full",
    "format": "node ./scripts/format.js",
    "lint": "node ./scripts/lint.js",
    "smoke": "node ./scripts/smoke.js"
  }
}

dev स्क्रिप्ट को हैप्पी पाथ बनाएं। इसे ऐप स्टार्ट करना चाहिए, जहाँ यह चल रहा है वह प्रिंट करे, और लॉग्स पढ़ने योग्य रखें। अगर सर्वर स्टार्ट नहीं हो पा रहा है, तो फ़ेल फास्ट करें और एक स्पष्ट संदेश दें (missing env var, port already used, database not reachable)।

build स्क्रिप्ट को हमेशा एक clean output डायरेक्टरी बनानी चाहिए। पहले पुरानी आउटपुट मिटाएँ, फिर नए आर्टिफैक्ट्स बनाएं। इससे कल की फाइलों से होने वाली अजीब बग्स बचती हैं।

टेस्ट्स के लिए quick चेक्स और slow चेक्स अलग रखें। Quick tests हर बदलाव पर चलें (unit tests, type checks). Full tests में integration चेक्स शामिल हों और वे merge से पहले चलें।

स्टाइल को एक कमांड से नियंत्रित रखें। एक सरल नियम: format चीज़ें ठीक कर देता है, lint शिकायतें दिखाता है।

अंत में, एक smoke चेक जोड़ें जो बुनियादी चीज़ों का सत्यापन करे ताकि आप फालतू डिबगिंग न करें:

• ज़रूरी env vars सेट हों (और खाली न हों)
• चुने हुए पोर्ट फ्री हों
• ऐप स्टार्ट हो सके और एक साधारण रिक्वेस्ट का उत्तर दे सके
• डेटाबेस कनेक्शन काम करे (यदि इस्तेमाल हो)
• build के बाद build आउटपुट मौजूद हो

पहला वर्टिकल स्लाइस फीचर बनाना

आपका पहला वर्टिकल स्लाइस ऐप को एंड-टू-एंड साबित करना चाहिए, सिर्फ़ UI दिखाना नहीं। इसका मतलब है एक छोटा फीचर जो स्क्रीन, लॉजिक और किसी तरह के स्टोरेज को छुए, भले ही स्टोरेज अस्थायी हो।

कोई बोरिंग और उपयोगी चीज़ चुनें, जैसे “नोट जोड़ना” या “टास्क बनाना।” इसे एक सत्र में खत्म करने लायक छोटा रखें, पर इतना पूरा कि आप क्लिक करके असल स्टेट चेंज देख सकें।

एक अच्छा स्लाइस चार भागों में होता है: एक रूट या स्क्रीन, एक फ़ॉर्म, एक सेव एक्शन, और एक डिस्प्ले। उदाहरण: एक "New Task" पेज जिसमें टाइटल इनपुट, Save बटन जो एक फ़ंक्शन को कॉल करे, और एक लिस्ट जो सेव किए गए टास्क दिखाए।

पहले एक प्लेसहोल्डर स्टोर से शुरू करें ताकि तेज़ काम कर सकें। एक इन-मेमोरी एरे, लोकल JSON फ़ाइल, या एक सरल स्टब इंटरफ़ेस ठीक है। महत्वपूर्ण बात यह है कि आप एक बाउंडरी बनाएं जिसे बाद में बदला जा सके। अगर आपका कोड आज taskRepository.save(task) कॉल करता है, तो वास्तविक डेटाबेस में बदलना छोटा बदलाव होगा, न कि रीराइट।

UI सादे रखें। डिजाइन सिस्टम बहस, खाली स्टेट्स, और एनिमेशन छोड़ दें।

तेज़ स्वीकृति चेक जिन्हें आप दो मिनट में कर सकते हैं:

• पेज बिना त्रुटि खुले
• आप एक वैल्यू टाइप करके Save दबा सकें
• नया आइटम तुरंत दिखाई दे
• रीलोड अपेक्षित व्यवहार दिखाए (यदि रीयल स्टोरेज है तो पर्सिस्टेड, नकली स्टोर में रीसेट)
• ख़राब इनपुट संभाला जाए (खाली टाइटल संदेश दिखाए और सेव न करे)

इटरेट करने के लिए इसे पर्याप्त स्थिर बनाना

एक runnable skeleton और एक वर्टिकल स्लाइस के बाद लक्ष्य बदलता है: ब्रेकेज़ को स्पष्ट बनाएं, और फिक्स तेज़ रखें। यही वह जगह है जहां कई greenfield शुरुआत विफल हो जाती हैं — समस्या फीचर में नहीं बल्कि छोटी बदलावों की वजह से होने वाली आश्चर्यजनक गड़बड़ियों में होती है।

हर बार जब आप एक स्लाइस जोड़ते हैं तो एक छोटा स्थिरता बार सेट करें:

• एक smoke टेस्ट जो साबित करे कि ऐप बूट होता है और मुख्य रूट/स्क्रीन रेंडर होता है
• एक smoke टेस्ट जो स्लाइस को end-to-end हिट करे (यहाँ तक कि टेस्ट डेटाबेस का उपयोग करके)
• स्पष्ट त्रुटि संदेश जो सामान्य उपयोगकर्ता समझ सके (स्टैक ट्रेस नहीं)
• डेवलपर लॉग्स जो बिना सीक्रेट्स के बताएँ क्या हुआ
• न्यूनतम निर्भरताएँ, वर्शन पिन्ड, और अपग्रेड सोच-समझकर करें

ठोस उदाहरण: आपका पहला स्लाइस उपयोगकर्ता को एक "Project" बनाने और उसे लिस्ट में देखने देता है। एक टेस्ट जोड़ें जो सर्वर शुरू करे, create endpoint को कॉल करे, फिर लिस्ट फेच करे और चेक करे कि नया आइटम दिखाई दे। अगर यह फेल हो, तो वह जोर से फेल होना चाहिए एक सहायक संदेश के साथ, जैसे "Create Project endpoint returned 500" — न कि बहुत सारा आउटपुट।

एरर हैंडलिंग के लिए एक छोटा सेट रखें। वैलिडेशन एरर्स एक छोटा संदेश लौटाएँ ("Name is required") और एक फ़ील्ड नाम। अनपेक्षित एरर्स "कुछ गड़बड़ हो गई। फिर कोशिश करें।" लौटाएँ। विवरण लॉग्स में रखें।

लॉगिंग सबसे उपयोगी तब है जब यह उत्तर दे: किस रिक्वेस्ट ने किया, कौन सा यूज़र (या anonymous), क्या फेल हुआ, और कहाँ। dev में एक request id और timing शामिल करें, पर डिफ़ॉल्ट रूप से टोकन, पासवर्ड, API कीज़ या पूरा पेलोड न डंप करें।

एक छोटा health check जोड़ें। वेब पर यह /health endpoint हो सकता है जो ok लौटाए। मोबाइल पर यह एक "Connected" स्थिति हो सकती है जो backend तक न पहुँचने पर "Offline" में बदल जाए। यह डिबगिंग से पहले एक तेज़ संकेत है।

AI का उपयोग करते समय सामान्य जाल

सबसे तेज़ तरीका जिससे आप एक greenfield शुरुआत बर्बाद कर देते हैं, वह है मॉडल से पूरा ऐप माँगना और फिर उसे बाद में चलाना। बड़े जनरेशन छोटे गल्तियों को छुपाते हैं: गुम निर्भरताएँ, गलत import पाथ, स्क्रिप्ट जो ऐसे टूल्स मानते हैं जो आपके पास नहीं हैं। हर आउटपुट को ऐसे समझें कि आपको मिनटों में चला सकना चाहिए।

एक और जाल परफेक्ट आर्किटेक्चर डिजाइन करना है जब कोई फीचर नहीं है। फ़ोल्डर नेम्स पर बहस करना उत्पादक लग सकता है, पर जब तक कोई असली स्लाइस नहीं है आप नहीं बता सकते कि क्या अजीब होगा। एक सरल संरचना जो एक काम करने वाले पाथ का समर्थन करे, एक चालाक परफेक्ट संरचना से बेहतर है जिसे आपने टेस्ट नहीं किया।

Command drift भी आम है। AI एक नया तरीका जोड़ देता है सर्वर स्टार्ट करने का, आप एक और जोड़ते हैं टेस्ट के लिए, और जल्द ही कोई नहीं जानता कौन सा "वह" कमांड है। अगर कोई teammate रिपो क्लोन कर के पूछे "मैं इसे कैसे चलाऊँ?", तो आप पहले से ब्याज़ चुका रहे होते हैं।

सबसे ज़्यादा रीवर्क कर देने वाली गलतियाँ:

• एक runnable पाथ बनाने की बजाय एक बार में कई सर्विसेज, स्क्रीन और कॉन्फ़िग जनरेट करना
• पहले फीचर के end-to-end काम करने से पहले auth, payments, जटिल स्टाइलिंग और पूरा डेटा मॉडल खींच लेना
• सेटअप निर्देशों को चैट में छोड़ देना बजाय स्क्रिप्ट्स (या एक README) के
• एक साफ़ env टेम्पलेट भूल जाना, ताकि अगली मशीन बिना अनुमान के स्टार्ट न कर सके

सरल उदाहरण: आप "complete" ऐप जनरेट करते हैं जिसमें login, theming, और billing है, पर पहली रन फेल हो जाती है क्योंकि एक सीक्रेट की कमी है और कोई .env.example नहीं है। आप फिर एक घंटा सेटअप ठीक करने में बिताते हैं बजाय यह जानने के कि फीचर उपयोगी है या नहीं।

ईमानदार रहें: एक runnable कमांड, एक छोटा फीचर, एक env टेम्पलेट, फिर बढ़ाएँ।

इटरेशन शुरू करने से पहले त्वरित चेकलिस्ट

"एक और फीचर" जोड़ने से पहले सुनिश्चित करें कि प्रोजेक्ट कल उठाकर किसी और के लिए आसान हो। स्पीड लक्ष्य नहीं है; प्रेडिक्टेबिलिटी है।

• एक-कमांड रन: नया डेवलपर env टेम्पलेट कॉपी करे, कुछ आवश्यक मान सेट करे, और एक कमांड से ऐप स्टार्ट कर दे। अगर अतिरिक्त कदम चाहिए (DB setup, migrations, seed data), तो उन्हें एक स्क्रिप्ट में कैप्चर करें।
• स्क्रिप्ट्स बेसिक कवर करें: dev, test, build के लिए स्पष्ट कमांड और एक तेज़ smoke चेक।
• सुस्पष्ट संरचना: लेआउट बिना पूरा कोड पढ़े एक कहानी बताता हो (app code, config, scripts, tests)।
• वर्टिकल स्लाइस डेमो पाथ: आप डेमो एक वाक्य में बता सकें, जैसे "एक आइटम बनाएं, लिस्ट में देखें, रिफ्रेश करें, वह वहां रहे।"
• रोलबैक पॉइंट: बड़े बदलावों से पहले आपके पास वापसी का सुरक्षित बिंदु हो (एक साफ़ commit, एक टैग, या snapshot/rollback मैकेनिज़्म)।

अगर कोई भी आइटम फेल हो, तो अभी ठीक करें। स्क्रिप्ट्स और नामकरण टाइट करना सस्ता है जब रिपो छोटा हो।

अगले कदम: वर्कफ़्लो को दोहराने योग्य आदत बनाना

एक greenfield शुरुआत तभी फ़ायदेमंद है जब आप इसे दोहरा सकें। एक बार आपका पहला वर्टिकल स्लाइस end-to-end चलने लगे, तो अच्छे हिस्सों को एक छोटे टेम्पलेट में फ्रीज़ कर दें: वही फ़ोल्डर पैटर्न, वही स्क्रिप्ट नाम, और वही तरीका जिससे आप UI, API और डेटा जोड़ते हैं।

अपने पहले स्लाइस को संदर्भ कार्यान्वयन की तरह ट्रीट करें। जब आप स्लाइस #2 शुरू करें, आकार कॉपी करें, कोड नहीं। अगर स्लाइस #1 में एक रूट, एक हैंडलर, एक डेटा एक्सेस लेयर, और एक बेसिक टेस्ट है, तो स्लाइस #2 को वही रास्ता अपनाना चाहिए।

योजना हल्की रखें। अगले 2-3 स्लाइस के लिए एक पन्ने का नोट पर्याप्त है: हर स्लाइस का लक्ष्य और यूज़र कार्रवाई (एक वाक्य), आवश्यक डेटा, "done" चेक्स, और कोई जोखिम जिन्हें जल्दी परखा जाना चाहिए।

फिर मेंटेनेंस को आदत बनाएं। हफ्ते में एक बार छोटा क्लीनअप पास करें: स्क्रिप्ट्स टाइट करें, README में कोई नए सेटअप स्टेप जोड़ें, और अपना env example फ़ाइल रिफ्रेश करें ताकि ऑनबोर्डिंग आसान रहे।

अगर आप चैट-फर्स्ट बिल्ड लूप पसंद करते हैं, तो Koder.ai (koder.ai) एक विकल्प है जो planning मोड, स्नैपशॉट और रोलबैक सपोर्ट करता है, और जब चाहें तब सोर्स कोड एक्सपोर्ट कर सकता है।

लक्ष्य एक ऐसा वर्कफ़्लो है जिसे आप बिना सोचे चला सकें: 2-3 स्लाइस प्लान करें, एक स्लाइस बनाएं, स्थिर करें, दोहराएँ।