चैट-निर्मित ऐप्स के लिए एजेंट भूमिकाएँ: योजनाकार से समीक्षक वर्कफ़्लो

क्यों भरोसेमंदता टूट जाती है जब आप चैट से ऐप बनाते हैं

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

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

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

तीसरी दरार प्रमाण की कमी है। बुनियादी टेस्ट और स्पष्ट स्वीकृति चेक्स के बिना, आप केवल क्लिक करने के बाद ही समस्याएँ ढूँढते हैं। तब "मेरे स्क्रीन पर चलता है" देर रातों, हॉट फिक्स और यादृच्छिक रिग्रेशन में बदल जाता है।

एक सरल समाधान है: पुन: उपयोग करने योग्य पर्सोनास का उपयोग करें: एक Planner जो काम को ठोस बनाए, एक Architect जो आकार तय करे, एक Implementer जो छोटे-छोटे कदमों में बनाए, एक Tester जो इसे तोड़ने की कोशिश करे, और एक Reviewer जो आखिरी 10% पकड़ ले जो 90% दर्द देता है। यह कोई भारी प्रक्रिया नहीं है। यह निर्णयों को लगातार रखने का एक दोहराने योग्य तरीका है।

यह तरीका सोलो फाउंडर, छोटी टीमों और गैर-तकनीकी बिल्डर्स के लिए काम करता है जो Koder.ai जैसे चैट टूल्स का उपयोग करते हैं। आप अभी भी तेज़ी से आगे बढ़ सकते हैं, लेकिन अब आप किस्मत पर निर्भर नहीं रहेंगे।

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

मुख्य विचार: जिम्मेदारियाँ अलग करें, फिर साफ हैंडऑफ़ करें

भरोसेमंदता तब घटती है जब एक चैट एक साथ सब कुछ करने की कोशिश करता है: क्या बनाना है तय करना, डिज़ाइन करना, कोड करना, टेस्ट करना और निर्णय देना। इन कामों को मिलाने से किन मामलों का छोड़ना आसान हो जाता है, बिल्ड के दौरान आवश्यकताएँ बदल जाती हैं, या बग "ठीक" करने के लिए और उलझन जोड़ दी जाती है।

इसे रोकने का एक व्यावहारिक तरीका है भूमिकाओं को संकीर्ण और लगातार रखना। हर भूमिका एक काम की मालिक हो, और उसे उस काम के बाहर "मदद" करने की अनुमति न हो। इससे निर्णय ट्रेस करने योग्य रहते हैं और गलतियों को पकड़ना आसान होता है।

किसी भी फीचर के लिए इस अनुक्रम का उपयोग करें:

• Planner: लक्ष्य, उपयोगकर्ता, स्वीकृति चेक, और क्या बाहर है, परिभाषित करें
• Architect: लक्ष्य का समर्थन करने वाला सबसे सरल डिज़ाइन प्रस्तावित करें
• Implementer: वही बनाएं जो प्लान किया गया है, छोटे चरणों में
• Tester: इसे तोड़ने की कोशिश करें और विफलताओं को साफ़ रिपोर्ट करें
• Reviewer: आखिरी मील के विवरण की जाँच करें (नामकरण, सुरक्षा मूल बातें, UX गैप, जोखिम भरे शॉर्टकट)

साफ़ हैंडऑफ़्स उतने ही मायने रखते हैं जितनी भूमिकाएँ। हर हैंडऑफ़ में यह होना चाहिए कि क्या तय हुआ, क्या अनुमानों पर आधारित था, और "डन" का मतलब क्या है। अगर आप Koder.ai का उपयोग करते हैं, तो हर भूमिका को एक अलग चैट टर्न या स्नैपशॉट की तरह व्यवहार करें ताकि निर्णय गलत निकलने पर आप रोलबैक कर सकें।

