5 एजेंट स्किल डिज़ाइन पैटर्न जो हर ADK डेवलपर को जानने चाहिए

जब बात 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 की आती है, तो डेवलपर्स आमतौर पर फ़ॉर्मेट पर ध्यान केंद्रित करते हैं—YAML को सही करना, डायरेक्ट्री को स्ट्रक्चर करना, और स्पेक का पालन करना। लेकिन जब 30 से अधिक एजेंट टूल्स (जैसे Claude Code, Gemini CLI, और Cursor) एक ही लेआउट पर मानकीकरण कर रहे हैं, तो फ़ॉर्मेटिंग की समस्या लगभग पुरानी हो चुकी है।

अब चुनौती कंटेंट डिज़ाइन की है। स्पेसिफिकेशन बताता है कि स्किल को कैसे पैकेज किया जाए, लेकिन इसके अंदर लॉजिक को कैसे स्ट्रक्चर किया जाए, इस पर कोई मार्गदर्शन नहीं देता। उदाहरण के लिए, एक स्किल जो FastAPI कन्वेंशन को लपेटती है, वह चार-चरणीय डॉक्यूमेंटेशन पाइपलाइन से पूरी तरह अलग तरीके से काम करती है, भले ही उनकी 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 फ़ाइलें बाहर से एक जैसी दिखें।

पूरे इकोसिस्टम में स्किल्स के निर्माण का अध्ययन करके—Anthropic के रिपॉजिटरी से लेकर Vercel और Google के आंतरिक दिशानिर्देशों तक—पाँच आवर्ती डिज़ाइन पैटर्न सामने आते हैं जो डेवलपर्स को एजेंट बनाने में मदद कर सकते हैं।

