Agent के लिए task brief लिखें

ऐसा बदलाव बताएँ जिसका reviewer आकलन कर सके

“Customer export जोड़ें” कई निर्णय खुले छोड़ता है। Records कौन export कर सकता है? कौन-से records और fields शामिल हैं? Request विफल होने पर क्या होता है? Agent इन खाली जगहों को उचित लगने वाले विकल्पों से भर सकता है। वे विकल्प business के लिए फिर भी गलत हो सकते हैं।

उपयोगकर्ता और समस्या से शुरू करें। फिर जरूरी व्यवहार बताएँ। ऐसे प्रमाण शामिल करें जो दिखाएँ कि परिणाम स्वीकार्य है या नहीं।

Brief को हर आंतरिक design choice तय किए बिना अनिश्चितता घटानी चाहिए। जरूरी डेटा सीमा बताएँ। जब तक बदलने का कारण न हो, implementation को repository के मौजूदा patterns इस्तेमाल करने दें।

ठोस उदाहरण इस्तेमाल करें

यह brief एक काल्पनिक support application के लिए है। यह सीखने का उदाहरण है, पूरी production specification नहीं।

परिणाम: Support manager ग्राहकों की सूची download कर सकता है।
उपयोगकर्ता: वर्तमान organization का manager।
डेटा: केवल उस organization के सक्रिय ग्राहक।
Fields: Customer ID, कंपनी का नाम और account status।
Format: Header row वाला UTF-8 CSV।
अस्वीकृत request: मौजूदा authorization error लौटाएँ।
खाली परिणाम: केवल header वाला मान्य CSV लौटाएँ।
दायरा: मौजूदा export route और audit pattern इस्तेमाल करें।
बाहर रखा गया: कोई नई role, dependency या deployment नहीं।
प्रमाण: स्वीकार्य, अस्वीकृत, खाली और दूसरी organization के अनुरोधों के tests।

यह brief उपयोगी व्यवहार और सीमाएँ बताता है। इससे आगे के प्रश्न भी सामने आते हैं। क्या system को export का आकार सीमित करना चाहिए? क्या किसी field में spreadsheet formula हो सकता है? Audit record कौन access कर सकता है? असर वाले प्रश्न implementation से पहले हल करें। उदाहरण को हर स्थिति में लागू checklist न मानें।

Requirements और धारणाएँ अलग रखें

Requirement वह व्यवहार बताती है जिसे बदलाव को पूरा करना है। धारणा ऐसा तथ्य है जिसे आपने अभी जाँचा नहीं है। दोनों अलग रखें।

उदाहरण के लिए, “मौजूदा audit pattern इस्तेमाल करें” मानता है कि उपयुक्त pattern मौजूद है। Agent से उसे ढूँढ़ने को कहें। Repository में ऐसा pattern न हो, तो नया audit system बनाने से पहले agent को इस कमी की रिपोर्ट देनी चाहिए।

कोई सीमा परिणाम से टकरा भी सकती है। मौजूदा route design के अनुसार हर organization लौटा सकता है। Agent को टकराव दिखाना चाहिए और सीमित सुधार सुझाना चाहिए। उसे चुपचाप डेटा सीमा नहीं हटानी चाहिए या काम को architecture दोबारा लिखने तक नहीं बढ़ाना चाहिए।

काम पूरा होने में प्रमाण शामिल करें

Delivery का सारांश माँगें, जिसमें अंतिम व्यवहार, बदला हुआ दायरा और की गई checks बताई गई हों। जहाँ जरूरी हो, सटीक commands और परिणाम माँगें। Pass हुई check और न चल सकी check का अंतर स्पष्ट रखें।

Pull request में बदलाव का कारण बना रहना चाहिए। बाद में रखरखाव करने वाला व्यक्ति मूल बातचीत के बिना code देख सकता है। पर्याप्त context दें कि export कुछ fields क्यों छोड़ता है और access कैसे लागू होता है।

Google की change-description guidance इस record के लिए उपयोगी संदर्भ है। विवरण को बदलाव और उसका उद्देश्य समझाना चाहिए। Review के बाद हुए बदलावों के अनुसार record को अंतिम implementation से मेल खाता रखें।

Brief को काम के अनुपात में रखें

छोटे text correction के लिए छोटा brief काफी हो सकता है। Data export को अधिक विवरण चाहिए, क्योंकि उसकी विफलता जानकारी उजागर कर सकती है। नए payment workflow को और अधिक विश्लेषण और review चाहिए।

Brief की गुणवत्ता उसकी लंबाई से न मापें। पूछें कि क्या सक्षम reviewer सही और गलत परिणाम में अंतर कर सकेगा। अगर दो उचित implementations किसी असर वाले व्यवहार पर अलग निर्णय देंगे, तो पहले वह व्यवहार स्पष्ट करें।