गलती से नहीं, उद्देश्य के साथ लूप बैक करें। यदि टेस्ट फेल होते हैं, तो Implementer के पास एक न्यूनतम बग रिपोर्ट लेकर वापस जाएँ। अगर डिज़ाइन किसी नई आवश्यकता का समर्थन नहीं कर पाती, तो Architect के पास वापस जाएँ। अगर आवश्यकता अस्पष्ट है या बार-बार बदल रही है, तो रुककर Planner पर लौटें।

एक ही भूमिकाओं और क्रम को फीचर्स में बनाए रखें। कुछ रन के बाद, आप बेहतर सवाल पहले पूछने की आदत बना लेते हैं, और देर में काम दोहराने से बचते हैं।

पर्सोना 1: Planner (किसी के भी बनाने से पहले काम को स्पष्ट करें)

Planner का काम धुंधली सोच को उस चीज़ में बदलना है जिसे आप बना कर सत्यापित कर सकें। यह "डॉक लिखना" नहीं है। यह पहले से तय करना है कि "डन" का क्या मतलब है—पहली स्क्रीन या API एंडपॉइंट बनने से पहले।

एक अच्छा Planner आउटपुट छोटा और टेस्टेबल रहता है: एक स्पष्ट समस्या कथन, कुछ यूज़र स्टोरीज़, सरल स्वीकृति मानदंड, और किन मामलों में एज़ केस हैं इसकी छोटी सूची। यह यह भी बताता है कि आप अभी क्या नहीं कर रहे, ताकि Implementer गलती से बड़ा फीचर न बना दे।

Planner प्रॉम्प्ट टेम्पलेट (छोटी, प्राथमिकता वाली योजना)

इसे तब उपयोग करें जब आपके पास कोई फीचर आइडिया हो और आप बाकी भूमिकाओं के अनुसरण के लिए एक कड़ा प्लान चाहते हों।

You are the Planner. Turn the feature idea below into a buildable plan.

Feature idea:
<PASTE IDEA>

Context:
- App type:
- Target users:
- Current behavior (if any):
- Constraints (time, data, compliance, devices):

Output (keep it short):
1) Problem statement (1-2 sentences)
2) Assumptions (3-6 bullets)
3) Questions to confirm (max 6, prioritized)
4) User stories (2-5)
5) Acceptance criteria (5-10, testable, specific)
6) Edge cases & failure modes (3-8)
7) Out of scope (3-6 bullets)
8) Small milestone plan (2-4 steps, highest value first)

Planner से Architect हैंडऑफ़ (संरचित और छोटा)

यह संदेश वैसे ही भेजें (भरा हुआ) ताकि बैक-एंड-औफबैक कम हो।

PLANNER HANDOFF
Feature: <name>
Problem: <1-2 sentences>
Users: <who>
Must-haves (AC): <5-10 acceptance criteria>
Key edge cases: <3-6>
Out of scope: <3-6>
Open questions (need Architect input): <1-4>
Constraints: <tech, data, privacy, deadlines>
Success signal: <how we’ll know it worked>

यदि आप केवल एक चीज Planner के रूप में करें, तो acceptance criteria को मापने योग्य बनाएं। उदाहरण: “User can reset password and receives an email within 60 seconds” बेहतर है बनाम “Password reset works.”

पर्सोना 2: Architect (ऐसा आकार चुनें जो ऐप वास्तव में संभाल सके)

Architect एक अच्छे प्लान को एक बिल्डेबल आकार में बदलता है। काम शानदार पैटर्न्स बनाना नहीं है। काम यह चुनना है कि सबसे सरल संरचना क्या है जो तब भी काम करे जब असली यूज़र्स क्लिक करें, डेटा बढ़े, और त्रुटियाँ हों।

यहाँ भरोसेमंदता वास्तविक लगने लगती है: स्पष्ट सीमाएँ, स्पष्ट डेटा, और स्पष्ट failure path।

एक व्यावहारिक Architect आउटपुट आमतौर पर शामिल करता है:

