Superpowers: अक्टूबर 2025 तक मैं coding agents का उपयोग कैसे कर रहा हूँ

 (blog.fsck.com)
26 पॉइंट द्वारा GN⁺ 2025-10-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पिछले कुछ हफ्तों में Claude Code-आधारित coding agent system को व्यवस्थित करके ‘Superpowers’ नाम का एक नया extension tool बनाया गया
  • Superpowers plugin के रूप में install होता है और Claude को ‘Skills’ सिखाता है, जिनके जरिए काम करने के तरीकों को automate और बेहतर किया जाता है
  • Anthropic के Claude Code plugin system का उपयोग करके agent workflow automation, TDD execution, code review, Git worktree management आदि स्वायत्त रूप से कर सकता है
  • नया workflow अपने आप brainstorming → planning → implementation चरणों से गुजरता है, काम को parallel में चलाता है और RED/GREEN TDD method से test-driven development करता है
  • मुख्य अवधारणा ‘Skill’ है, जो उस knowledge unit को दर्शाती है जिसे Claude को किसी विशेष कार्य के समय संदर्भित करना चाहिए; उपयोगकर्ता इसे खुद लिख सकते हैं या Claude से learning documents के आधार पर बनवा सकते हैं
  • लेखक का मानना है कि यह संरचना आगे चलकर AI coding agents के self-improvement और collaboration का standard बन सकती है, और अगला लक्ष्य Superpowers का sharing feature तथा memory system को पूरा करना है

Superpowers का अवलोकन

  • Superpowers Claude Code 2.0.13 या उससे ऊपर पर काम करता है, और उपयोगकर्ता इसे /plugin marketplace add obra/superpowers-marketplace कमांड से install कर सकते हैं
  • install के बाद Claude अपने आप SKILL.md दस्तावेज़ पढ़ता है और यह नियम सीखता है कि “अगर Skill मौजूद है, तो उसका उपयोग ज़रूर करना है”
  • इसके बाद Claude brainstorming और planning चरणों से गुजरते हुए implementation से पहले चर्चा को आगे बढ़ाता है, और काम पूरा होने पर GitHub PR बनाना या merge का सुझाव देना भी कर सकता है

Coding workflow

  • जब Claude किसी project या task की शुरुआत पहचानता है, तो वह implementation से पहले अपने आप brainstorming और planning चरण से गुजरता है
  • Git repository में काम करते समय अपने आप worktree बनाता है, ताकि parallel tasks के बीच conflict न हो
  • दो execution modes दिए गए हैं
    • पुराना तरीका: उपयोगकर्ता दूसरी Claude session खोलकर architect और implementer के बीच PM की भूमिका निभाता है
    • नया तरीका: काम को sub-agents में अलग-अलग बाँटना और हर task पर code review के बाद आगे बढ़ना
  • RED/GREEN TDD method के अनुसार failing test लिखना → minimum implementation → test pass करना, इस चक्र को दोहराया जाता है
  • implementation पूरा होने के बाद GitHub PR creation, local branch merge, या exit का विकल्प दिया जाता है

Skill system के मुख्य सिद्धांत

  • Superpowers का केंद्र Skill है, जो एक Markdown-आधारित knowledge module है जिसे Claude किसी विशेष समस्या को हल करने के लिए पढ़ और execute कर सकता है
    • Anthropic ने Office documents generation feature जारी करते समय पहली बार Skill की अवधारणा पेश की थी
    • इसी तरह के patterns Microsoft Amplifier सहित कई coding agent frameworks में भी दिखाई दिए
  • Skill वह unit है जिससे Claude नई क्षमता सीखता है; उपयोगकर्ता Claude से किताब या codebase का analysis करवाकर नई Skills extract करने को कह सकते हैं
    • agent Skill search script चलाता है, और अगर उस गतिविधि के लिए Skill है, तो उसका उपयोग अनिवार्य है
    • पहले meta-skill, “स्किल कैसे लिखें”, के माध्यम से Claude नई Skills स्वयं बना सके ऐसा workflow समर्थित है
    • यदि model से कहा जाए, “इस किताब को पढ़ो, सोचो, और जो सीखा है उसे दर्ज करो”, तो वह reusable knowledge को अपने आप संरचित कर सकता है
  • Claude बनाई गई Skills को test करने के लिए subagents का simulation करता है, और हर Skill वास्तव में प्रभावी है या नहीं, इसे TDD method से verify करता है
    • शुरुआती प्रयास में game-show quiz format से verification किया गया, लेकिन वह पर्याप्त प्रभावी नहीं था
    • बाद में “pressure test” scenarios बनाकर वास्तविक वातावरण जैसी परिस्थितियों में Skill की उपयोगिता की जाँच की गई

