06 जन॰ 2026·8 मिनट
स्पष्ट और सुसंगत AI-बिल्ट ऐप्स के लिए एक-पृष्ठ स्पेक टेम्पलेट
एक-पृष्ठ ऐप स्पेक टेम्पलेट का उपयोग करके अस्पष्ट आइडिया को Planning Mode के लिए स्पष्ट प्रांम्प्ट में बदलें — उपयोगकर्ता, JTBD, एंटिटीज़ और एज-केसेस कवर किए गए।
एक-पृष्ठ ऐप स्पेक टेम्पलेट का उपयोग करके अस्पष्ट आइडिया को Planning Mode के लिए स्पष्ट प्रांम्प्ट में बदलें — उपयोगकर्ता, JTBD, एंटिटीज़ और एज-केसेस कवर किए गए।
अस्पष्ट आइडिया सपना देखने के लिए ठीक है। निर्माण के लिए यह मुश्किल है।
जब आप AI बिल्डर से सिर्फ "एक हैबिट ट्रैकिंग ऐप" पूछते हैं बिना और विवरण के, तो उसे अनुमान लगाना पड़ता है कि आपका क्या मतलब है। वे अनुमान हर प्रांम्प्ट के साथ बदलते हैं, और ऐप भी बदलता है। परिणामस्वरूप स्क्रीन मेल नहीं खातीं, डेटा बीच में ही नाम बदल लेता है, और फीचर्स दिखाई देते हैं, गायब होते हैं, और फिर अलग रूप में फिर से प्रकट होते हैं।
यह असंगतता आमतौर पर कुछ जगहों पर दिखती है:
"Planning Mode" बिल्डिंग से पहले एक सरल विराम है। आप वे फैसले लिखते हैं जो AI वरना खुद ही बना लेगा। उद्देश्य है सुसंगतता: एक सेट विकल्प जो UI, बैकएंड और डेटाबेस सभी फ़ॉलो करें।
मकसद पूर्णता नहीं है। मकसद ऐसा बिल्ड है जिसे आप लगातार पैच किए बिना iterate कर सकें। बाद में अगर आप फैसला बदलते हैं, तो एक छोटा स्पेक अपडेट करें और उसी लॉजिक के साथ फिर से बिल्ड करें।
इसीलिए एक-पृष्ठ ऐप स्पेक टेम्पलेट मायने रखता है। यह लंबा PRD नहीं है और न ही हफ्तों के डायग्राम। यह एक पेज है जो चार चीज़ों का जवाब देता है: उपयोगकर्ता कौन हैं, वे क्या पूरा करने की कोशिश कर रहे हैं, क्या डेटा मौजूद है (सादा भाषा में), और कौन से एज-केसेस या नॉन-लक्ष्य पहले वर्जन को बिगाड़ने से रोकते हैं।
उदाहरण: “एक बुकिंग ऐप” तब काफी स्पष्ट हो जाता है जब आप तय करते हैं कि यह एक सलून मालिक के लिए है या एक मार्केटप्लेस के लिए, और क्या ग्राहक रि-शेड्यूल, कैंसिल, या नो-शो कर सकते हैं।
एक एक-पृष्ठ ऐप स्पेक टेम्पलेट एक छोटा नोट है जो अस्पष्ट आइडिया को स्पष्ट निर्देशों में बदल देता है। आप पूरा प्रोडक्ट डिज़ाइन नहीं कर रहे—आप अपने AI बिल्डर को इतनी संरचना दे रहे हैं कि वे हर बार एक जैसे फैसले लें।
पृष्ठ में चार ब्लॉक होते हैं। यदि आप एक पेज में फिट नहीं कर पा रहे हैं, तो संभवतः आपके पास पहले बिल्ड के लिए बहुत ज्यादा फीचर्स हैं।
एक पेज उपयोगी प्रतिबंध मजबूर करता है। यह आपको प्राथमिक उपयोगकर्ता चुनने, सबसे छोटे सफल फ्लो को परिभाषित करने, और "सब कुछ सपोर्ट करें" जैसे vague वादों से बचने के लिए प्रेरित करता है। ये प्रतिबंध ही वे चीज़ें हैं जो AI-बिल्ट ऐप को स्क्रीन के बीच अपना मन बदलने से रोकते हैं।
"काफी अच्छा" विवरण साधारण, टेस्टेबल स्टेटमेंट जैसा दिखता है। अगर कोई इसे पढ़कर पूछे, "हमें कैसे पता चलेगा कि यह काम कर रहा है?" तो आप सही स्तर पर हैं।
एक त्वरित मानदंड:
भाषा सादी रखें। उन लाइनों को लिखें जिन्हें आप सीधे प्रांम्प्ट में पेस्ट कर सकें, जैसे “A manager can approve or reject a request, and the requester gets a status update.”
20 मिनट का टाइमर सेट करें और उद्देश्य रखें "बिल्ड करने के लिए काफी स्पष्ट," न कि "परफेक्ट"। मकसद है अनुमान हटाना ताकि आपका AI बिल्डर हर बार एक जैसे फैसले करे।
एक वाक्य से शुरू करें जो उत्तर देता हो: यह किसके लिए है, और उन्हें क्या परिणाम मिलेगा?
उदाहरण: “एक मोबाइल ऐप कुत्ते के मालिकों के लिए ताकि वे वॉक और क्लिनिक विज़िट एक जगह ट्रैक कर सकें।”
अगर आप इसे एक वाक्य में नहीं कह सकते, तो संभावना है कि आइडिया दो ऐप्स है।
अगला, 1–3 उपयोगकर्ता प्रकार नाम दें जैसे असली लोग, न कि सार रूप। “Owner,” “Vet,” और “Family member” “User A” से बेहतर हैं। हर एक के लिए एक छोटी लाइन जोड़ें कि वे सबसे ज्यादा किस बारे में परवाह करते हैं।
फिर 3–7 Jobs-to-be-done इस फ़ॉर्मेट में लिखें: “When [situation], I want to [action], so I can [result].” इन्हें टेस्टेबल रखें। “When I finish a walk, I want to log distance and notes, so I can spot patterns” "track health" से साफ़ है।
अब अपनी एंटिटीज़ और मुख्य फ़ील्ड बिना डेटाबेस शब्दों के परिभाषित करें। सोचें "ऐप क्या याद रखता है"। कुत्ते ऐप के लिए: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). अगर कोई फ़ील्ड किसी स्क्रीन या जॉब में उपयोग नहीं होती, तो उसे छोड़ दें।
अंत में दो छोटे ब्लॉक्स भरें: एज-केसेस और नॉन-गोल्स। एज-केसेस कष्टप्रद लेकिन आम होते हैं (“no internet”, “एक ही नाम वाले दो कुत्ते”)। नॉन-गोल्स वे चीज़ें हैं जिन्हें आप अभी नहीं बना रहे (“कोई पेमेंट्स नहीं”, “कोई सोशल फ़ीड नहीं”)।
अंत में हर ब्लॉक को ऐसे प्रांम्प्ट में बदलें जिसे आपका बिल्डर फॉलो कर सके। संरचना बनाए रखें (purpose, users, jobs, entities, edge cases) ताकि सिस्टम स्क्रीन, डेटा, और फ्लोज़ जेनरेट करे जो मेल खाती हों।
अगर आपका स्पेक कहता है “सबके लिए,” तो AI बिल्डर को तय करना होगा कि पहले क्या बनाना है। एक एक-पृष्ठ स्पेक में उपयोगकर्ताओं को इरादे से परिभाषित करें (वे क्या करने आये हैं), न कि जनसांख्यिकी से। इरादा स्क्रीन, डेटा, और परमिशन्स के बारे में स्पष्ट चुनावों की ओर ले जाता है।
2–4 उपयोगकर्ता प्रकार नाम दें, हर एक के साथ एक मुख्य लक्ष्य। अच्छे उदाहरण: “Customer placing an order,” “Team member fulfilling orders,” “Manager reviewing performance.” अस्पष्ट उदाहरण: “18–35,” “busy professionals,” या सिर्फ “admins” (जब तक आप न कहें कि वे क्या admin करते हैं)।
हर बार वही वाक्य संरचना उपयोग करें: “When..., I want to..., so I can...”. यह ऐप को परिणाम-उन्मुख रखता है और AI बिल्डर को स्थिर, टेस्टेबल आवश्यकताएँ देता है।
यहाँ वास्तविक JTBD उदाहरण हैं जिनमें “done” स्पष्ट है:
सफलता के मापदंड मायने रखते हैं क्योंकि वे “अच्छा दिखता है” जैसी अस्पष्टता हटाते हैं। वे बिल्डर को बताते हैं कि UI क्या अनुमति दे और बैकएंड क्या स्टोर करे।
पूरी सुरक्षा योजना लिखने की ज़रूरत नहीं। बस सामान्य भाषा में बताइए कौन क्या कर सकता है।
उदाहरण: “Members अपने आइटम बना और एडिट कर सकते हैं। Managers किसी भी आइटम को एडिट कर और स्टेटस बदल सकते हैं। Owners यूज़र्स और बिलिंग मैनेज कर सकते हैं।”
अगर आप Planning Mode का उपयोग किसी टूल जैसे Koder.ai में कर रहे हैं, तो ये उपयोगकर्ता प्रकार, JTBD लाइनें, और परमिशन्स विश्वसनीय इनपुट बन जाते हैं और AI को अतिरिक्त रोल इनवेंट करने या जिम्मेदारियाँ स्क्रीन पर मिलाने से रोकते हैं।
एंटिटीज़ वे "चीज़ें" हैं जिन्हें आपका ऐप ट्रैक करता है। अगर आप उन्हें स्पष्ट नाम दें तो आपका AI बिल्डर स्क्रीन, फ़ॉर्म और डेटाबेस ऐसे बना सकेगा कि सब मेल खाए। यह वही चीज़ है जो mismatched फ़ील्ड और यादृच्छिक अतिरिक्त फीचर्स रोकती है।
कोर संज्ञाओं की सूची से शुरू करें। अगर ऐप "प्रोजेक्ट मैनेजमेंट" के लिए है तो संज्ञाएँ हो सकती हैं Project, Task, Comment। यदि यह "हेयरकट बुकिंग" है, तो Booking, Service, Customer, Staff हो सकते हैं।
हर एंटिटी के लिए फ़ील्ड रोज़मर्रा की शब्दावली में लिखें, न कि डेटाबेस शब्दों में। सोचिए कि कोई फ़ॉर्म में क्या टाइप करेगा।
यदि आप किसी फ़ील्ड को एक वाक्य में समझा नहीं सकते, तो वह संभवतः पहले वर्जन के लिए बहुत विवरणी है।
एंटिटीज़ कैसे जुड़ती हैं यह सरल वाक्यों में बताइए:
"एक उपयोगकर्ता के कई प्रोजेक्ट हो सकते हैं." "हर टास्क एक प्रोजेक्ट से संबंधित है." "एक कमेंट एक टास्क से संबंधित है और उसकी एक लेखक है."
यह बिल्डर को पर्याप्त संरचना देता है ताकि वह सुसंगत लिस्ट, डिटेल पेज और फ़िल्टर जेनरेट कर सके।
कुछ डेटा नियम जोड़ें जो गड़बड़ी से बचाएँ:
अंत में, क्या आप अभी स्टोर नहीं करेंगे, इसे नाम देकर स्कोप कम करें। उदाहरण: “v1 में कोई फ़ाइल अटैचमेंट नहीं,” या “स्टाफ़ शेड्यूल अभी ट्रैक न करें, केवल बुकिंग।” ये बहिष्करण महत्वपूर्ण हैं क्योंकि वे ऐप को गलत दिशा में बढ़ने से रोकते हैं।
एक-पृष्ठ ऐप स्पेक टेम्पलेट सबसे अच्छा तब काम करता है जब पहला वर्जन छोटे, स्थिर स्क्रीन सेट के साथ हो। यदि आप हर संभव स्क्रीन डिजाइन करने की कोशिश करेंगे तो AI बिल्डर बार-बार अनुमान लगाएगा, और UI हर बिल्ड के साथ भटकेगा।
मुख्य जॉब पूरा कराने वाले न्यूनतम स्क्रीन नाम दें। अधिकांश MVPs के लिए 3–6 स्क्रीन पर्याप्त हैं:
फिर हैप्पी पाथ को एक छोटी कहानी के रूप में लिखें शुरू से अंत तक।
उदाहरण: “यूज़र साइन इन करता है, लिस्ट पर पहुँचता है, खोज करता है, एक आइटम खोलता है, एक फ़ील्ड एडिट करता है, सेव करता है, और लिस्ट पर लौट आता है।”
हर स्क्रीन के लिए प्रमुख क्रियाएं सादे शब्दों में नोट करें। "सब कुछ कर दें" वाली स्क्रीन से बचें। 2–4 मुख्य क्रियाएं चुनें जो सबसे अधिक मायने रखती हैं: create, edit, search, export, archive वगैरह।
यह भी तय करें क्या तेज़ होना चाहिए और क्या "काफी अच्छा" हो सकता है। "तेज़" का मतलब आमतौर पर सूची जल्दी खुलनी चाहिए, खोज तुरंत उत्तर दे, और सेव फील तुरंत करे। "काफी अच्छा" में एक्स्पोर्ट को कुछ सेकंड लगना, बेसिक एनालिटिक्स, या सीमित सेटिंग्स आ सकती हैं।
अंत में हर रोल और उनके एक्सेस को एक लाइन में कैप्चर करें:
यह स्क्रीन को अनुमान्य रखता है, परमिशन आश्चर्यों को रोकता है, और बाद में री-राइट्स घटाता है।
अधिकतर री-राइट्स एक कारण से होते हैं: ऐप खुश पाथ में ठीक चलता है, फिर असली दुनिया आने पर टूट जाता है।
एक अच्छा एक-पृष्ठ स्पेक टेम्पलेट एज-केसेस और नॉन-गोल्स के लिए जगह बनाता है, और वह छोटा सा स्थान घंटों बचा सकता है।
हर JTBD से पूछें: क्या गलत हो सकता है? सादा भाषा में रखें, तकनीकी न बनाएं। आप ambiguity हटाकर बिल्डर को हर बार एक जैसा निर्णय लेने के लिए कह रहे हैं।
सामान्य एज-केसेस जो लिखने योग्य हैं:
फिर प्रतिक्रिया तय करें। स्पष्ट रहें: “एक्शन रोकें और एक स्पष्ट संदेश दिखाएँ,” “ड्राफ्ट के रूप में सेव करने की अनुमति दें,” या “एक बार retry करें, फिर टाइप करने के लिए बटन दिखाएँ।” ये नियम सीधे सुसंगत प्रांम्प्ट में ट्रांसलेट होते हैं।
एक या दो लाइन में प्राइवेसी और सेफ़्टी की अपेक्षाएँ जोड़ें। उदाहरण: “जरूरी न्यूनतम डेटा ही इकट्ठा करें,” “यूज़र अपना अकाउंट और सभी व्यक्तिगत डेटा डिलीट कर सकते हैं,” और “निजी आइटम डिफ़ॉल्ट रूप से छुपे हों।” यदि आपका ऐप यूज़र-जेनरेटेड कंटेंट शामिल करता है, तो रिपोर्ट और स्पैम के साथ क्या करना है, यह भी लिखें, भले ही v1 में सरल हो।
अंत में, नॉन-गोल्स लिखें ताकि स्कोप क्रैप रोका जा सके। बड़े प्रलोभन फीचर्स को चुनें जिन्हें आप अभी नहीं करेंगे।
स्पष्ट नॉन-गोल उदाहरण:
एक त्वरित उदाहरण: यदि जॉब है “इवेंट बनाना,” तो परिभाषित करें कि जब तारीख पहले की हो, टाइटल खाली हो, या वही इवेंट दो बार बनाया जाए तो क्या होता है। वह स्पष्टता अगली रीबिल्ड रोकती है।
सबसे तेज़ तरीका सुसंगत परिणाम पाने का है हर स्पेक ब्लॉक को छोटे, सीधे प्रांम्प्ट्स में बदलना। इसे ऐसे सोचें जैसे आप बिल्डर को कार्ड दे रहे हैं जिन्हें वह क्रम में फॉलो करे, न कि एक बड़े, अस्पष्ट अनुरोध के रूप में।
प्रत्येक ब्लॉक (Users, Jobs, Entities, Screens, Edge cases, Non-goals) को एक निर्देश में बदलें जिसमें स्पष्ट संज्ञाएँ और क्रियाएँ हों। "Make it clean" जैसे मत बताएँ जब तक आप यह न बताएं कि "clean" का क्या मतलब है।
दो-स्टेप चक्र का उपयोग करें: पहले बनाओ, फिर स्पेक के खिलाफ वैलिडेट करो।
एक छोटा definition of done जोड़ें ताकि बिल्डर जानें कब रुकना है। इसे मापनीय रखें:
सिर्फ़ वही constraints जोड़ें जो वाकई मायने रखें: अपेक्षित डिवाइस (mobile-first), अपेक्षित auth (admin-only actions), या अपेक्षित स्टैक (जैसे React frontend, Go backend, PostgreSQL) अगर आपका प्लेटफ़ॉर्म इसे मांगता है।
जब आप एडिट चाहते हैं, तो स्पेक ब्लॉक का संदर्भ दें, न कि कोड का।
उदाहरण: “Update the Entities block: add ‘Subscription’ with fields X and Y. Then regenerate only the affected APIs and screens, and re-run the validation step.”
यह तरीका प्लान को स्थिर रखता है और सुरक्षित रूप से iterate करने देता है।
कल्पना कीजिए आप एक साधारण अपॉइंटमेंट रिमाइंडर ट्रैकर चाहते हैं छोटे सलून के लिए। उद्देश्य पूरा बुकिंग सिस्टम नहीं है। यह हल्का-फुल्का प्लेटफ़ॉर्म है अपॉइंटमेंट स्टोर करने और रिमाइंडर भेजने के लिए।
यहाँ एक भरा हुआ एक-पृष्ठ ऐप स्पेक टेम्पलेट कैसा दिखेगा।
APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.
USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.
JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.
ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.
EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments
अब इसे Planning Mode ऐप बिल्डिंग में पेस्ट करने योग्य प्रांम्प्ट बंडल में बदलें। इसे कड़ाई से रखें ताकि बिल्डर हर बार एक जैसे निर्णय करे।
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.
गंदा आउटपुट आमतौर पर अस्पष्ट स्पेक और फीचर-विक्षेप सूचियों से शुरू होता है। AI बिल्डर वही करेगा जो आप कहते हैं, पर वह आपके मन को नहीं पढ़ सकता। छोटे गैप बड़े फर्क में बदल जाते हैं स्क्रीन और फ्लोज़ में।
ये जाल सबसे ज़्यादा असंगतता तोड़ते हैं, और एक-पृष्ठ स्पेक टेम्पलेट इन्हें कैसे ठीक करता है:
यदि आप Planning Mode को Koder.ai (koder.ai) में उपयोग कर रहे हैं, तो ये बेसिक्स और भी महत्वपूर्ण हो जाते हैं क्योंकि प्लान बार-बार प्रांम्प्ट्स के लिए स्रोत बन जाता है। स्पष्ट जॉब्स, छोटा डेटा मॉडल, स्पष्ट परमिशन्स, और टेस्टेबल सफलता नियम हर नए स्क्रीन को बाकी के साथ संरेखित रखते हैं।
बनाने से पहले अपने एक-पृष्ठ स्पेक टेम्पलेट पर एक त्वरित पास करें। मकसद है वे छेद हटाना जो AI बिल्ड को अनुमान लगाने पर मजबूर करते हैं। वे अनुमान री-राइट्स बन जाते हैं।
तुरंत पूर्णता जांच:
यदि आप एक सरल स्कोरिंग विचार चाहते हैं, तो हर क्षेत्र को 0–2 से रेट करें:
कम से कम 7/10 का लक्ष्य रखें। अगर Entities या Edge cases 2 से नीचे हों तो उन्हें पहले ठीक करें—वे सबसे ज़्यादा churn करते हैं।
पहले बिल्ड के बाद, ऐप की हर JTBD के खिलाफ समीक्षा करें और mismatches मार्क करें। हर बदलाव से पहले स्नैपशॉट लें। अगर नया इटरेशन चीज़ों को बिगाड़ता है, तो रोलबैक करें और एक छोटा एडिट आज़माएँ।
अगर आप Koder.ai (koder.ai) का उपयोग कर रहे हैं, तो Planning Mode को "source of truth" के रूप में रखें और केवल वही regenerate कराएँ जो बदला है, बजाय कि सब कुछ फिर से हाथ से लिखने के।
स्पेक को चलते-चलते अपडेट रखें। जब आप ऐप में कोई बदलाव स्वीकार करते हैं, उसी दिन स्पेक अपडेट करें। जब आप कोई बदलाव अस्वीकार करें, तो कारण लिखें, ताकि अगली बार प्रांम्प्ट स्थिर रहे।
Planning Mode एक छोटा विराम है जहाँ आप स्क्रीन और कोड जनरेट करने से पहले मुख्य निर्णय लिखते हैं। मक़सद है सुसंगतता: वही यूज़र्स, फ्लो और डेटा नाम UI, बैकएंड और डेटाबेस में, ताकि हर बार नई कल्पनाओं के कारण बार-बार रीबिल्ड न करना पड़े।
एक-पेज लक्ष्य वाक्य के साथ शुरू करें, फिर चार ब्लॉक्स भरें:
अगर ये एक पेज में फिट नहीं होते, तो v1 के लिए फीचर्स काट दें।
व्यवहार-आधारित और इरादा-आधारित रखें। कुछ उपयोगकर्ता प्रकार और उनके उद्देश्य बताइए।
उदाहरण: “Owner/Staff जो अपॉइंटमेंट बनाते हैं” “Admin” कहने से बेहतर है। अगर आप किसी रोल का एक लाइन में उद्देश्य नहीं बता सकते, तो वह बहुत अस्पष्ट है।
कठोर पैटर्न का उपयोग करें ताकि हर जॉब परीक्षण योग्य रहे:
फिर एक छोटा ‘definition of done’ जोड़ें (कौन-सा डेटा सेव/अपडेट/दिखना चाहिए)। इससे बिल्डर अनावश्यक कदम या यादृच्छिक स्क्रीन नहीं जोड़ेगा।
वाक्यात्मक भाषा में “ऐप जो याद रखता है” बताएं, और हर एंटिटी के 3–7 फ़ील्ड दें जो स्क्रीन पर वाकई काम आएंगे।
उदाहरण: Appointment: start time, duration, status, service, client. अगर कोई फ़ील्ड किसी जॉब या स्क्रीन में उपयोग नहीं होती, तो v1 में छोड़ दें।
रिश्तों को साधारण वाक्यों में लिखें:
कुछ बेसिक नियम जोड़ें (required, unique, defaults)। यह अक्सर लिस्ट, फॉर्म और फ़िल्टर को सुसंगत रखने के लिए काफी होता है।
पहले वर्जन के लिए 3–6 स्क्रीन काफी हैं जो मुख्य जॉब को एंड-टू-एंड पूरा करें:
हर जॉब के लिए एक “happy path” छोटी स्टोरी लिखें (start → action → save → confirmation) ताकि फ्लो डिफ्ट न करे।
वे एज़-केस लिखें जो खुशरास्ता टूटने पर समस्या बनाएँ। टॉप 5–10 संभावित असाधारण मामलों पर ध्यान दें:
हर एक के लिए अपेक्षित व्यवहार बताइए (एक्शन ब्लॉक करें + स्पष्ट संदेश, ड्राफ्ट की अनुमति, एक बार retry, आदि)।
प्रत्येक ब्लॉक को छोटे, स्पष्ट निर्देशों में बदलें जिन्हें बिल्डर चलाए और सत्यापित करे.
सरल अनुक्रम:
यह एक बड़े, अस्पष्ट प्रांम्प्ट पर भरोसा करने से बेहतर है।
पहले स्पेक अपडेट करें, फिर केवल प्रभावित हिस्सों को regenerate कराइए।
उदाहरण: “Entities ब्लॉक अपडेट करें: ‘Subscription’ जोड़ें फ़ील्ड X और Y के साथ; फिर प्रभावित APIs और स्क्रीन regenerate करें और validation चलाएं।”
स्पेक को source of truth रखें ताकि बदलाव सारभूत रूप से बिखरें नहीं।