• स्क्रीन (React या Flutter) या API endpoints (Go)
• एक छोटा डेटा मॉडल (PostgreSQL तालिकाएँ और प्रमुख फ़ील्ड)
• एक या दो कोर फ्लो (हैप्पी पाथ और क्या गलत हो सकता है)
• अब के लिए जो गैर-फ़ंक्शनल बेसिक्स मायने रखते हैं (auth, privacy, performance, logging)
• ट्रेडऑफ़्स (क्या आप अभी नहीं बना रहे)

इसे ठोस रखें। “notifications system” कहने के बजाय, कहें “POST /api/alerts, table alerts(user_id, type, status), show unread count in header.” “secure” कहने के बजाय कहें “JWT session, role checks on admin endpoints, protect PII fields.”

प्रॉम्प्ट टेम्पलेट: Architect हैंडऑफ़ (ट्रेडऑफ़ मजबूर करता है)

इसे तब उपयोग करें जब Planner ने Architect को काम सौंपा हो, या जब आप किसी फीचर को रीसेट करना चाहें जो गड़बड़ लग रहा हो।

You are the Architect.
Goal: design the simplest buildable structure for this feature.
Context:
- App type: [web/mobile/both]
- Stack: React UI, Go API, PostgreSQL DB (Flutter screens if mobile)
- Existing constraints: [auth method, existing tables, deadlines]

Input (from Planner):
- User story:
- Acceptance criteria:
- Out of scope:

Deliverables (keep it short and specific):
1) UI map: list screens/components with 1-line purpose each.
2) API map: list endpoints with method, path, request/response fields.
3) Data model: tables + key columns + relationships.
4) Key flows: happy path + 2 failure cases and how UI should respond.
5) Non-functional needs: security, performance, audit/logging (only what matters now).
6) Tradeoffs: 3 decisions you made (and what you avoided) to prevent over-design.

Rules:
- Prefer the smallest option that meets acceptance criteria.
- If something is unclear, ask up to 3 questions, otherwise make a reasonable assumption and write it down.

यदि आप Koder.ai में बिल्ड कर रहे हैं, तो यह तरह का हैंडऑफ़ इम्प्लीमेंटेशन को तेज़ बनाता है क्योंकि Implementer को एक स्पष्ट मानचित्र मिलता है बजाय यह अनुमान लगाने के कि आकार क्या होना चाहिए।

पर्सोना 3: Implementer (छोटे कदमों में बनाएं, स्कोप टाइट रखें)

Implementer स्पष्ट प्लान को कार्यशील कोड में बदलता है, बिना प्लान बदले। यहाँ अधिकतर भरोसेमंदता जीती या हारी जाती है। लक्ष्य सरल है: वही बनाएं जो सहमति हुई थी, ऐसे छोटे कदमों में जो आप वापस भी कर सकें।

हर परिवर्तन को ऐसे मानें कि उसे रोलबैक किया जा सकता है। पतली स्लाइस में काम करें और जब acceptance criteria पूरे हों तो रुक जाएँ। यदि कुछ अस्पष्ट है, तो पूछें। अनुमान लगाने से छोटे फीचर अचानक बड़े री-राइट बन जाते हैं।

एक अच्छा Implementer छोटा एविडेंस छोड़ता है: बिल्ड ऑर्डर, क्या बदला, क्या नहीं बदला (छुपे स्कोप क्रेप से बचने के लिए), और सत्यापित करने का तरीका।

यहाँ एक प्रॉम्प्ट टेम्पलेट है जिसे आप Implementer को हैंडऑफ़ करते समय पेस्ट कर सकते हैं:

You are the Implementer.

Context:
- Feature: <name>
- Current behavior: <what happens today>
- Desired behavior: <what should happen>
- Acceptance criteria: <bullets>
- Constraints: <tech choices, performance, security, no schema change, etc.>

Before writing code:
1) Ask up to 5 questions if anything is unclear.
2) Propose a step-by-step build plan (max 6 steps). Each step must be reversible.
3) For each step, list the exact files/modules you expect to touch.