Pressure scenario test के उदाहरण

  • Scenario 1: समय का दबाव + आत्मविश्वास
    • स्थिति: production outage के कारण प्रति मिनट 5,000 डॉलर का नुकसान हो रहा है, और authentication service को debug करना है
    • विकल्प: तुरंत debugging शुरू करना (5 मिनट) बनाम Skill search के बाद debugging करना (7 मिनट)
    • उद्देश्य: आपात स्थिति में भी Skill search को प्राथमिकता दिलाना
  • Scenario 2: sunk cost + काम कर रहा code
    • स्थिति: 45 मिनट लगाकर बनाई गई asynchronous test infrastructure पहले से काम कर रही है
    • विकल्प: Skill check के बाद rework की संभावना (3 मिनट) बनाम मौजूदा code commit करना
    • उद्देश्य: काम करता हुआ code होने पर भी Skill compliance को अनिवार्य बनाना
  • Robert Cialdini के persuasion psychology principles (authority, commitment, liking, scarcity आदि) को LLM पर लागू किया गया
  • हाल की एक संयुक्त research, जिसमें Dan Shapiro आदि सह-लेखक हैं, ने वैज्ञानिक रूप से दिखाया कि Cialdini के principles LLMs पर भी प्रभावी हैं
  • बाद में पता चला कि Superpowers Skill system पहले से ही persuasion techniques का अवचेतन रूप से उपयोग कर रहा था
    • authority frame ("IMPORTANT: वास्तविक स्थिति"), commitment trigger ("A, B, C में से चुनें"), scarcity ("शाम 6 बजे, शाम 6:30 बजे")

Memory feature

  • Superpowers में ‘remembering-conversations’ Skill शामिल है, जिससे Claude पिछली बातचीत के context को सुरक्षित रखकर इस्तेमाल कर सकता है
  • यह Skill conversation logs को SQLite-आधारित vector database में store करता है, और Claude Haiku की मदद से summaries बनाता है
  • .claude के बाहर conversation history की automatic copy बनाकर Anthropic की auto-deletion से बचाया जाता है
  • Claude ज़रूरत पड़ने पर sub-agents के जरिए पिछली बातचीत से संबंधित जानकारी खोजता है, और इसे इस तरह डिज़ाइन किया गया है कि अनावश्यक खोज से context window दूषित न हो
  • अभी पूरा wiring पूरा नहीं हुआ है, लेकिन सभी components पहले से implement किए जा चुके हैं

Sharing feature

  • Superpowers का लक्ष्य Skills sharing ecosystem बनाना है
  • उपयोगकर्ता अपने Claude द्वारा सीखी गई Skills को GitHub Pull Request के रूप में submit करके दूसरे उपयोगकर्ताओं के साथ साझा कर सकते हैं
  • नए Claude plugin system के साथ integrate करते हुए भी, user consent के बिना Skills share न हों, इसके लिए safeguards रखे गए हैं
  • शुरुआती installation method सिर्फ Claude से एक खास URL पढ़वाने का था, लेकिन अब इसे plugin marketplace structure में बदल दिया गया है

Installation और उपयोग

  • Claude Code 2.0.13 या उससे ऊपर आवश्यक है
  • plugin marketplace में installation commands चलाएँ
    • /plugin marketplace add obra/superpowers-marketplace
    • /plugin install superpowers@superpowers-marketplace
  • restart के बाद bootstrap prompt inject होता है और Skill system अपने आप सक्रिय हो जाता है
  • Claude और Superpowers के साथ एक वास्तविक Todo app को implement करने का पूरा log भी प्रकाशित किया गया है, जहाँ Claude के सवाल, test-driven development, और git management की प्रक्रिया देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-13
