अध्याय 04
स्किल्स और एजेंट्स
DWP एजेंट-निरपेक्ष है, पर यह दो आवर्ती निर्माण-खंडों — स्किल्स और एजेंट्स — और किसी भी काम के शुरू होने से पहले रिपॉज़िटरी में अभिमुख होने के एक सुविचारित तरीके की अपेक्षा करता है।
स्किल्स बनाम एजेंट्स
स्किल
कैसे — एक पुन: उपयोग योग्य प्रक्रिया
fix-lintadd-componenttranslate-syncdwp-create
एजेंट
कौन — एक विशेषज्ञ कार्यकर्ता
reviewerexecutorarchitecti18n-guardian
.claude .agents सांकेतिक लिंक → पश्चगामी संगतता दोनों को भ्रमित करना आसान है पर वे भिन्न उद्देश्यों की पूर्ति करते हैं:
- स्किल्स नाम से आमंत्रित की जाने वाली पुनः-प्रयोज्य प्रक्रियाएँ हैं। एक स्किल एक दोहराने योग्य वर्कफ़्लो को पैकेज करती है — परीक्षण चलाना, lint ठीक करना, एक कंपोनेंट बनाना — ताकि एजेंट और मनुष्य हर बार उसे एक ही तरह आमंत्रित करें।
- एजेंट्स एक परिभाषित भूमिका वाले विशेषीकृत कर्मी हैं — reviewer, executor, architect। हर एजेंट की एक केंद्रित ज़िम्मेदारी होती है और वह अपने दायरे में काम करता है।
एक उपयोगी सूत्र: एक स्किल यह है कि किसी आवर्ती कार्य को कैसे करना है; एक एजेंट यह है कि किसी प्रकार के काम के लिए कौन ज़िम्मेदार है।
एक जीवंत किट: रिपॉज़िटरी अपनी स्किल्स विकसित करती है
ऑनबोर्डिंग एक रिपॉज़िटरी को एजेंट हार्नेस में बदल देती है; यह उसे जमा नहीं देती। किट का अभिप्राय बढ़ना है, जैसे-जैसे रिपॉज़िटरी के वर्कफ़्लो स्पष्ट होते हैं। DWP एक author सब-स्किल प्रदान करता है — /skill-create और /agent-create के माध्यम से आमंत्रित — जो रिपॉज़िटरी के मौजूदा .agents/ लेआउट और परिपाटियों पर तर्क करता है, फिर उनसे मेल खाती एक नई स्किल, एजेंट, या पतला कमांड-डेलिगेटर लिखता है। रिपॉज़िटरी एक सामान्य किट विरासत में पाने के बजाय अपनी किट स्वयं रचती है।
author सब-स्किल उपयुक्तता के प्रति सजग है। यह उस दोहराने योग्य प्रक्रिया के लिए एक स्किल बनाता है जिसे लोग हाथ से चलाते हैं, अलग मॉडल या उपकरण ज़रूरतों वाली एक आवर्ती भूमिका के लिए एक एजेंट, और एक कमांड केवल एक पतले प्रवेश-बिंदु के रूप में जो किसी स्किल या एजेंट तक मार्ग बनाता है। यह किसी भी ऐसी सामान्य चीज़ को छोड़ देता है जो किसी वास्तविक वर्कफ़्लो से मेल नहीं खाती, और जो कुछ भी जोड़ता है उसके साथ .agents/docs/ कैटलॉग को समकालिक रखता है। यही सब-स्किल अनिवार्य Skills & Agents Discovery कार्य का आधार है, जो कैटलॉग को डिस्क पर वास्तव में मौजूद चीज़ से मिलाता है — और /dwp-verify उस मिलान की वस्तुनिष्ठ पुष्टि करता है, और यदि कैटलॉग तथा फ़ाइलें अलग हों तो विफल हो जाता है।
रखरखाव ऐडऑन
रचना से परे, DWP ऑप्ट-इन रखरखाव ऐडऑन भेजता है — एक रिपॉज़िटरी के AI-first होने के लिए कभी आवश्यक नहीं। dependency-upgrade ऐडऑन इसका आदर्श उदाहरण है: यह किसी एक को मानने के बजाय रिपॉज़िटरी के वास्तविक पैकेज मैनेजर पर तर्क करता है (npm, pnpm, या ncu के साथ yarn; pip, poetry, या uv; Cargo; Go modules; Bundler; Composer), फिर छोटे बैचों में अपग्रेड करता है, हर बैच के बाद रिपॉज़िटरी का वास्तविक सत्यापन-गेट चलाता है, विफल होने वाले किसी भी बैच को वापस ले लेता है, और बिना स्वतः-कमिट किए सारांश देता है। design-system ऐडऑन इंटरफ़ेस उदाहरण है: जब किसी रिपॉज़िटरी के पास एक उपयोगकर्ता-उन्मुख इंटरफ़ेस सतह हो, यह एक DESIGN.md बनाता है (docs/DESIGN.md पर, AGENTS.md से संदर्भित) जो हर पता लगाए गए प्रोफ़ाइल के अनुसार रिपॉज़िटरी की वास्तविक परिपाटियाँ पकड़ता है — विज़ुअल UI (रंग, टाइपोग्राफ़ी, स्पेसिंग, कंपोनेंट्स, सुलभता नियम), CLI आउटपुट (सिमेंटिक टर्मिनल शैलियाँ, पैनल और स्पिनर, TTY/NO_COLOR डिग्रेडेशन), और संवादात्मक (संदेश की आवाज़, संरचना, और प्रति-प्लेटफ़ॉर्म रेंडरिंग) — ताकि कोई भी एजेंट ऑन-ब्रांड, सुसंगत इंटरफ़ेस आउटपुट बनाए। एक डिज़ाइन सिस्टम का पता चलने पर विज़ुअल प्रोफ़ाइल डिफ़ॉल्ट-ऑन है; CLI और संवादात्मक प्रोफ़ाइल पता चलने पर अनुशंसित हैं और हमेशा पूछे जाते हैं; जिस रिपॉज़िटरी के पास कोई भी इंटरफ़ेस सतह न हो उसके लिए यह ऐडऑन कभी प्रस्तावित नहीं होता। ऐडऑन ऑनबोर्डिंग के दौरान स्पष्ट रूप से स्वीकार किए जाते हैं; किसी एक को अस्वीकार करने पर रिपॉज़िटरी पूर्णतः अनुरूप बनी रहती है।
तर्क-आधारित रिपॉज़िटरी ऑनबोर्डिंग
किसी योजना को बनाने या निष्पादित करने से पहले, एक एजेंट रिपॉज़िटरी में ऑनबोर्ड होता है। ऑनबोर्डिंग तर्क-आधारित है, स्क्रिप्ट-आधारित नहीं: एजेंट एक निश्चित सेटअप स्क्रिप्ट चलाने के बजाय एक मानसिक मॉडल बनाने के लिए रिपॉज़िटरी की संरचना, दस्तावेज़ीकरण और कॉन्फ़िगरेशन पढ़ता है।
ऑनबोर्डिंग के दौरान एजेंट रिपॉज़िटरी आर्किटाइप (स्वतंत्र बनाम ऑर्केस्ट्रेटर), build, test और lint कमांड्स, शैली, संरचना और नामकरण की मौजूदा परिपाटियाँ, और पहले से उपलब्ध स्किल्स तथा एजेंट्स की पहचान करता है। यही समझ एजेंट को रिपॉज़िटरी से लड़ने के बजाय उसके अनुरूप योजना बनाने और निष्पादित करने देती है।
परीक्षण और सत्यापन टूलचेन पर विशेष ध्यान दिया जाता है, क्योंकि सत्यापन-गेट ही किसी योजना के परिणाम को भरोसेमंद बनाते हैं। जब किसी रिपॉज़िटरी के पास पहले से परीक्षण और linter हों, तो ऑनबोर्डिंग उनकी वास्तविक कमांड्स और परिपाटियाँ दर्ज करती है। जब उसके पास कोई न हो, तो ऑनबोर्डिंग केवल इस कमी को नोट नहीं करती — यह स्टैक के अनुकूल एक सेटअप प्रस्तावित करती है और उसे रिपॉज़िटरी की परीक्षण मार्गदर्शिका में लिखती है, ताकि हर भावी योजना के पास चलाने के लिए एक अपरिभाषित गेट के बजाय एक वास्तविक गेट हो।
.agents/ डायरेक्टरी और .claude → .agents सिमलिंक
DWP एजेंट व्यवहार को परिभाषित करने वाली हर चीज़ — स्किल्स, कमांड्स, एजेंट परिभाषाएँ, आंतरिक दस्तावेज़ीकरण और सेटिंग्स — को एक एकल विहित डायरेक्टरी, .agents/, के अंतर्गत एकत्र करता है। यह नाम संकेत देता है कि सामग्री किसी एक उपकरण से बँधी होने के बजाय एजेंट्स के पार साझा है।
ऐतिहासिक रूप से .claude/ से पढ़ने वाले उपकरणों के साथ पश्च-संगतता के लिए, वह पाथ .agents/ का एक सिमलिंक है:
ls -la .claude
# .claude -> .agents
हर .claude/... पाथ पारदर्शी रूप से अपने .agents/... समकक्ष तक हल हो जाता है, इसलिए पुराने उपकरण काम करते रहते हैं जबकि नई सामग्री विहित .agents/ स्थान को संदर्भित करती है। स्किल्स और एजेंट्स को .agents/ के अंतर्गत वास्तविक फ़ाइलों के माध्यम से संपादित किया जाता है, कभी सिमलिंक के माध्यम से नहीं।