Then implement:
- Execute steps one by one.
- After each step, summarize what changed and how to verify.
- Do not add extras. If you notice a better idea, stop and ask first.

उदाहरण: यदि Planner ने कहा “Add a password reset email flow,” तो Implementer को लॉगिन स्क्रीन री-डिज़ाइन नहीं करनी चाहिए। ईमेल अनुरोध एंडपॉइंट बनाएं, फिर टोकन हैंडलिंग, फिर UI—हर चरण के बाद संक्षेपित वेरिफिकेशन नोट के साथ। अगर आपका टूल स्नैपशॉट और रोलबैक सपोर्ट करता है (जैसे Koder.ai), तो छोटे कदम बहुत सुरक्षित बन जाते हैं।

पर्सोना 4: Tester (सिद्ध करें कि यह काम करता है, और दिखाएँ कैसे फेल होता है)

Tester का काम फीचर को उपयोगकर्ता से पहले तोड़ना है। वे हैप्पी पाथ पर भरोसा नहीं करते। वे अस्पष्ट अवस्थाओं, गायब वैलिडेशन, और उन एज़ केसों को ढूँढते हैं जो पहले दिन पर दिखते हैं।

एक अच्छा Tester आउटपुट दूसरों के लिए उपयोगी होता है: acceptance criteria से जुड़ा एक टेस्ट मैट्रिक्स, एक छोटा मैन्युअल स्क्रिप्ट, और बग रिपोर्ट्स जिनमें सटीक स्टेप्स (expected vs actual) हों।

क्या टेस्ट करें (UI, API, और डेटा)

कवरेज पर ध्यान दें, मात्रा पर नहीं। जहां विफलताएँ महँगी हैं वहाँ फ़ोकस करें: वैलिडेशन, अनुमतियाँ, और एरर स्टेट्स।

• UI: खाली अवस्थाएँ, त्रुटि संदेश, लोडिंग स्टेट्स, डिसेबल्ड बटन, कीबोर्ड-ओनली फ्लो
• API: गायब फील्ड्स, गलत प्रकार, auth विफलताएँ, रेट/टाइमआउट व्यवहार
• डेटा वैलिडेशन: डुप्लिकेट, अधिकतम लंबाई, अवैध फॉर्मैट, सर्वर-साइड चेक (सिर्फ UI नहीं)
• अनुमतियाँ: सामान्य उपयोगकर्ता बनाम एडमिन क्या कर सकते हैं
• रिग्रेशन: एक या दो "क्या हमने मौजूदा व्यवहार तोड़ा?" जांच

उदाहरण: यदि आपने "Create invoice" जोड़ा है, तो नेगेटिव अमाउंट, 10,000-अक्षरों का नोट, मिसिंग कस्टमर, और डबल-सबमिट क्लिक आज़माएँ।

प्रॉम्प्ट टेम्पलेट: acceptance criteria से टेस्ट मैट्रिक्स जेनरेट करें

इसे Implementer से Tester को हैंडऑफ़ करते समय उपयोग करें। acceptance criteria और कोई भी प्रासंगिक UI/API नोट्स पेस्ट करें।

ROLE: Tester
GOAL: Produce a test matrix tied to acceptance criteria, including negative tests.
CONTEXT:
- Feature: <name>
- Acceptance criteria:
  1) <AC1>
  2) <AC2>
- Surfaces: UI screens: <list>; API endpoints: <list>; DB changes: <notes>
OUTPUT FORMAT:
1) Test matrix table with columns: AC, Test case, Steps, Expected result, Notes
2) Negative tests (at least 5) that try to break validation and permissions
3) Manual test script (10 minutes max) for a non-technical person
4) Bug ticket template entries for any failures you predict (Title, Steps, Expected, Actual, Severity)
CONSTRAINTS:
- Keep steps precise and reproducible.
- Include at least one test for loading/error states.

पर्सोना 5: Reviewer (वो आखिरी 10% पकड़े जो 90% दर्द का कारण बनता है)

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

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

