Ask HN: आप skills files को कैसे प्रबंधित करते हैं?
AI users इस बात पर बंटे हुए हैं कि “skills” — LLM agents के लिए reusable prompt और workflow files — models के बेहतर होने के साथ आवश्यक infrastructure हैं या अनावश्यक जटिलता। कई लोग इन्हें cached workflows और project-specific runbooks के रूप में उपयोगी मानते हैं, जो tooling conventions encode करते हैं, token use कम करते हैं, और agents को अधिक reliable बनाते हैं, खासकर proprietary या complex environments में। अन्य लोग तर्क देते हैं कि generic, internet-download किए गए skills अक्सर snake oil होते हैं, और केवल छोटे, curated, version-controlled set को (अक्सर Git, symlinks, या custom CLIs से) प्रबंधित करने तथा बाकी सबके लिए deterministic scripts या अच्छे AGENTS.md/docs पर निर्भर रहने की सलाह देते हैं।
“skills” क्या हैं और ये कहाँ मदद करते हैं
- कई लोग skills को छोटे, पुन: प्रयोज्य prompt files या runbooks के रूप में वर्णित करते हैं जो agents को बताते हैं कि दोहराए जाने वाले काम कैसे करने हैं, अक्सर deterministic scripts को उच्च-स्तरीय guidance के साथ जोड़ते हुए।
- आम उपयोग:
- बार-बार इस्तेमाल होने वाले prompts के लिए macros / shortcuts (जैसे, rebasing, test runs, Jira workflows)।
- project- या org-specific conventions: coding style, commit messages, branching, deployment steps.
- niche tools/CLIs या proprietary systems के लिए interfaces, जो model training data में अच्छी तरह covered नहीं हैं।
- “workflow caches” जो multi-step processes करने का तरीका फिर से खोजने से बचाते हैं।
संदेहवाद और “skills obsolete हैं” वाले तर्क
- कई लोगों का तर्क है कि modern models repos और docs से अधिकांश “general” behaviors (design critique, basic code review) infer कर सकते हैं, जिससे generic marketplace skills unnecessary या harmful हो जाते हैं।
- कुछ लोग बड़ी skill collections को code smell, अतिरिक्त tech debt, और influencer marketing का उत्पाद मानते हैं।
- अन्य लोग लगभग सब कुछ AGENTS.md/README में रखने और model को code तथा docs सीधे पढ़ने देने को प्राथमिकता देते हैं।
- LLM judgment पर ज़्यादा भरोसा करने और skills के आसपास fragile, opaque systems बनाने को लेकर चिंता है।
जब skills को essential माना जाता है
- कई लोग इनमें बड़े फायदे बताते हैं:
- Proprietary, complex, या cross-system workflows (deployments, CI, security checks, compliance).
- Custom tools (जैसे obscure CLIs, DSLs) का उपयोग करते समय token use और trial-and-error कम करना।
- मुश्किल से सीखे गए debugging flows या “यहाँ X कैसे करना है” को कैप्चर करना ताकि agents उन्हें फिर से न सीखें।
- Skills को contextual guidance और process encoding के रूप में देखा जाता है, “extra intelligence” के रूप में नहीं।
Organization, sharing, और tooling
- सामान्य patterns:
- Skills को version control के तहत रखें (अक्सर dotfiles या dedicated repos में) और उन्हें agent skill directories में symlink करें।
- Install, update, और versions pin करने के लिए package-manager-like CLIs या “marketplaces” (internal या public) का उपयोग करें।
- Global vs project-specific skills अलग रखें; कुछ लोग task domain के अनुसार profiles या “skillsets” का उपयोग करते हैं।
- Scripts, Nix/Home Manager, या homegrown registries के जरिए skills को machines और agents के बीच sync करें।
Design, maintenance, और evaluation practices
- अक्सर सुझाए जाने वाले principles: zero skills से शुरू करें; केवल तब जोड़ें जब आपको repeated friction या wasted tokens दिखें; उन्हें कम, छोटे, और task-specific रखें; समय-समय पर prune करें।
- कुछ लोग skills को code की तरह मानते हैं: evals या behavioral tests चलाएँ, integration-style checks का उपयोग करें, और जब agents संघर्ष करें तो skills अपडेट करें।
- Third-party skills की security और authority को लेकर चिंताएँ उठाई जाती हैं; कई लोग केवल homegrown या internally reviewed skills को प्राथमिकता देते हैं।