- Agent Skills एक ऐसा scaffolding है जो AI coding agents को spec, test, review-योग्य PR, trust boundary review जैसी senior engineering प्रक्रियाएँ छोड़े बिना workflow के ज़रिए लागू कराता है
- skill frontmatter वाली Markdown file होती है, और reference document से ज़्यादा चरणों के क्रम, checkpoint evidence, और exit criteria वाले workflow के करीब होती है
- repository की 20 skills, Define, Plan, Build, Verify, Review, Ship के 6 lifecycle stages और
/spec, /plan, /build, /test, /review, /ship, /code-simplify इन 7 slash commands से बनी हैं
- मुख्य सिद्धांत हैं गद्य से अधिक process, anti-rationalization tables, verification को exit criteria मानना, progressive disclosure, और scope discipline;
using-agent-skills काम के हिसाब से सिर्फ़ ज़रूरी skills को activate करता है
- इसे Claude Code marketplace install, Cursor
.cursor/rules/, Gemini CLI, Codex, Aider, Windsurf, OpenCode जैसे tools में Markdown डालकर इस्तेमाल किया जा सकता है, और यह MIT license के तहत उपलब्ध है
उद्देश्य और समस्या की समझ
- Agent Skills एक ऐसा scaffolding है जिसका उद्देश्य AI coding agents को वे senior engineering प्रक्रियाएँ workflow के रूप में लागू कराना है जिन्हें वे आम तौर पर छोड़ देते हैं
- AI coding agents को जब कोई feature implement करने को कहा जाता है, तो वे आम तौर पर सबसे छोटे रास्ते से implementation पूरा कर देते हैं, और spec लिखना, tests पहले बनाना, trust boundary review करना, review-योग्य PR बनाना जैसी प्रक्रियाएँ डिफ़ॉल्ट रूप से नहीं करते
- senior engineers के काम में बहुत कुछ ऐसा होता है जो diff में दिखता नहीं है
- assumptions स्पष्ट करना
- spec लिखना
- काम को review-योग्य units में बाँटना
- उबाऊ लेकिन सुरक्षित design चुनना
- नतीजा सही है इसका evidence छोड़ना
- changes को इतना सीमित रखना कि इंसान वास्तव में review कर सके
- agents इन चरणों को छोड़ते हैं क्योंकि, junior engineers की तरह, उनका reward signal “काम पूरा” पर set होता है, “spec document सहित काम पूरा” पर नहीं
- Agent Skills repository को 26K से ज़्यादा stars मिले हैं, और यह README से आगे बढ़कर design choices के कारण, standard SDLC और Google की सार्वजनिक engineering practices से उनका mapping, और वे patterns भी कवर करती है जिन्हें install किए बिना अपनाया जा सकता है
skill का वास्तविक मतलब
- skill frontmatter सहित एक Markdown file है जिसे स्थिति के अनुसार agent context में inject किया जाता है; इसका रूप system prompt fragments और runbook के बीच कहीं पड़ता है
- skill कोई reference document नहीं है, न ही “tests के बारे में सब कुछ” जैसी knowledge collection है
- उपयोगी skill वह workflow है जिसका agent पालन करता है
- इसमें चरणों का क्रम होता है
- checkpoints पर evidence generate होता है
- यह स्पष्ट exit criteria के साथ समाप्त होती है
- अगर testing best practices पर 2,000 शब्दों का essay context में डाल दिया जाए, तो agent विश्वसनीय लगने वाले वाक्य बना सकता है और असली testing छोड़ सकता है
- इसके उलट, अगर workflow दिया जाए जिसमें पहले failing test लिखना, उसे चलाकर failure confirm करना, pass होने के लिए minimum implementation लिखना, pass verify करना, और refactor करना शामिल हो, तो agent के पास करने के लिए ठोस काम होता है और इंसान उसे verify कर सकता है
- मुख्य अंतर है गद्य से अधिक process, reference से अधिक workflow, और exit criteria के बिना essay के बजाय exit criteria वाले steps
- कई “AI rules” repositories के असरदार न होने की वजह यही है कि वे workflows की बजाय essays बनकर रह जाती हैं
SDLC और slash command संरचना
- repository की 20 skills, 6 lifecycle stages में संगठित हैं, और उनके ऊपर 7 slash commands रखे गए हैं
-
चरण और commands
/spec: Define चरण, जिसमें तय होता है कि क्या बनाना है/plan: Plan चरण, जिसमें काम को तोड़ा जाता है/build: Build चरण, जिसमें vertical slice के रूप में implementation होती है/test: Verify चरण, जिसमें behavior सिद्ध किया जाता है/review: Review चरण, जिसमें छूटे हुए issues पकड़े जाते हैं/ship: Ship चरण, जिसमें users तक सुरक्षित delivery की जाती है/code-simplify: एक simplification command जो पूरे flow में लागू होती है- यह संरचना किसी सही ढंग से चलने वाले engineering organization के SDLC जैसी है; अलग-अलग organizations में सिर्फ़ vocabulary बदलती है
- Google में यह design doc → review → implementation → readability review → launch checklist flow के रूप में दिखती है, और Amazon में working-backwards memo और bar raiser जैसी practices के रूप में
- AI coding agents की नई समस्या यह है कि ज़्यादातर agents डिफ़ॉल्ट रूप से इन चरणों में से अधिकांश को छोड़ देते हैं
- अगर किसी feature की माँग की जाए, तो सिर्फ़ implementation निकलती है; spec, plan, tests, review, release checklist नहीं
- skills उन चरणों को agents पर भी लागू करती हैं जिन्हें senior engineers खुद पर लागू करते हैं; ऐसी प्रक्रियाओं के बिना code deploy करना incidents तक ले जा सकता है
- complex feature में 11 skills क्रम से activate हो सकती हैं, जबकि छोटे bug fix में सिर्फ़ 3 skills लग सकती हैं
using-agent-skills router तय करता है कि मौजूदा काम पर कौन-सी skills लागू होंगी, और workflow अनुमानित scope के बजाय वास्तविक scope के हिसाब से फैलता है
काम करने के पीछे के सिद्धांत
-
1. गद्य से अधिक process
- workflow को agent action में बदल सकता है, essay को नहीं
- यही सिद्धांत human teams पर भी लागू होता है
- अगर team handbook 200 pages की हो, तो दबाव की स्थिति में कोई उसे नहीं पढ़ता; लेकिन checkpoints वाला छोटा workflow वास्तव में execute होने की ज़्यादा संभावना रखता है
-
2. anti-rationalization tables
- Agent Skills की सबसे अलग और ऐसी design choice जिसे दूसरी teams को अपनाना चाहिए, वह है anti-rationalization tables
- हर skill में वे आम बहाने और उनके लिए पहले से लिखे गए जवाब शामिल होते हैं जिन्हें agent या थका हुआ engineer workflow छोड़ने के लिए इस्तेमाल कर सकता है
- उदाहरण:
- “यह काम इतना simple है कि spec की ज़रूरत नहीं” → acceptance criteria फिर भी लागू होते हैं। 5 lines ठीक हैं, 0 lines नहीं
- “test बाद में लिख दूँगा” → “बाद में” ही मूल समस्या है। बाद में कुछ नहीं होता। पहले failing test लिखना होगा
- “tests pass हो गए, अब deploy कर देते हैं” → passing tests evidence हैं, proof नहीं। यह देखना होगा कि runtime check हुआ या नहीं, user-visible behavior verify हुआ या नहीं, और क्या किसी इंसान ने diff पढ़ा
- LLMs rationalization में माहिर होते हैं, और वे विश्वसनीय पैराग्राफ बना सकते हैं कि किसी काम को spec की ज़रूरत नहीं या कोई change review के बिना merge हो सकता है
- anti-rationalization table दरअसल उन झूठों के लिए पहले से लिखी rebuttal है जो agent ने अभी बोले भी नहीं हैं
- यह pattern human teams पर भी लागू होता है
- engineering quality की गिरावट अक्सर इसलिए नहीं होती कि किसी ने जानबूझकर बुरा काम करने का फैसला किया, बल्कि इसलिए कि उसने किसी नापसंद प्रक्रिया को छोड़ने के लिए दिया गया विश्वसनीय justification स्वीकार कर लिया
-
3. verification पर समझौता नहीं
- हर skill ठोस evidence पर समाप्त होती है
- passing tests, clean build output, अपेक्षित behavior दिखाने वाला runtime trace, reviewer approval जैसी चीज़ें exit criteria बनती हैं
- “काफ़ी सही लग रहा है” पर्याप्त नहीं है
- यही सिद्धांत Anthropic के harness में failure recovery, Cursor के planner/worker/judge separation से bug पकड़ने, और long-running agent को recoverable बनाने के पीछे काम करता है
- agent एक generator है, इसलिए काम पूरा हुआ या नहीं इसका अलग signal चाहिए; skills वही signal हर workflow में embed करती हैं
-
4. progressive disclosure
- session की शुरुआत में सभी 20 skills context में नहीं डाली जातीं
- सिर्फ़ मौजूदा चरण के लिए ज़रूरी skills activate की जाती हैं
- छोटा meta-skill
using-agent-skills एक router की तरह काम करता है जो तय करता है कि मौजूदा task के लिए कौन-सी skills सही हैं
- यह harness engineering की सीख को skill unit पर लागू करता है
- context में load किया गया हर token कहीं न कहीं performance घटाता है, इसलिए सिर्फ़ संबंधित चीज़ें load होनी चाहिए और बाकी disk पर रहनी चाहिए
- progressive disclosure 20-skill library को 5K-token slot में रखते हुए पूरे context को प्रदूषित किए बिना इस्तेमाल करने का तरीका है
-
5. scope discipline
- meta-skill यह non-negotiable principle encode करती है: “सिर्फ़ वही छुओ जो माँगा गया है”
- पास के systems को refactor मत करो, जिस code को पूरी तरह समझते नहीं उसे मत हटाओ, और TODO देखकर पूरी file फिर से लिखने का फैसला मत करो
- agent एक bug fix करते-करते असंबंधित 3 files को modernize करने लग सकता है
- scope discipline यह तय करने वाला सबसे बड़ा factor है कि agent का PR merge-योग्य है या revert करना पड़ेगा
- यह Google के code review norms से भी मेल खाता है, जहाँ एक PR एक से ज़्यादा काम करे तो reviewer उसे रोक सकता है
Google engineering practices से संबंध
- Agent Skills में Software Engineering at Google और Google की सार्वजनिक engineering culture से निकली कई practices प्रतिबिंबित होती हैं
- Google-scale software को कामयाब बनाने वाले कई तत्व सार्वजनिक रूप से documented हैं, और agents सबसे ज़्यादा इन्हीं चीज़ों को छोड़ते हैं
-
skills और practices का mapping
api-and-interface-design: Hyrum’s Law को दर्शाता है। API का हर observable behavior अंततः किसी न किसी dependency में बदल जाएगा, इसलिए design उसी हिसाब से होनी चाहिएtest-driven-development: test pyramid ~80/15/5 और Beyoncé Rule को दर्शाता है। सिद्धांत यह है कि “अगर यह इतना पसंद था, तो test लगाना चाहिए था”; bugs को infrastructure changes नहीं बल्कि tests पकड़ते हैं- tests में DAMP over DRY: Google की testing philosophy के अनुसार test code को थोड़ी duplication सहते हुए भी spec की तरह पढ़ा जाना चाहिए। ज़रूरत से ज़्यादा abstract tests एक जाना-पहचाना anti-pattern हैं
code-review-and-quality: ~100-line PR size और Critical / Nit / Optional / FYI severity labels को दर्शाता है। बड़े PR अक्सर वास्तव में review नहीं होते और rubber-stamp approval पा लेते हैंcode-simplification: Chesterton’s Fence को दर्शाता है। किसी चीज़ को क्यों रखा गया है यह समझे बिना उसे हटाना नहीं चाहिएgit-workflow-and-versioning: trunk-based development और atomic commits को दर्शाता हैci-cd-and-automation: Shift Left और feature flags को दर्शाता है। समस्याएँ जितनी जल्दी हो सके पकड़नी चाहिए और deploy तथा release को अलग रखना चाहिएdeprecation-and-migration: code-as-liability को दर्शाता है। हर maintain की जाने वाली line का स्थायी maintenance cost होता है, इसलिए छोटा surface area बेहतर है- ये concepts नए नहीं हैं, लेकिन agents में by default built-in नहीं आते
- कोई frontier model training data में “Hyrum’s Law” पढ़ चुका हो, तब भी वह रात 3 बजे API design करते समय इसे अपने-आप लागू नहीं करेगा
- skills इन practices को agents से वास्तविक काम के दौरान लागू कराती हैं
वास्तविक उपयोग के तरीके
install किए बिना अपनाए जा सकने वाले patterns
-
anti-rationalization को team practice बनाना
- team को उन झूठों को लिखना चाहिए जो वह खुद से बोलती है
- उदाहरण: “release के बाद tests ठीक कर देंगे”, “यह change इतनी छोटी है कि design doc की ज़रूरत नहीं”, “monitoring है, इसलिए ठीक है”
- हर वाक्य के साथ rebuttal जोड़कर
AGENTS.md या engineering wiki में रखने से बहस कम होती है और शुक्रवार दोपहर वाले थके हुए shortcuts पकड़े जा सकते हैं
-
internal docs को गद्य नहीं, process के रूप में लिखना
- अगर आप “हम X को कैसे approach करते हैं” पर 2,000 शब्दों का document लिख रहे हैं, तो आप reference material लिख रहे हैं
- इसे checkpoints वाले workflow में बदल दें, तो document 400 शब्दों तक सिमट सकता है और वास्तव में execute होने की संभावना बढ़ जाती है
- यह सिद्धांत onboarding guides, runbooks, और agent skills सभी पर लागू होता है
-
verification को ठोस exit criteria बनाना
- हर task का अंतिम चरण “evidence generate करना” होना चाहिए
- यह agents, engineers, और individual work सभी पर लागू होता है
- evidence green test run, screenshot, logs, review approval जैसी कोई भी चीज़ हो सकती है जो साबित करे कि काम पूरा हो गया है
- अगर evidence नहीं है, तो काम पूरा नहीं हुआ; “ठीक लग रहा है” loop बंद नहीं करता
-
हर rulebook पर progressive disclosure लागू करना
- 50-page handbook लिखने के बजाय छोटा router लिखना चाहिए जो ज़रूरत के हिसाब से छोटे sections की ओर भेजे
- यह
AGENTS.md, runbooks, incident response playbooks, और दबाव की स्थिति में पढ़े जाने वाले हर document पर लागू होता है
-
AGENTS.md में डालने लायक 5 non-negotiable principles
- build शुरू करने से पहले assumptions स्पष्ट करनी चाहिए। चुपचाप बनी रहने वाली गलत assumptions सबसे आम failure modes में से हैं
- अगर requirements टकराएँ, तो रुककर पूछना चाहिए। अंदाज़ा नहीं लगाना चाहिए
- ज़रूरत पड़ने पर असहमति जतानी चाहिए। agent या engineer yes-man नहीं होता
- उबाऊ और स्पष्ट solutions को प्राथमिकता देनी चाहिए। चतुराई महँगी पड़ती है
- सिर्फ़ वही छूना चाहिए जो माँगा गया है
harness के भीतर इसकी जगह
- बड़े परिप्रेक्ष्य में skills, agent harness engineering की एक layer हैं
- harness में model और उसके आसपास बनाई गई हर चीज़ आती है, और skills ऐसे reusable workflow fragments हैं जो system prompt में progressively disclose किए जाते हैं
- skills,
AGENTS.md, hooks, tools, और session log के साथ-साथ रखी जाती हैं
AGENTS.md: लगातार update होने वाली rulebook की भूमिका निभाती है- hooks: deterministic enforcement layer हैं
- tools: वे actions हैं जो agent कर सकता है
- session log: persistent memory है
- skills: senior engineering process संभालती हैं
- skills की अहमियत chat-based agents की तुलना में long-running agents में और बढ़ जाती है
- लंबा execution हर shortcut को amplify कर देता है
- 10-minute session में tests छोड़ने वाला agent एक bug पैदा कर सकता है
- 30-hour session में tests छोड़ने वाला agent अंत में ऐसी debugging archaeology पैदा कर सकता है जिसमें मूल intent किसी को याद न रहे
- execution time जितना लंबा हो, senior engineering scaffolding उतनी ही कम suggestion और उतनी ही ज़्यादा enforced constraint होनी चाहिए
- skill format की portability भी महत्वपूर्ण है
- वही
SKILL.md file Claude Code, rules वाले Cursor, Gemini CLI, Codex, और system prompt content स्वीकार करने वाले अन्य harnesses में इस्तेमाल की जा सकती है
- workflow एक बार लिख दिया जाए, तो runtime उसे enforce कर सकता है; और bespoke prompt engineering के विपरीत यही Markdown-with-frontmatter format का फ़ायदा है
निष्कर्ष
- AI coding agents बेहद सक्षम junior engineers की तरह व्यवहार करते हैं, लेकिन diff में न दिखने वाले कामों के लिए उनके पास सहज प्रवृत्ति नहीं होती
- assumptions स्पष्ट करना, change size नियंत्रित करना, spec लिखना, evidence छोड़ना, और non-reviewable changes को merge करने से मना करना जैसी senior engineering ज़िम्मेदारियाँ agents छोड़ सकते हैं, जब तक उन्हें ऐसा न करने के लिए मजबूर न किया जाए
- आगे चलकर सबसे महत्वपूर्ण काम यह होगा कि इन disciplines को ऐसी form में encode किया जाए जिससे agent खुद उन्हें बोलकर bypass न कर सके
- skills ऐसा ही एक रूप हैं, और anti-rationalization tables, progressive disclosure, गद्य से अधिक process, exit criteria के रूप में verification, और पहले से काम कर रही Google practices को portable बनाने वाली यह संरचना इसका मूल है
- Agent Skills repository MIT license के तहत उपलब्ध है, और बड़े scaffolding perspective को Agent Harness Engineering तथा Long-running Agents में आगे पढ़ा जा सकता है
1 टिप्पणियां
Hacker News की राय
यह लगभग धोखेबाज़ रामबाण इलाज जैसा है। पढ़ने लायक है और ऊपर-ऊपर से ठीक भी लगता है, लेकिन आखिर में यह फिर भी धोखेबाज़ रामबाण इलाज ही है
वजह यह है कि स्लॉट मशीन जैसे मॉडल
AGENTS.md,memory.md, और दर्जनों skill Markdown files में लिखी अनिवार्य आवश्यकताएँ कभी भी छोड़ सकते हैं, और यह लगभग तय हैइस तरह का harness approach यह दिखाता है मानो LLM सख्ती और पूरी तरह नियमों का पालन करता हो, और समस्या सिर्फ इतनी हो कि हम नियमों को पर्याप्त स्पष्ट और पर्याप्त मात्रा में नहीं लिख पाए। यह LLM के काम करने के तरीके को लेकर एक बुनियादी समझ संबंधी गलती है
आखिरकार भरोसेमंद तो नहीं है, और तुलनात्मक रूप से ज़्यादा भरोसेमंद विकल्प सिर्फ मानवीय review और supervision है, और हो सके तो लगातार दो बार
बाकी सब धोखेबाज़ रामबाण इलाज ही है, और उस बिंदु पर जाकर समझ आता है कि वादा की गई productivity gains भी वैसी ही हैं। क्योंकि code पढ़कर दिमाग में मॉडल बनाना, पहले से दिमाग में मॉडल होने पर उसे code में उतारने से कहीं ज़्यादा कठिन है
code पढ़ना किस code की बात हो रही है उस पर निर्भर करता है, लेकिन दूसरी skills की तरह practice से आसान हो जाता है। यह तब आम बात है जब आपको बहुत पुराने, बड़े और जटिल codebase के साथ काम करना पड़ता है, जहाँ लिखने से ज़्यादा code पढ़ना होता है
यह और आसान तब होता है जब docs, पुराना अनुभव, या teammates से पूछकर आपके पास code का मानसिक मॉडल पहले से हो
agents के साथ भी यह संभव है। आमतौर पर AI को prompt देने से पहले आपको code structure अच्छी तरह पता होता है, और अगर काम को सावधानी से बाँटा जाए तो generated code का review बहुत आसान हो जाता है। यह पहले से पढ़ी किताब दोबारा पढ़ने जैसा लगता है, और कभी-कभार कुछ गलत हो तो वह तुरंत दिख जाता है, इसलिए शुरुआत में ही ज़्यादातर चीज़ें पकड़ ली जाती हैं। किसी भी तरह देखें, speedup काफ़ी बड़ा है
लेकिन पिछले कुछ महीनों से मैंने spec-kit, यानी AI को इस तरह इस्तेमाल करने का तरीका, आज़माया है और व्यवहार में यह हैरान करने जितना अच्छा रहा। मैं शानदार चीज़ें बना रहा हूँ, और जो समस्याएँ अनुमान के रूप में उठाई गईं वे अभी तक नहीं आईं। आगे कभी आ सकती हैं, इसलिए सावधान हूँ
फिर भी कुछ समय तक ख़ुद इस्तेमाल करने के बाद इसे बस धोखेबाज़ रामबाण इलाज कहकर खारिज नहीं किया जा सकता। मैं 30 साल से ज़्यादा समय से programmer हूँ, और मुझे लगता है कि क्या काम करता है और क्या नहीं, इसका मुझे काफ़ी अच्छा अंदाज़ा है
आगे मैं ऐसे harness देखना चाहता हूँ जो request नहीं बल्कि demand करें। जैसे agent को plan mode में रहने को कहा गया है, और अगर वह तय planning procedure न माने तो उसे terminate कर दिया जाए। पूरी तरह perfect न भी हो, फिर भी यह इंसान-इन-द-लूप वाले मौजूदा तरीके से बेहतर होना चाहिए
कहा जाता है कि “skills frontmatter वाले Markdown files हैं जो सही स्थिति होने पर agent context में inject किए जाते हैं”, लेकिन यह तय करने वाला कि वह सही स्थिति है या नहीं, LLM ही है
और कहा जाता है कि “यह उन steps की श्रृंखला है जिन्हें agent follow करता है, और जो evidence बनाने वाले checkpoints और साफ़ end criteria पर खत्म होती है”, लेकिन यह तय करने की क्षमता कि उन steps को follow करना है या नहीं, वह भी LLM के पास है
$my-skillसे skill को सीधे call कर सकते हैं, और तब वह skill सचमुच context में inject हो जाती है। उसके बाद LLM उसे उतना ही follow करता है जितना वह prompt, instructions और context के दूसरे हिस्सों को follow करता हैउस दिन का इंतज़ार है जब सब लोग agents से एक साल से ज़्यादा छेड़छाड़ करने के बाद समझेंगे कि उन्हें बस नकली productivity का एहसास हुआ था
यह मेरे वास्तविक अनुभव से बिल्कुल मेल नहीं खाता। AI coding के अनिवार्य पतन पर इतना यक़ीन किस अनुभव ने दिलाया, यह जानना चाहूँगा। क्या यह एक दार्शनिक विश्वास है कि AI नैतिक रूप से गलत है, या फिर आपने सच में AI से कुछ बनाया है, काफ़ी खोजबीन की है, और उसके बाद यह मज़बूत निष्कर्ष निकाला है
मैं 30 साल से ज़्यादा समय से रोज़ code लिख रहा हूँ, और 20 साल से ज़्यादा समय से पेशेवर रूप से। मैंने फैशन आते-जाते देखे हैं, और काम करने के तरीके बदलने वाली असली प्रगति भी कई बार देखी है। AI से जितने ज़्यादा projects बनाता हूँ, उतना ही पक्का होता जाता है कि यह software बनाने और computers इस्तेमाल करने के तरीके में स्थायी और बुनियादी बदलाव है
मैंने AI को बेहतर होते देखा है, और ख़ुद को भी असली काम पूरा कराने में ज़्यादा सक्षम होते देखा है। वह काम पहले ही वास्तविक दुनिया के production load पर test हो चुका है। हो सकता है आपको जो हो रहा है वह पसंद न हो, और AI के साथ काम करने का अनुभव भी न पसंद हो, लेकिन इसका यह मतलब नहीं कि वह लोगों को वास्तविक value नहीं दे रहा या असली काम नहीं कर रहा
हम लगभग सितंबर से Claude Code पर पूरी तरह आ गए हैं, और improvements को सफलतापूर्वक track कर पाए हैं। हम ऐसे features deploy कर रहे हैं जो वास्तविक production में इस्तेमाल हो रहे हैं। infra side पर भी, business logic implementation में भी, और frontend व backend दोनों में
मुझे नहीं लगता कि लोग बस समय बर्बाद कर रहे हैं। हाँ, मैं मानता हूँ कि इस तरह की ज़्यादातर पोस्ट बकवास होती हैं, इसमें यह पोस्ट भी शामिल है। फिर भी AI development दुनिया भर की बहुत-सी कंपनियों में पहले से हो रहा है
मुझे नहीं लगता कि agent-style workflows अभी उस स्तर तक पहुँचे हैं, लेकिन manually call करके AI के साथ-साथ काम करने के लिए skills का implementation निश्चित रूप से ठीक है। हमारी company आजकल sandboxing और safe skills पर बहुत ध्यान दे रही है
feature development अभी तक बहुत अच्छी तरह पकड़ में नहीं आई है, लेकिन मेरे लिखे हुए review skill और Grafana skill काफ़ी मज़बूत रहे हैं
मैंने पहले बड़े agent skill bundles इस्तेमाल किए थे, लेकिन वे बहुत ज़्यादा करने की कोशिश करते थे, इसलिए समय की बर्बादी लगे। Vim की तरह skills को पूरे IDE की तरह install करने के बजाय, community से चुनकर इस्तेमाल करना कई बार बेहतर होता है
skills हर developer और team के लिए अलग होती हैं, इसलिए वे बहुत व्यक्तिगत हैं। किसी और की settings को bulk में install करने के बजाय, उन्हें अपनी setup बनाने के लिए reference material की तरह लेना ज़्यादा सही है
search optimization या LLM optimization के नज़रिए से देखें तो, अगर नाम नहीं बदला गया तो इन skills की discoverability मुश्किल लगती है: https://agentskills.io/
अगर Addy यह देख रहे हों, तो जानना चाहूँगा कि वह इसे Superpowers से तुलना करके कैसे समझाएँगे: https://github.com/obra/superpowers
मैं superpowers से पहले से agent development की तरफ़ था, और अब मुझे चिंता है कि मेरे self-built process का 50% से ज़्यादा हिस्सा superpowers cover करने लगा है
मैं अब GitHub stars पर भरोसा नहीं करता। काश कोई बताए। क्या superpowers अब सचमुच adopt हो चुका है? अगर यह वास्तव में इतना मूल्यवान है, तो Boris ने अभी तक उस concept को integrate क्यों नहीं किया?
“अगर आपको 1% भी लगे कि कोई skill आपके काम पर लागू हो सकती है, तो आपको वह skill ज़रूर call करनी चाहिए”
समझ नहीं आता कि सब लोग अपनी ही नौकरियाँ खत्म करने को लेकर इतने उत्साहित क्यों हैं
हो सकता है ये चीज़ें या कोई “skills” सच में इतना न करें, लेकिन सिद्धांत की बात कर रहा हूँ। यह बड़े पैमाने पर श्रम से अलगाव जैसा लगता है
मानवता ने जितना पीछे तक पता लगाया जा सकता है, हमेशा किसी निश्चित output के लिए ज़रूरी labor कम करने की कोशिश की है, और वही सभ्यता है। क्या हमें फिर से कुदाल से हाथ से खेती करने वाले दौर में लौट जाना चाहिए सिर्फ़ writing labor को maximize करने के लिए? क्या हमें फिर से एक-एक करके street lights जलाने वाले समय में लौटना चाहिए?
automation में पीछे रह जाने वाले समाज ग़रीब होते जाते हैं और अंततः मर जाते हैं। वहाँ पैदा हुए लोग भी ज़्यादा productive जगहों पर चले जाते हैं। यह पूर्वी यूरोप में भी हुआ, Amish समुदाय में भी, और हर उस ग़रीब समाज में जहाँ migration होती है। कम से ज़्यादा करना हमेशा दिलचस्प काम रहा है
क्या आप हर automation के बारे में ऐसा ही महसूस करते हैं, यह जानना चाहता हूँ। पुराने ज़माने के कुछ system administrators infra automation की प्रगति को इसी तरह देखते थे, और उन्हें यह पसंद नहीं था कि जो काम पहले हाथ से होता था वह scripts और systems करने लगें
हमारी team ने एक नौकरी में 30,000 servers पर patches अपने-आप चलाने और systems को production से अपने-आप बाहर-भीतर करने वाला automated patching system बनाया था। पूरी process hands-off हो गई थी, जबकि पहले यह प्रक्रिया manually चलाने के लिए dedicated team थी। क्या automation ने उनकी jobs छीन लीं?
एक अर्थ में हाँ, लेकिन और काम भी थे जो करने थे, और अब वे वह काम कर सकते थे
programming, computers और technology मुझे इसलिए पसंद हैं क्योंकि वे हमारे बदले काम करते हैं। मेरा utopia वह दुनिया है जहाँ robots सारा कठिन काम कर लें ताकि इंसान जो चाहें वह कर सकें। AI हमें उस दिशा में एक कदम और ले जा रहा है। मैं यह सोचने के बजाय कि robots jobs ले जाएँ तो लोगों को व्यस्त रखने के लिए पर्याप्त अप्रिय काम कैसे बचा रहे, इस पर ध्यान देना पसंद करूँगा कि robots के काम संभालने का फ़ायदा सिर्फ़ अमीर मालिकों को नहीं बल्कि पूरी दुनिया को कैसे मिले
अभी यह साफ़ नहीं है कि सब कुछ किस दिशा में evolve करेगा, इसलिए लोग अपना data random agents को देकर देख रहे हैं, context को store और access करने के तरीके ढूँढ रहे हैं, prompts को reuse कर रहे हैं, और इस technology के साथ काम करने के कई प्रयोग कर रहे हैं
इनमें से ज़्यादातर चीज़ें एक साल बाद अगली पीढ़ी के models में गहराई से integrate होकर बेकार हो सकती हैं। फिर भी progress के साथ चलते रहना इस क्षेत्र में काम करने के मज़े का हिस्सा रहा है
अगर लंबी अवधि का data यह दिखाए कि औसतन productivity gains सीमित रही हैं, और top-end modern models की मदद के बावजूद high-quality software बनाने के लिए अब भी बारीकी और मानवीय ध्यान चाहिए, तो शायद समर्थक और विरोधी दोनों थोड़ा चकित होंगे
यह वही काम है, बस screwdriver की जगह power drill मिल गई है। कुछ लोग सैकड़ों साल टिकने वाले घर बनाते हैं, कुछ नहीं
मैं आजकल यह बात बार-बार सुन रहा हूँ। developer teams को manage करने में जो चीज़ें अच्छी हैं, वही LLM management में भी अच्छी हैं
अच्छे test cases, स्पष्ट और संक्षिप्त docs, CI/CD, best practices और onboarding docs
LLM को manage करना धीरे-धीरे इंसानी टीम को manage करने जैसा होता जा रहा है
जानना चाहूँगा कि यह spec-kit से कैसे बेहतर है या कैसे अलग है। दर्शन बहुत मिलता-जुलता लगता है, और यह भी सोच रहा हूँ कि क्या दोनों साथ इस्तेमाल हो सकते हैं। या फिर यह बस overlap है?
https://github.com/github/spec-kit
मुझे हैरानी हुई कि कुछ skills इतनी लंबी हैं। उनमें tables, checkbox lists, code examples वगैरह हैं और वे कई pages में फैली हुई हैं
जानना चाहूँगा कि यह कितना आम है। ऐसी कुछ ही चीज़ें context का काफ़ी हिस्सा भर देंगी, ऐसा लगता है
एक दिलचस्प प्रयोग है। LLM से कुछ ऐसा लिखने को कहिए जिससे वह बस हल्का-सा परिचित हो। जैसे “write a fib” कहिए, तो लगभग हर LLM, क्योंकि उसे code पर fine-tune किया गया है, जबकि किसी non-programmer के लिए उसका मतलब “छोटा झूठ लिखो” हो सकता है, Fibonacci sequence algorithm के रूप में जवाब देगा
यानी compression होता है। Fibonacci sequence क्या है, यह विस्तार से बताए बिना, सिर्फ़ तीन ambiguous tokens से नतीजा व्यक्त किया जा सकता है
इसलिए prompt की length महत्वपूर्ण नहीं है। महत्वपूर्ण है सही शब्द, उनकी frequency, और उनका order। दो pages के prompt और दो sentences के prompt से एक जैसा result आ सकता है
अभी तक मुझे छोटी और focused skills के साथ सफलता मिली है। मैं उन्हें reusable context snippets की तरह रखता हूँ, लेकिन छोटा। जैसे मेरे project में Python कैसे इस्तेमाल होता है और unit tests कैसे चलाए जाते हैं, इस पर कुछ paragraphs
मेरे पास कई छोटी “info” skills भी हैं जिनमें agent को instructions नहीं दिए जाते, बल्कि बस उपयोगी context information होती है जिसे ज़रूरत पड़ने पर ऊपर लाया जा सकता है
skills बहुत ज़्यादा हो जाएँ तो वह भी समस्या बन सकती है। क्योंकि skill names और descriptions की list भी किसी बिंदु पर context में पहुँच जाती है
छोटे LLM context जैसे 128k में यह लगभग 10% के आसपास है, और बड़े models की 1M context window में तो लगभग दिखेगा भी नहीं
हो सकता है मैं यहाँ कुछ ज़्यादा conservative हूँ। अभी और explore करना है
“Senior engineer का ज़्यादातर काम diff में दिखाई नहीं देता”
Agent Skills, Addy की उस काम को भी खत्म करने की कोशिश है। चीयर्स, Addy :P