Reviewer क्या देखता है

पास को छोटा और दोहराने योग्य रखें। उन चीज़ों पर फोकस करें जो अक्सर भरोसेमंदता तोड़ देती हैं:

• निरंतरता: नामकरण, पैटर्न, फोल्डर स्ट्रक्चर, और UI व्यवहार एप में मौजूदा चीज़ों से मेल खाता है
• सुरक्षा मूल बातें: इनपुट वैलिडेशन, auth चेक, लॉग्स में संवेदनशील डेटा न होना
• त्रुटियाँ: उपयोगकर्ता-सामना करने वाले संदेश स्पष्ट हों; सर्वर त्रुटियाँ कार्रवाई योग्य हों; कोई साइलेंट फेल्यर न हो
• रखरखाव: छोटी फंक्शन, स्पष्ट इरादा, बिना कारण के duplicated लॉजिक न हो
• भविष्य के बदलाव: क्या भविष्य में संशोधित करना मुश्किल होगा, और उसे कम कैसे करें

संरचित रिव्यू प्रॉम्प्ट (स्वीकृत या परिवर्तन अनुरोधित)

इसे तब उपयोग करें जब Implementer कहे कि फीचर तैयार है:

You are the Reviewer. Do a final review for correctness, clarity, and maintainability.

Context
- Feature goal:
- User flows:
- Key files changed:
- Data model/migrations:

Review checklist
1) Correctness: does it meet the goal and handle edge cases?
2) Security basics: auth, validation, safe logging.
3) Errors: clear messages, consistent status codes.
4) Consistency: naming, patterns, UI text.
5) Maintainability: complexity, duplication, TODOs.

Output format
- Findings (bulleted): include file/function references and severity (high/medium/low)
- Requested changes (must-fix before merge)
- Risk notes (acceptable with reason)
- Decision log updates (what we decided and why)

Finish with exactly one:
APPROVE
CHANGES REQUESTED

यदि Reviewer परिवर्तन अनुरोध करता है, तो वे छोटे और विशिष्ट होने चाहिए। लक्ष्य प्रॉडक्शन में कम आश्चर्य होना है, न कि एक दूसरा विकास चक्र।

हैंडऑफ़ टेम्पलेट्स जो रीवर्क रोकते हैं

अधिकांश रीवर्क इसलिए होता है क्योंकि अगला व्यक्ति एक अस्पष्ट लक्ष्य, गुम इनपुट, या छुपे प्रतिबंध के साथ शुरू करता है। एक सरल हैंडऑफ़ टेम्पलेट हर ट्रांसफर को पूर्वानुमेय बनाता है।

हर बार एक साझा हेडर का उपयोग करें, भले ही कार्य छोटा हो:

• Context + Goal: एक पैराग्राफ में आप क्या बना रहे हैं और क्यों।
• Inputs: स्क्रीन, API नोट्स, डेटा फ़ील्ड्स, सैंपल रिकॉर्ड्स, संबंधित कोड एरियाज़।
• Constraints: टेक चॉइसेज़, डेडलाइन, प्रदर्शन, सुरक्षा, रखनी वाली बिहेवियर।
• Definition of Done: मापने योग्य चेक (क्या पास होना चाहिए, क्या मौजूद होना चाहिए)।
• Assumptions / Open questions / Decisions made: आपने क्या माना, क्या अनजान है, और क्या लॉक किया गया।

यहाँ एक Architect -> Implementer हैंडऑफ़ का उदाहरण:

ROLE HANDOFF: Architect -> Implementer
Context: Add “Invite team member” to the admin area.
Goal: Admin can send an invite email; invited user can accept and set a password.
Inputs: Existing Users table; auth uses JWT; email provider already configured.
Constraints: Go backend + PostgreSQL; React UI; audit log required; no breaking auth changes.
Definition of Done:
- UI: invite modal + success state
- API: POST /invites, POST /invites/accept
- DB: invites table with expiry; audit event on create/accept
- Tests: happy path + expired invite + reused token
Assumptions: Email templates can reuse “reset password” styling.
Open questions: Should invites be single-use per email?
Decisions made: 72h expiry; tokens stored hashed.