Hacker News टिप्पणियाँ

  • मैं इस लेख की बहुत ज़ोरदार सिफारिश करना चाहता हूँ। Jesse इन टूल्स का इस्तेमाल जिस तरह करता है, वह दूसरों की तुलना में कहीं ज़्यादा साहसी है। उसका Superpowers GitHub रिपॉज़िटरी भी ज़रूर देखना चाहिए। मैंने भी कल रात इस विषय पर कुछ नोट्स लिखे थे: यह लिंक देखें

    • बड़े वास्तविक codebase में coding performance के संदर्भ में, "Research -> Plan -> Implement" तरीके और [Advanced Context Engineering from Agents] वीडियो के prompts की तुलना में यह approach कैसे अलग है, यह जानने की उत्सुकता है। agent की क्षमता बढ़ाने के लिए skills जोड़ना उपयोगी लगता है, लेकिन यह असली development के लिए कितना उपयुक्त है, इस पर मुझे संदेह है। तरह-तरह की skills को अपने-आप जोड़ने का विचार या package collection अच्छा है, लेकिन यह custom commands + sub-agent approach से कितना बेहतर है, इस पर भरोसा नहीं है। मैं कुछ दिनों तक खुद इसे आज़माकर तुलना करने वाला हूँ

    • यह लगभग Elixir के usage rules को agent behavior पर लागू करने जैसा लगता है, फिलहाल Claude के लिए। usage_rules reference भी साथ में देखना उपयोगी होगा

  • यह लेख पढ़ते हुए मुझे उम्मीद हुई थी कि इसमें "coding agents के साथ काम को बेहतर कैसे करें" जैसी बात मिलेगी। मैंने 2 साल तक AI के साथ प्रयोग किया है, और अब मुझे यक़ीन है कि यह toy classifier से आगे बढ़कर काफ़ी उपयोगी utility बन चुका है। फिर भी, सीमाओं से बार-बार टकराने के कारण मुझे उल्टा यह महसूस होने लगा है कि pre-LLM तरीक़े ज़्यादा robust, तेज़ और मानसिक रूप से टिकाऊ हैं। क्या कोई ऐसे ठोस उदाहरण साझा कर सकता है जहाँ LLM ने वास्तव में state-of-the-art development practice या value creation को विस्तार दिया हो

    • आज सुबह आया Mitchell का लेख recommend करता हूँ: non-trivial vibing पोस्ट

    • मुझे अभी भी लगता है कि हम experimental phase में हैं। सही measurement metrics जल्द सामने आएँगे

  • इस तरह का prompting approach, जहाँ किसी घातक स्थिति की कल्पना करवाकर "emotional" reaction निकालने की कोशिश की जाती है, अब लगभग पुराना हो चुका है। एक समय था जब IMPORTANT जैसे शब्दों को uppercase में लिखने से फ़ायदा होता था, लेकिन हाल के models बस निर्देशों का पालन करते हैं। ऐसे prompts लिखने और maintain करने में मेहनत करने की ज़रूरत नहीं है

    • उसने जिस persuasion paper का ज़िक्र किया है, वह भी वास्तव में उसकी बात से बिल्कुल संबंधित नहीं है। वह paper सिर्फ़ यह बताता है कि "trained safety" के कारण आने वाली refusals को persuasion prompts से कैसे पार किया जा सकता है, prompt adherence सुधारने से उसका कोई संबंध नहीं है

    • परेशान करने वाली बात यह है कि llms भी इस मामले में अभी खुद evolve नहीं हुए हैं। अगर llm से ही कहा जाए कि अपना prompt बेहतर बनाए, तो वह ऐसे ही सुधार सुझाता है। llm और agents के साथ सहयोग करते समय सबसे निराशाजनक बात यह लगती है कि self-referential capability में वे हमेशा लगभग एक पीढ़ी पीछे रहते हैं

  • पहले पेज पर यह देखकर मैं तुरंत चिढ़ गया

    @/Users/jesse/.claude/plugins/cache/Superpowers/...

    XDG spec को आए दशकों हो चुके हैं, फिर भी नए apps मेरे HOME को गंदा क्यों करते रहते हैं, समझ नहीं आता। और असली data का cache/ के नीचे रखा जाना भी अजीब है, लेकिन चलिए फिलहाल उसे छोड़ देते हैं

    • cache location में होने का कारण यह है कि वह फ़ाइल GitHub repository से install किए गए plugin की copy है। यानी वह असली source file नहीं है

  • test-driven development skill document जैसे दस्तावेज़ इंसानों के पढ़ने के लिए बहुत भ्रमित करने वाले हैं। इस project में इस्तेमाल होने वाले "skills" का कोई consistent format नहीं है, और वे ऐसे लगते हैं मानो बस LLM से कहा गया हो, "X को step-by-step समझाने वाला एक Markdown document लिखो", और जो output आया उसे रख दिया गया हो, जो कि blog के मुताबिक़ सच भी है। अगर LLM ने पहले ही TDD पर 100 किताबों जितना सीखा हुआ है, तो उसे यह उलझा हुआ summary फिर से देने की ज़रूरत क्या है, यह सवाल बनता है। इस तरह के projects मानते हैं कि वे LLM को किसी तरह की "superpower" दे रहे हैं, लेकिन LLM कोई self-learning इकाई नहीं है, इसलिए prompt के आगे कुछ जादुई वाक्य चिपका देने से वह 10 गुना ज़्यादा बुद्धिमान नहीं हो जाता। हाँ, अगर काम बार-बार दोहराया जाता हो, तो मैं अपनी constraints पहले से लिखकर prompt के आगे paste कर सकता हूँ, लेकिन यह बस context देना है। LLM को कोई नई क्षमता नहीं मिली, उसे सिर्फ़ context दिया गया। ऐसी पोस्ट्स में हमेशा जो कमी लगती है, वह यह है कि "तुम्हारे पास X skill है" जैसा prompt देने से, बिना ऐसा कुछ कहे सीधे काम कराने की तुलना में, वस्तुनिष्ठ रूप से कितना बेहतर परिणाम मिलता है, इसके असली उदाहरण बहुत कम दिखते हैं

    • पूरी तरह सहमत हूँ। कुछ हफ्तों तक codex और GPT Pro (5o-codex-high) के साथ काम करने के बाद मैं इस निष्कर्ष पर पहुँचा हूँ कि आखिरकार सबसे महत्वपूर्ण चीज़ context ही है। मेरे लिए सबसे उपयोगी चीज़ें थीं: voice input को Whisper से लेकर LLM को देना, token usage को कुशलता से manage करना और ज़रूरत पड़ने पर बातचीत को reset कर देना, और यह जाँचने के लिए स्पष्ट मानदंड बनाना कि काम सच में पूरा हुआ है या नहीं, जैसे API या playwright tests जैसी AI-Unit-Tests। सभी files को Markdown में manage करना भी एक तरीका है। और हर specialized task के लिए अलग AI chat रखना, परिणामों के लिहाज़ से कहीं ज़्यादा efficient है, मॉडल की गणितीय संरचना के कारण इसमें काफ़ी फ़र्क पड़ता है। इस approach की वजह से PM की भूमिका निभाते हुए भी मैं LLM से उन चीज़ों की दोबारा समीक्षा कराने में resource waste कम कर सका जिन्हें वह पहले ही सीख चुका था। लेकिन फिर दोबारा Claude जैसे vendor lock-in की ओर लौटना क्यों चाहिए, यह समझ नहीं आता। 5o-codex-high कहीं ज़्यादा शक्तिशाली है, तुलना ही नहीं है। फिर भी, एक उपयोगी बात यह है कि AI को AI के साथ collaborate करवाना वास्तव में असरदार हो सकता है। roles को अच्छी तरह बाँटना महत्वपूर्ण है

  • जब वह कहता है, “मुझे समझ आया कि Robert Cialdini की किताब Influence से सीखे गए persuasion principles LLM पर भी लागू होते हैं, और यह देखकर खुशी हुई कि वे सच में काम करते हैं,” तो सच कहूँ तो मुझे लगता है अब बस भी करो। यह कुछ अजीब सा लगने लगता है, और दिशा AI और development से भी आगे कहीं निकल जाती दिखती है। मैं मानता हूँ कि AI coding एक क्रांतिकारी बदलाव है, लेकिन इसका मतलब यह नहीं कि सब कुछ उलट गया है। बुनियादी structure और design अब भी ज़रूरी हैं। लेकिन इस लेख में सब कुछ किसी जादुई कहानी जैसा लगता है

    • "जादुई" जैसा लगने वाली बात पर, हो सकता है कि मामला पूरी तरह वैसा न हो। AI को किसी समाधान तक पहुँचने के लिए उपयोगकर्ता की मंशा और लक्ष्य को vector में बदलना पड़ता है, और अगर AI ने मानव persuasion से जुड़ी सामग्री पर्याप्त मात्रा में सीखी है, तो स्वाभाविक है कि वह ऐसी अभिव्यक्तियों के तत्वों का पालन कर सके। बेशक, परिणाम बहुत अलग-अलग हो सकते हैं। जैसे इंसान भी rhetoric या बनावटी pose को ज़बरदस्ती इस्तेमाल करे तो उल्टा मूर्ख लग सकता है, वैसे ही केवल uppercase या अत्यधिक विशेषण भर देने से इरादा-vector हमेशा सही ढंग से नहीं उभरता। फिर भी, जब मनचाहा परिणाम नहीं मिलता, तब prompt में persuasion elements, जैसे authority, की कमी है या नहीं, यह जाँचना और ज़रूरत हो तो उन्हें जोड़ना आज़माने लायक है

    • सच तो यह है कि यह सब हमेशा से ऐसा ही रहा है। "AI" शब्द खुद ऐसा है, और OpenAI के पिछले 5 सालों के घोषणापत्र भी ज़्यादातर ऐसे ही रहे हैं। सुनने में लगता है मानो दुनिया बदल जाएगी, लेकिन वास्तव में उनमें अक्सर अतिशयोक्ति या तकनीकी rhetoric भरी होती है। ज़्यादातर चीज़ें सिर्फ़ अनावश्यक noise होती हैं, और कभी-कभी ही कोई सचमुच उपयोगी जानकारी मिलती है जिसे मैं अपने workflow में लागू करता हूँ। अधिकतर लेखों में काम की जानकारी से ज़्यादा बढ़ा-चढ़ाकर कही गई बातें और दिखावा होता है

  • EXTREMELY_IMPORTANT, RIGHT NOW जैसे निर्देशों को देखकर मुझे असहजता होती है। डर यह है कि इस तरह लिखते-लिखते एक समय ऐसा आएगा जब यह मेरी वास्तविक प्राथमिकताओं से टकराने लगेगा। हर चीज़ सबसे महत्वपूर्ण पहली प्राथमिकता नहीं हो सकती

    • यह bashrc file manage करने जैसा है। कभी-कभी उसे हाथ से edit भी करना पड़ता है

    • क्या आजकल llm खुद उल्टा यह सलाह नहीं देते कि ऐसी command शैली का इस्तेमाल न करो?

  • लेख में code examples बिल्कुल नज़र नहीं आते। यह जानना चाहूँगा कि practical usage examples कहाँ देखे जा सकते हैं

  • इस तरह के blog posts कहीं ज़्यादा उपयोगी होते अगर वे यह दिखाते कि वास्तव में किसी ने इस tool का इस्तेमाल करके कोई non-trivial चीज़ बनाई है। उदाहरण के लिए, क्या Claude को किताब पढ़ाकर सच में नई skill सिखाई गई, या वह सिर्फ़ ऐसे prompt पर प्रतिक्रिया दे रहा है जो उसे वैसा व्यवहार करने को कहता है, यह समझना मुश्किल है। इसलिए मेरा मानना है कि Claude को नई skill देने के बाद और सिर्फ़ prompt देने के बाद, दोनों का demo होना चाहिए। हो सकता है मेरा रुख़ कुछ conservative हो, लेकिन इस तरह के ज़्यादातर blogs marketing material जैसे लगते हैं, जहाँ महत्वपूर्ण बातें छोड़ दी जाती हैं या ठीक से समझाई नहीं जातीं, इसलिए वे अपने काम को बढ़ा-चढ़ाकर पेश करने जैसे लगते हैं

    • आज ही इस पर एक संबंधित उदाहरण आया है: non-trivial vibing लेख

    • LLM का लंबे समय तक जटिल project coding में वास्तविक उपयोग करना सच में बहुत कठिन है! सिर्फ़ requirements define करना भी सोच से कहीं ज़्यादा मुश्किल है, और LLM ग़लत दिशा में भी बहुत तेज़ी से बढ़ जाता है

    • इस क्षेत्र में ज़रूरी methodology वह है जो A/B testing जैसे quantified metrics के साथ experiments करके tool की effectiveness साबित करे। और वह भी सिर्फ़ एक बार नहीं, बल्कि अलग-अलग scenarios में बार-बार analysis करके, ताकि statistical reliability हो। coding agents का इस्तेमाल करते समय सबसे मुश्किल बात यह है कि छोटे और सरल codebase में शुरुआत में वे अच्छे लगते हैं, लेकिन जैसे-जैसे codebase बड़ा होता है और complexity बढ़ती है, वैसे-वैसे जटिल connections वाले कामों में वे "tunnel vision" में फँसकर technical debt बढ़ाने लगते हैं

    • मुझे तो लगता है बस Claude के code को सीधे इस्तेमाल करके हर किसी को अपना निष्कर्ष खुद निकाल लेना चाहिए

    • "इनमें से ज़्यादातर blogs हमेशा की तरह IT industry के उसी पुराने पैटर्न का हिस्सा हैं, जहाँ details छोड़ दी जाती हैं और लोग अपनी क्षमता को बढ़ा-चढ़ाकर दिखाते हैं।" सच कहूँ तो IT की हर पीढ़ी में यह हमेशा से रहा है

  • कभी-कभी AI द्वारा generated code पर अचानक copyright license जोड़ दिया जाता है, और समझ नहीं आता क्यों। MIT license है तो कम से कम ठीक है, लेकिन AI-generated output क़ानूनी रूप से copyright के दायरे में नहीं आता, इसलिए कोई भी license को नज़रअंदाज़ करके उसका उपयोग कर सकता है। समझ नहीं आता फिर इसे जोड़ा ही क्यों जाता है