[@Saboo_Shubham_](https://x.com/@Saboo_Shubham_) और [@lavinigam](https://x.com/@lavinigam) द्वारा

यह लेख प्रत्येक पैटर्न को कार्यशील ADK कोड के साथ कवर करता है:

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

पैटर्न 1: टूल रैपर

टूल रैपर आपके एजेंट को किसी विशिष्ट लाइब्रेरी के लिए ऑन-डिमांड कॉन्टेक्स्ट देता है। API कन्वेंशन को सीधे अपने सिस्टम प्रॉम्प्ट में हार्डकोड करने के बजाय, आप उन्हें एक स्किल में पैकेज करते हैं। आपका एजेंट उस कॉन्टेक्स्ट को तभी लोड करता है जब वह वास्तव में उस तकनीक के साथ काम करता है।

यह लागू करने के लिए सबसे सरल पैटर्न है। 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 फ़ाइल उपयोगकर्ता के प्रॉम्प्ट में विशिष्ट लाइब्रेरी कीवर्ड को सुनती है, 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ डायरेक्ट्री से आपके आंतरिक दस्तावेज़ीकरण को गतिशील रूप से लोड करती है, और उन नियमों को पूर्ण सत्य के रूप में लागू करती है। यह वही तंत्र है जिसका उपयोग आप अपनी टीम के आंतरिक कोडिंग दिशानिर्देशों या विशिष्ट फ्रेमवर्क के सर्वोत्तम अभ्यासों को सीधे अपने डेवलपर्स के वर्कफ़्लो में वितरित करने के लिए करते हैं।

यहाँ एक टूल रैपर का उदाहरण है जो एक एजेंट को FastAPI कोड लिखना सिखाता है। ध्यान दें कि निर्देश स्पष्ट रूप से एजेंट को बताते हैं कि वह 𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍 फ़ाइल को केवल तभी लोड करे जब वह कोड की समीक्षा या लेखन शुरू करे:

1# skills/api-expert/SKILL.md
2---
3name: api-expert
4description: FastAPI विकास के लिए सर्वोत्तम अभ्यास और परंपराएँ। FastAPI एप्लिकेशन, REST API या Pydantic मॉडल बनाते, समीक्षा करते या डीबग करते समय उपयोग करें।
5metadata:
6  pattern: tool-wrapper
7  domain: fastapi
8---
9
10आप FastAPI विकास में विशेषज्ञ हैं। इन परंपराओं को उपयोगकर्ता के कोड या प्रश्न पर लागू करें।
11
12## मुख्य परंपराएँ
13
14FastAPI सर्वोत्तम अभ्यासों की पूरी सूची के लिए 'references/conventions.md' लोड करें।
15
16## कोड की समीक्षा करते समय
171. परंपराओं का संदर्भ लोड करें
182. प्रत्येक परंपरा के विरुद्ध उपयोगकर्ता के कोड की जाँच करें
193. प्रत्येक उल्लंघन के लिए, विशिष्ट नियम का हवाला दें और समाधान सुझाएँ
20
21## कोड लिखते समय
221. परंपराओं का संदर्भ लोड करें
232. प्रत्येक परंपरा का ठीक से पालन करें
243. सभी फ़ंक्शन हस्ताक्षरों में प्रकार एनोटेशन जोड़ें
254. डिपेंडेंसी इंजेक्शन के लिए Annotated शैली का उपयोग करें

पैटर्न 2: जनरेटर

जहाँ टूल रैपर ज्ञान को लागू करता है, वहीं जनरेटर सुसंगत आउटपुट सुनिश्चित करता है। यदि आपको एजेंट द्वारा हर बार अलग-अलग दस्तावेज़ संरचनाएँ उत्पन्न करने में समस्या होती है, तो जनरेटर एक रिक्त स्थान भरने की प्रक्रिया का आयोजन करके इसका समाधान करता है।

यह दो वैकल्पिक डायरेक्ट्री का उपयोग करता है: 𝚊𝚜𝚜𝚎𝚝𝚜/ आपके आउटपुट टेम्पलेट को रखता है, और 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ आपकी शैली मार्गदर्शिका को रखता है। निर्देश एक प्रोजेक्ट मैनेजर के रूप में कार्य करते हैं। वे एजेंट को बताते हैं कि टेम्पलेट लोड करें, शैली मार्गदर्शिका पढ़ें, उपयोगकर्ता से लुप्त चर के बारे में पूछें, और दस्तावेज़ को भरें। यह पूर्वानुमान योग्य API दस्तावेज़ीकरण उत्पन्न करने, कमिट संदेशों को मानकीकृत करने, या प्रोजेक्ट आर्किटेक्चर तैयार करने के लिए व्यावहारिक है।

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

1# skills/report-generator/SKILL.md
2---
3name: report-generator
4description: Markdown में संरचित तकनीकी रिपोर्ट उत्पन्न करता है। तब उपयोग करें जब उपयोगकर्ता रिपोर्ट, सारांश या विश्लेषण दस्तावेज़ लिखने, बनाने या तैयार करने के लिए कहे।
5metadata:
6  pattern: generator
7  output-format: markdown
8---
9
10आप एक तकनीकी रिपोर्ट जनरेटर हैं। इन चरणों का ठीक से पालन करें:
11
12चरण 1: स्वर और फ़ॉर्मेटिंग नियमों के लिए 'references/style-guide.md' लोड करें।
13
14चरण 2: आवश्यक आउटपुट संरचना के लिए 'assets/report-template.md' लोड करें।
15
16चरण 3: टेम्पलेट को भरने के लिए आवश्यक किसी भी लुप्त जानकारी के लिए उपयोगकर्ता से पूछें:
17- विषय या विषय-वस्तु
18- मुख्य निष्कर्ष या डेटा बिंदु
19- लक्षित दर्शक (तकनीकी, कार्यकारी, सामान्य)
20
21चरण 4: शैली मार्गदर्शिका नियमों का पालन करते हुए टेम्पलेट भरें। आउटपुट में टेम्पलेट का प्रत्येक अनुभाग मौजूद होना चाहिए।
22
23चरण 5: पूर्ण रिपोर्ट को एक Markdown दस्तावेज़ के रूप में लौटाएँ।

पैटर्न 3: समीक्षक

समीक्षक पैटर्न यह अलग करता है कि क्या जाँचना है और इसे कैसे जाँचना है। हर कोड स्मेल का विवरण देने वाला एक लंबा सिस्टम प्रॉम्प्ट लिखने के बजाय, आप 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/𝚛𝚎𝚟𝚒𝚎𝚠-𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍 फ़ाइल के अंदर एक मॉड्यूलर मानदंड संग्रहीत करते हैं।

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

निम्नलिखित कोड समीक्षक स्किल इस पृथक्करण को प्रदर्शित करता है। निर्देश स्थिर रहते हैं, लेकिन एजेंट गतिशील रूप से एक बाहरी चेकलिस्ट से विशिष्ट समीक्षा मानदंड लोड करता है और एक संरचित, गंभीरता-आधारित आउटपुट को बाध्य करता है:

1# skills/code-reviewer/SKILL.md
2---
3name: code-reviewer
4description: गुणवत्ता, शैली और सामान्य बग के लिए Python कोड की समीक्षा करता है। तब उपयोग करें जब उपयोगकर्ता समीक्षा के लिए कोड सबमिट करता है, अपने कोड पर प्रतिक्रिया माँगता है, या कोड ऑडिट चाहता है।
5metadata:
6  pattern: reviewer
7  severity-levels: error,warning,info
8---
9
10आप एक Python कोड समीक्षक हैं। इस समीक्षा प्रोटोकॉल का ठीक से पालन करें:
11
12चरण 1: पूर्ण समीक्षा मानदंड के लिए 'references/review-checklist.md' लोड करें।
13
14चरण 2: उपयोगकर्ता के कोड को ध्यान से पढ़ें। आलोचना करने से पहले उसके उद्देश्य को समझें।
15
16चरण 3: चेकलिस्ट के प्रत्येक नियम को कोड पर लागू करें। प्रत्येक पाए गए उल्लंघन के लिए:
17- लाइन नंबर (या लगभग स्थान) नोट करें
18- गंभीरता का वर्गीकरण करें: error (ठीक करना ही होगा), warning (ठीक करना चाहिए), info (विचार करें)
19- समझाएँ कि यह समस्या क्यों है, न कि केवल क्या गलत है
20- सही कोड के साथ एक विशिष्ट सुधार सुझाएँ
21
22चरण 4: इन अनुभागों के साथ एक संरचित समीक्षा तैयार करें:
23- **सारांश**: कोड क्या करता है, समग्र गुणवत्ता मूल्यांकन
24- **निष्कर्ष**: गंभीरता के अनुसार समूहित (पहले errors, फिर warnings, फिर info)
25- **स्कोर**: संक्षिप्त तर्क के साथ 1-10 का रेटिंग दें
26- **शीर्ष 3 अनुशंसाएँ**: सबसे प्रभावशाली सुधार

पैटर्न 4: इन्वर्ज़न

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

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

इसे क्रियान्वित देखने के लिए, इस प्रोजेक्ट प्लानर स्किल को देखें। यहाँ महत्वपूर्ण तत्व सख्त चरणबद्धता और स्पष्ट गेटकीपिंग प्रॉम्प्ट है जो एजेंट को तब तक अंतिम योजना को संश्लेषित करने से रोकता है जब तक सभी उपयोगकर्ता उत्तर एकत्र नहीं हो जाते:

1# skills/project-planner/SKILL.md
2---
3name: project-planner
4description: योजना तैयार करने से पहले संरचित प्रश्नों के माध्यम से आवश्यकताएँ एकत्र करके एक नए सॉफ्टवेयर प्रोजेक्ट की योजना बनाता है। तब उपयोग करें जब उपयोगकर्ता कहे "मैं बनाना चाहता हूँ", "योजना बनाने में मदद करें", "एक सिस्टम डिज़ाइन करें", या "एक नया प्रोजेक्ट शुरू करें"।
5metadata:
6  pattern: inversion
7  interaction: multi-turn
8---
9
10आप एक संरचित आवश्यकता साक्षात्कार आयोजित कर रहे हैं। जब तक सभी चरण पूरे न हों, निर्माण या डिज़ाइन शुरू न करें।
11
12## चरण 1 — समस्या खोज (एक बार में एक प्रश्न पूछें, प्रत्येक उत्तर की प्रतीक्षा करें)
13
14इन प्रश्नों को क्रम से पूछें। किसी को छोड़ें नहीं।
15
16- Q1: "यह प्रोजेक्ट अपने उपयोगकर्ताओं के लिए कौन सी समस्या हल करता है?"
17- Q2: "प्राथमिक उपयोगकर्ता कौन हैं? उनका तकनीकी स्तर क्या है?"
18- Q3: "अपेक्षित पैमाना क्या है? (प्रति दिन उपयोगकर्ता, डेटा मात्रा, अनुरोध दर)"
19
20## चरण 2 — तकनीकी बाधाएँ (केवल चरण 1 के पूरी तरह उत्तर देने के बाद)
21
22- Q4: "आप किस परिनियोजन वातावरण का उपयोग करेंगे?"
23- Q5: "क्या आपकी कोई तकनीकी स्टैक आवश्यकता या प्राथमिकता है?"
24- Q6: "गैर-परक्राम्य आवश्यकताएँ क्या हैं? (विलंबता, अपटाइम, अनुपालन, बजट)"
25
26## चरण 3 — संश्लेषण (केवल सभी प्रश्नों के उत्तर देने के बाद)
27
281. आउटपुट फ़ॉर्मेट के लिए 'assets/plan-template.md' लोड करें
292. एकत्रित आवश्यकताओं का उपयोग करके टेम्पलेट के प्रत्येक अनुभाग को भरें
303. पूर्ण योजना उपयोगकर्ता को प्रस्तुत करें
314. पूछें: "क्या यह योजना आपकी आवश्यकताओं को सटीक रूप से दर्शाती है? आप क्या बदलना चाहेंगे?"
325. जब तक उपयोगकर्ता पुष्टि न करे, प्रतिक्रिया पर पुनरावृति करें

पैटर्न 5: पाइपलाइन

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

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

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

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

1# skills/doc-pipeline/SKILL.md
2---
3name: doc-pipeline
4description: बहु-चरणीय पाइपलाइन के माध्यम से Python स्रोत कोड से API दस्तावेज़ीकरण उत्पन्न करता है। तब उपयोग करें जब उपयोगकर्ता किसी मॉड्यूल का दस्तावेज़ीकरण करने, API डॉक्स उत्पन्न करने या कोड से दस्तावेज़ीकरण बनाने के लिए कहे।
5metadata:
6  pattern: pipeline
7  steps: "4"
8---
9
10आप एक दस्तावेज़ीकरण जनरेशन पाइपलाइन चला रहे हैं। प्रत्येक चरण को क्रम से निष्पादित करें। यदि कोई चरण विफल होता है तो उसे छोड़ें नहीं या आगे न बढ़ें।
11
12## चरण 1 — पार्स और सूची
13सभी सार्वजनिक क्लास, फ़ंक्शन और स्थिरांक निकालने के लिए उपयोगकर्ता के Python कोड का विश्लेषण करें। सूची को एक चेकलिस्ट के रूप में प्रस्तुत करें। पूछें: "क्या यह पूर्ण सार्वजनिक API है जिसे आप दस्तावेज़ित करना चाहते हैं?"
14
15## चरण 2 — डॉकस्ट्रिंग उत्पन्न करें
16प्रत्येक फ़ंक्शन के लिए जिसमें डॉकस्ट्रिंग नहीं है:
17- आवश्यक फ़ॉर्मेट के लिए 'references/docstring-style.md' लोड करें
18- शैली मार्गदर्शिका के अनुसार ठीक एक डॉकस्ट्रिंग उत्पन्न करें
19- उपयोगकर्ता की स्वीकृति के लिए प्रत्येक उत्पन्न डॉकस्ट्रिंग प्रस्तुत करें
20उपयोगकर्ता के पुष्टि करने तक चरण 3 पर न जाएँ।
21
22## चरण 3 — दस्तावेज़ीकरण तैयार करें
23आउटपुट संरचना के लिए 'assets/api-doc-template.md' लोड करें। सभी क्लास, फ़ंक्शन और डॉकस्ट्रिंग को एक API संदर्भ दस्तावेज़ में संकलित करें।
24
25## चरण 4 — गुणवत्ता जाँच
26'references/quality-checklist.md' के विरुद्ध समीक्षा करें:
27- हर सार्वजनिक प्रतीक दस्तावेज़ित है
28- हर पैरामीटर का एक प्रकार और विवरण है
29- प्रति फ़ंक्शन कम से कम एक उपयोग उदाहरण
30परिणाम रिपोर्ट करें। अंतिम दस्तावेज़ प्रस्तुत करने से पहले मुद्दों को ठीक करें।

सही एजेंट स्किल पैटर्न चुनना

प्रत्येक पैटर्न एक अलग प्रश्न का उत्तर देता है। अपने उपयोग के मामले के लिए सही खोजने के लिए इस निर्णय वृक्ष का उपयोग करें:

और अंत में, पैटर्न संयोजित होते हैं

ये पैटर्न परस्पर अनन्य नहीं हैं। ये संयोजित होते हैं।

एक पाइपलाइन स्किल में अपने स्वयं के काम की दोबारा जाँच करने के लिए अंत में एक समीक्षक चरण शामिल हो सकता है। एक जनरेटर अपना टेम्पलेट भरने से पहले आवश्यक चर एकत्र करने के लिए शुरुआत में इन्वर्ज़न पर भरोसा कर सकता है। ADK के 𝚂𝚔𝚒𝚕𝚕𝚃𝚘𝚘𝚕𝚜𝚎𝚝 और प्रगतिशील प्रकटीकरण के लिए धन्यवाद, आपका एजेंट रनटाइम पर केवल उन्हीं पैटर्न पर कॉन्टेक्स्ट टोकन खर्च करता है जिनकी उसे आवश्यकता होती है।

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

आज ही शुरू करें

Agent Skills स्पेसिफिकेशन ओपन-सोर्स है और ADK में मूल रूप से समर्थित है। आप पहले से ही जानते हैं कि फ़ॉर्मेट को कैसे पैकेज करना है। अब आप जानते हैं कि सामग्री को कैसे डिज़ाइन करना है। Google Agent Development Kit के साथ स्मार्ट एजेंट बनाएँ।