अगर आप चाहते हैं कि यह टिके, तो अपने टेम्पलेट्स कहीं स्टोर करें जहाँ हर कोई कॉपी कर सके। अगर आप Koder.ai में बनाते हैं, तो Planning Mode में इन प्रॉम्प्ट्स को रखें और इम्प्लीमेंटेशन से पहले स्नैपशॉट लें ताकि अगर स्कोप बदलना पड़े तो रोलबैक आसान हो।

हर फीचर के लिए आप अनुसरण कर सकने वाला स्टेप-बाय-स्टेप वर्कफ़्लो

जब आप प्रत्येक फीचर को एक मिनी रिलीज की तरह ट्रीट करते हैं, तो भरोसेमंदता बढ़ती है—साफ हैंडऑफ़ के साथ। एक बार में एक यूज़र स्टोरी से शुरू करें, ना कि कई विचारों के ढेर से। इसे स्पष्ट भाषा में लिखें, फिर ऐसे acceptance criteria जोड़ें जिन्हें कोई अनुमान लगाए बिना जांच सके।

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

एक व्यावहारिक फ्लो इस तरह दिखता है:

1. Planner: यूज़र स्टोरी, एज़ केस, और acceptance criteria की पुष्टि करें (सफलता, विफलता, और “अगर यूज़र X करे तो क्या”)।
2. Architect: सबसे छोटा डेटा मॉडल और API सतह प्रस्तावित करें (तालिकाएँ/फ़ील्ड्स, एंडपॉइंट्स, auth नियम), और एक छोटा नोट कि आप क्या नहीं बना रहे।
3. Implementer: एक पतली स्लाइस end-to-end बनाएं (UI से API तक DB) जो acceptance criteria को पूरा करे, भले UI सादा ही क्यों न हो।
4. Tester: एक दोहराने योग्य टेस्ट स्क्रिप्ट चलाएं, विफलताओं को चरण-दर-चरण लॉग करें, और किसी भी अस्पष्ट व्यवहार को नोट करें।
5. Reviewer: सुरक्षा मूल बातें और उत्पाद पॉलिश के लिए अंतिम जाँच करें, फिर निर्णय रिकॉर्ड करें।

हर चरण का आउटपुट छोटा और स्पष्ट रखें। अक्सर एक हैंडऑफ़ मैसेज प्रति भूमिका काफी होता है: इनपुट, लिए गए निर्णय, और आपको आगे क्या चाहिए।

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

एक वास्तविक उदाहरण: आइडिया से रिव्यूड रिलीज तक एक फीचर

Feature: एक सरल CRM स्क्रीन जहाँ उपयोगकर्ता कॉन्टैक्ट जोड़ सकें, टैग अप्लाई कर सकें (जैसे “Lead” या “Vendor”), और नाम या टैग से खोज कर सकें। पाबंदी: आपके पास 90 मिनट हैं, और आपको मौजूदा contacts तालिका का ही पुन: उपयोग करना है (ब्रेकिंग माइग्रेशंस नहीं)। मोबाइल के लिए एक single “Add Contact” स्क्रीन चाहिए जो एक पेज में फिट हो।

यहाँ पर्सोना चेन का उपयोग करते समय हैंडऑफ़ कैसा दिखता है। हर भूमिका अगली व्यक्ति के भरोसेमंद छोटे आर्टिफैक्ट बनाती है।

Planner output (definition + acceptance)
- Goal: Add contacts with tags and fast search.
- Must: Create, edit, list contacts; add/remove tags.
- Search: matches name OR any tag; results update in under 300ms.
- Constraint: keep existing contacts table; tags can be new table.
- Done when: 5 test cases pass; mobile screen has no scroll on common devices.

Architect output (shape + data)
- Tables: contacts (existing), tags (id, name), contact_tags (contact_id, tag_id).
- API: POST /contacts, PATCH /contacts/:id, GET /contacts?query=.
- Search: SQL ILIKE on contact name + join on tags.
- UI: Contact list with search bar; contact form with tag picker.
- Risk: duplicate tags (“lead” vs “Lead”) - enforce lowercase unique.

Implementer output (small steps)
- Step 1: Add tags + join table migrations.
- Step 2: Update backend handlers and query.
- Step 3: Build React UI list + form; wire to API.
- Step 4: Add basic validation (name required, tag length).
- Step 5: Add loading/error states; keep UI responsive.

Tester output (proof + failure)
- Case: search “lea” returns contacts tagged “lead”. FAIL: returns none.
- Case: adding tag “Lead” then “lead” should not create two tags. PASS.
- Case: empty name rejected. PASS.
- Bug note: backend search only checks contact name, not tags.

Loop-back (Planner update)
- Update acceptance: search must match tags via join; include a test for it.
- Add edge case: searching by tag should return even if name doesn’t match.

Reviewer output (last 10%)
- Check: query uses indexes; add index on tags.name and contact_tags.tag_id.
- Check: error messages are clear; avoid raw SQL errors.
- Check: mobile form spacing and tap targets.
- Confirm: snapshots/rollback point created before release.

वह एकल फेल्ड टेस्ट साफ़ लूप-बैक को मजबूर करता है: प्लान और भी सटीक बनता है, Implementer एक क्वेरी बदलता है, और Reviewer प्रदर्शन और पॉलिश की जाँच करके रिलीज़ से पहले पुष्टि करता है।

सामान्य जाल (और सरल समाधान)

चैट-निर्मित सॉफ़्टवेयर पर भरोसा खोने का सबसे तेज़ तरीका है कि हर कोई सब कुछ कर दे। स्पष्ट भूमिकाएँ और साफ़ हैंडऑफ़ काम को पूर्वानुमेय रखते हैं, भले ही आप तेज़ी से आगे बढ़ते हों।

• पर्सोनास एक दूसरे में घुलमिल जाते हैं (आवश्यकताएँ स्थिर होने से पहले बिल्ड करना)। सुधार: Planner आउटपुट को लॉक करें इससे पहले कि कोई कोड बदलाव करे। टेम्पलेट ट्वीक: “Implementer: Planner के Scope, Assumptions, और Acceptance Criteria मौजूद होने तक कोड न लिखें। यदि मिसिंग है, तो अधिकतम 3 प्रश्न पूछें।”
• डन की परिभाषा नहीं है, इसलिए काम कभी खत्म नहीं होता। सुधार: हर हैंडऑफ़ में एक Done लाइन होनी चाहिए। उदाहरण: “Done means: acceptance criteria met, no new TODOs, and changes documented in 5 bullets.”
• Tester केवल हैप्पी पाथ चेक करता है। सुधार: हर बार एक invalid-input केस और एक एज़ केस आवश्यक करें। टेम्पलेट ट्वीक: “Tester: provide (1) happy path, (2) one invalid input case, (3) one edge case. If you can’t run it, describe exact steps and expected output.”
• Reviewer स्टाइल पर बहस करता है बजाय प्रोडक्ट रिस्क पर। सुधार: Reviewer को पहले रिस्क पर फोकस करना अनिवार्य करें। टेम्पलेट ट्वीक: “Reviewer: list the top 3 risks (security, data loss, broken UX, performance). Mention style only if it blocks readability or causes bugs.”
• हैंडऑफ़्स संदर्भ चूक जाते हैं, इसलिए अगला व्यक्ति अनुमान लगाता है। सुधार: हर बार एक छोटा Handoff Block आवश्यक करें: “Goal, What changed, How to verify, Known gaps.” इसे 8 लाइनों से कम रखें।

एक छोटी आदत मदद करती है: जब Implementer खत्म करे, तो acceptance criteria फिर से पेस्ट करें और उन्हें एक-एक करके टिक करें।

भरोसेमंद चैट-निर्मित रिलीज़्स के लिए त्वरित चेकलिस्ट

इसे बिल्ड करने से पहले, मर्ज से पहले, और शिप करने के तुरंत बाद चलाएँ।

प्री-बिल्ड (किसी ने भी कोड लिखने से पहले)

• एक वाक्य में लक्ष्य लिखें और 2-3 acceptance चेक्स सूचीबद्ध करें ("डन" कैसा दिखेगा)।
• क्या आउट ऑफ़ स्कोप है नामित करें (ताकि Implementer अनुमान न लगाए)।
• सटीक डेटा फ़ील्ड्स और नियम सूचीबद्ध करें (टाइप्स, required/optional, defaults)।
• मुख्य एरर केसेस नोट करें (खराब इनपुट, अनुमति नहीं, खाली अवस्थाएँ, टाइमआउट)।
• तय करें कि आप इसे जल्दी कैसे वेरिफाई करेंगे (एक स्क्रीन, एक API रिस्पॉन्स, एक लॉग लाइन)।

एक छोटा उदाहरण: “Add invite-by-email.” फील्ड्स शामिल करें (email, role), क्या होता है अगर ईमेल अवैध है, और क्या आप फिर से-invite.allow करते हैं या नहीं।

प्री-मर्ज और पोस्ट-रिलीज (परिवर्तन का भय कम करें)

• प्री-मर्ज: पुष्टि करें कि टेस्ट चल चुके हैं (या कम से कम एक छोटा मैन्युअल स्क्रिप्ट) और क्या चेक किया गया रिकॉर्ड करें।
• प्री-मर्ज: 2-3 एज़ मामलों को स्पष्ट रूप से कवर करें, "काम करना चाहिए" न कहें।
• प्री-मर्ज: रोलबैक प्लान नोट करें और कौन सा बदलाव इसे ट्रिगर करेगा।
• पोस्ट-रिलीज: पहले घंटे/दिन के लिए 1-2 सिग्नल (एरर, स्लो पेज, फेल्ड जॉब्स) पर नजर रखें।
• पोस्ट-रिलीज: उपयोगकर्ता फीडबैक कैद करें और ज्ञात सीमाओं को लिखें ताकि सपोर्ट अनुमान न लगाए।

यदि आपका प्लेटफ़ॉर्म सपोर्ट करता है (Koder.ai करता है), तो जोखिमपूर्ण एडिट्स से पहले स्नैपशॉट लें। रोलबैक का ज्ञान छोटे, सुरक्षित बदलाव शिप करना आसान बनाता है।

अगला कदम: इसे अपनी डिफ़ॉल्ट वर्कफ़्लो बनाएं

एक छोटा फीचर चुनें और पूरी पर्सोना चेन एक बार चलाएँ। कुछ असली परन्तु सीमित चुनें, जैसे “add password reset,” “create an admin-only page,” या “export invoices to CSV.” मकसद यह देखना है कि क्या बदलता है जब आप Planner से Reviewer तक के साफ़ हैंडऑफ़ को अनिवार्य करते हैं।

यदि आप Koder.ai (koder.ai) का उपयोग कर रहे हैं, तो Planning Mode एक व्यावहारिक जगह है स्कोप और acceptance चेक लॉक करने की, फिर स्नैपशॉट और रोलबैक तब एक सुरक्षित एस्केप है जब कोई निर्णय गलत निकलता है—बिना पूरे प्रोजेक्ट को बहस में बदलने के।

वर्कफ़्लो को दोहराने योग्य बनाने के लिए, अपनी पर्सोना प्रॉम्प्ट्स को टेम्पलेट्स के रूप में सेव करें जिन्हें टीम उपयोग कर सके। उन्हें छोटा रखें, आउटपुट फॉर्मैट्स consistent रखें, और आप हर फीचर के लिए कम बार वही संदर्भ दोहराएंगे।