Superpowers से Claude Code सुधरता है, पर एक असली कीमत है

Superpowers Claude Code के लिए एक plugin है, जिसे Jesse Vincent ने लिखा है, जो 1990 के दशक से open source developer tools बनाते आ रहे हैं। उन्होंने इसे अक्टूबर में release किया, और साल भर से कम में repository पर 280,000 stars और 25,000 forks हैं, और आख़िरी push हमारी recording से दो दिन पहले आया। project अभी से अपने छठे major version पर है, main branch पर 681 commits के साथ, तो ये कोई ऐसा prompt collection नहीं है जिसे launch के उछाल के बाद छोड़ दिया गया हो।

Signal	Value
GitHub stars	280,000
Forks	25,000
Major version	6
main पर commits	681
Open issues	125

Vincent का दांव एक लाइन में समा जाता है: coding agents में कमी capability की नहीं, discipline की है। वो discipline सादी markdown files के रूप में आती है, जिन्हें कोई भी पढ़, fork और adapt कर सकता है। हमने plugin install किया, सभी 14 skills लाइन-दर-लाइन पढ़ीं, और देखा कि ये चार मोर्चों पर क्या बदलता है: productivity, code reliability, token खर्च और documentation।

Superpowers Claude Code के लिए एक फ़्री, open source plugin है। ये Anthropic के official plugin marketplace पर मौजूद है और एक ही command से install होता है। यही methodology दर्जन भर से ज़्यादा दूसरे harnesses के लिए भी उपलब्ध है, जिनमें Cursor, Codex और Gemini शामिल हैं, हर एक का अपना install path।

core हैं 14 skills: markdown instruction files, जिन्हें agent तब load करता है जब कोई situation उनसे match करे। Brainstorming, plan writing, subagent-driven development, test-driven development और systematic debugging, हर एक काम करने का एक पूरा तरीक़ा encode करती है, अपनी checklists और guardrails के साथ। debugging वाली skill root cause अलग किए बिना fix सुझाने से मना करती है। एक verification skill agent से साबित करवाती है कि काम पूरा हुआ, सिर्फ़ दावा करने की जगह। हर skill load होते ही अपना नाम बताती है, तो आपको हमेशा पता रहता है कि agent किस mode में काम कर रहा है।

session शुरू होते ही एक hook Claude को मजबूर करता है कि हर task से पहले check करे कि इनमें से कोई skill लागू होती है या नहीं। नियम entry skill में लिखा है: अगर skill relevant होने का एक percent chance भी हो, तो agent को उसे load करना ही है। नतीजा toolbox कम और agent में inject की गई development methodology ज़्यादा लगता है।

Vincent अपने blog पर इसकी शुरुआत बताते हैं। उन्होंने ये skills 2,249 markdown files को खंगालकर बनाईं, जिनमें उनके अपने agents के सीखे सबक़ थे, फिर drafts को उन्हीं archives के सामने pressure test किया। methodology theory से नहीं लिखी गई, बल्कि असली agent failures से निकाली गई।

Brainstorming वो skill है जिससे सब कुछ गुज़रता है। जिस पल आप कोई feature माँगते हैं, Claude इसे load करता है और framing बातचीत भर के लिए requirements expert बन जाता है। पूरा method एक readable file में समा जाता है।

file एक hard gate से खुलती है: न code, न scaffolding, किसी भी तरह की implementation skill नहीं, जब तक आप एक explicit intent approve न कर दें। अंदाज़े पर कुछ नहीं बनता, और gate हर task पर लागू होता है, चाहे वो कितना भी छोटा लगे। फिर skill हर request को तीन paths में से एक में छाँटती है।

Path	परिभाषा	Output
Spike	एक feasibility सवाल	एक जवाब, रखने वाला code नहीं
Bounded	repo में पहले से मौजूद किसी flow में छोटा बदलाव	एक scoped बदलाव
Architectural	ऐसा कुछ भी जो project की बनावट को नए ढंग से जोड़े	एक spec जिसे आप validate करते हैं, फिर एक implementation plan

agent अपनी classification खुलकर बताता है ताकि आप उसे override कर सकें, और ये ratchet एक ही दिशा में घूमता है: task के बीच में मिली छिपी complexity path को upgrade करती है, कभी उल्टा नहीं। file में red flags की एक table है, "ये design के लिए बहुत आसान है" जैसे ख़याल, और ठीक बगल में उनका जवाब: आसान tasks में ही बिना जाँची assumptions सबसे भारी पड़ती हैं। spike भी अपना guardrail रखता है। सवाल का जवाब देने के लिए agent जो भी बनाए, वो throwaway ही label रहता है, और उस code को रखना classify करने के लिए एक नई request बन जाती है।

बातचीत के दौरान agent वो सवाल पूछता है जो एक lead engineer पूछेगा, और अपना design समझने लायक हिस्सों में रखता है। हमारी अपनी pipeline पर इस phase ने पहले ही ऐसे features रोक दिए हैं जो हम बेकार में बना बैठते।

plan लिखने वाली skill एक ऐसी instruction से खुलती है जो उसका tone तय कर देती है: plan ऐसे skilled developer के लिए लिखो जिसे आपके codebase का zero context है, और file के अपने शब्दों में, questionable taste।

ठोस तौर पर, काम ऐसे tasks में कटता है जहाँ हर step दो से पाँच मिनट का है: failing test लिखो, चलाकर पक्का करो कि वो fail होता है, minimal code लिखो जो उसे pass करे, tests फिर चलाओ, commit करो। एक action, एक verification, और काम लगातार commits में आगे बढ़ता है। ये test-driven development cycle है, जिसे plugin की एक और skill लागू करती है, तो हर task का अपना test cycle होता है।

हर task बनाने या छूने वाली exact files बताता है, line number तक। plan एक mandatory header से खुलता है: goal एक लाइन में, architecture दो या तीन में, tech stack, spec का link, और project की global constraints शब्द-दर-शब्द copy। अगर spec कई independent subsystems कवर करती है, तो skill अलग-अलग plans माँगती है, हर subsystem का एक, हर एक से ऐसा software निकले जो अकेले testable हो।

task sizing reliability वाले तर्क का दिल है। छोटा task मतलब ऐसा agent जो अपना काम ऐसी context window के साथ ख़त्म करता है जो अभी भी ज़्यादातर खाली है। वो उस पल तक कभी नहीं पहुँचता जब session overflow होता है, agent धागा खो देता है और ऐसे functions गढ़ने लगता है जो मौजूद ही नहीं। कोई पाँच मिनट की demo ये दिक़्क़त नहीं दिखाती, पर असली project पर यही सब कुछ तय करती है: session के आख़िर में agent की quality का पहले prompt वाली quality से कोई लेना-देना नहीं। कम भरा context मतलब अपने आप कम hallucinations, और ऐसा code जो वही करे जो plan ने कहा।

execution के वक़्त एक dedicated skill काम को git worktree में isolate करती है, जो repository की एक अलग working copy है, ताकि plan चले और बगल में आप जो कर रहे हैं उसमें दख़ल न दे।

execute करने वाली skill development को subagents से चलाती है। उसका principle file की एक लाइन में है: हर task पर नया subagent, हर task के बाद review, और आख़िर में पूरी branch का broad review। आपका main session orchestrator बन जाता है। वो अब code नहीं करता, dispatch करता है। हर subagent को ठीक वही context मिलता है जो उसके task को चाहिए, आपकी session की history कभी नहीं, जिससे context pollution नहीं होती और आपकी अपनी window coordination के लिए खाली रहती है।

subagent शुरू करने से पहले सवाल पूछ सकता है, फिर implement, test, commit करता है और अपने काम का review भी। काम पूरा होने पर orchestrator दो हिस्सों में review चलाता है, पहले spec compliance और फिर code quality, हर task के लिए एक dedicated reviewer seat के साथ। कुछ भी improvised नहीं: skill हर role के लिए template prompt देती है (implementer, task reviewer, और वो reviewer जो fixes दोबारा जाँचता है), जिन्हें orchestrator task के context से भरता है।

Review का नतीजा	क्या होता है
Pass	orchestrator ledger में completion लिखता है और plan में आगे बढ़ता है
Fail, round 1 से 3	original implementer ही दोबारा लगता है, क्योंकि वो code और अपने फ़ैसले पहले से जानता है
Fail, round 4	ज़्यादा capable model पर एक नया implementer dispatch होता है
Fail, round 5	breaker trip हो जाता है और orchestrator हर खुली finding पर ख़ुद फ़ैसला देता है

skill उल्टी ज़्यादती से भी बचती है: छोटे mechanical tasks का झुंड एक grouped dispatch के रूप में जाता है और एक unit की तरह review होता है। बिना reviewer से गुज़रे कुछ भी merge नहीं होता। नतीजा वो है जिसे इंसानी team code review process कहती है, बस ये अपने आप चलता है, task के बाद task।

dispatch system तीसरी जीत का रास्ता खोलता है: token economics। skill में एक model selection section है जो एक नियम से शुरू होता है: सबसे कम powerful model लो जो उस role को संभाल सके। orchestrator plan के हर task की difficulty आँकता है और उसके हिसाब से model देता है।

Task	Model tier
एक-दो files वाला well-specified mechanical task, या ऐसा plan जिसमें लिखने वाला code पहले से हो	सबसे सस्ता tier (implementation बस transcription और testing बन जाती है)
कई files में coordination, debugging	एक standard model
Architecture, final branch review	उपलब्ध सबसे capable model

file दो बारीकियाँ जोड़ती है। पहली, dispatch करते वक़्त model का नाम हमेशा explicit लिखो: बिना नाम वाला subagent आपके session का model inherit करता है, अक्सर सबसे महँगा, जो चुपचाप पूरे section को बेकार कर देता है। दूसरी, turn count token price पर भारी है। सबसे सस्ते models कई steps वाले काम पर ज़्यादा turns लेते हैं और कुल मिलाकर ज़्यादा महँगे पड़ते हैं, इसीलिए reviewers और prose से काम करने वाले implementers को bargain bin की जगह एक tier ऊपर का floor मिलता है।

ये setup एक अजीब-सी लगने वाली चीज़ मुमकिन करता है: Opus या Fable, catalog के सबसे महँगे models, 20 dollar वाले Pro plan पर चलाना। महँगा model बस उन चंद फ़ैसलों पर लगता है जो उसके लायक हैं, और बाक़ी plan ऐसे models पर चलता है जो आपके quota का अंश भर खाते हैं।

आख़िरी जीत वो है जिसके बारे में plugin install करते वक़्त कोई नहीं सोचता। specs और plans chat messages नहीं हैं जो session ख़त्म होने पर ग़ायब हो जाएँ। ये markdown files हैं जो repository के अंदर save होती हैं और काम के साथ ही commit होती हैं। skill जगह भी तय करती है: एक dated plans folder, हर feature की एक file, जिसके header में goal, architecture और spec का link है।

spec plan के साथ चलती है, और दोनों के बीच टकराव spec के पक्ष में सुलझता है: authority document है, agent की memory नहीं। git history अब सिर्फ़ ये नहीं बताती कि क्या बदला। ये बताती है क्यों, और agent ने उस वक़्त क्या तय किया था। छह महीने बाद prompt में plan file का ज़िक्र करने से agent original feature का context फिर से पकड़ लेता है, और उसी subsystem को छूने वाला नया feature मौजूदा spec पर बनता है, ज़मीन दोबारा खोजने की जगह।

अब कोई untracked task रह ही नहीं जाता: agent ने codebase पर जो भी किया, उसका एक document पीछे छूटा, पहले brainstorm से आख़िरी commit तक। project अपना दर्शन दो principles में समेटता है, ad hoc से ऊपर systematic और दावों से ऊपर evidence। documentation process से अपने आप निकलती है।

limit असली है और repository इसका प्रचार नहीं करता: इस पूरी discipline की एक fixed cost है, और वो cost कभी बंद नहीं होती। entry skill दो-टूक है। ज़रा-सा शक हो तो agent को skill load करनी ही है, और brainstorming file साफ़ कहती है कि ceremony task के हिसाब से बढ़ती है, पर इंसानी approval कभी नहीं।

दो लाइन के fix पर इसका मतलब है framing सवालों के जवाब देना, दो लाइन का design approve करना, फिर fix देखने से पहले पूरे cycle का इंतज़ार। config file में एक typo के लिए पूरा process ख़ुद ठीक करने से बस धीमा है। orchestration ख़ुद भी tokens खाती है: dispatch briefs, हर task पर दो reviews और ledger, ये हर एक बार चुकाए जाते हैं, और सबसे छोटे tasks पर ये सबसे ज़्यादा महसूस होता है।

एक उल्टा लक्षण भी है, और ये Reddit वाले सवाल का सीधा जवाब है। अगर आपके usage stats में plugin कुछ ही percent पर दिखे, तो आपकी requests skills को शायद ही कभी trigger करती हैं, यानी आप हर session entry check चुका रहे हैं, फ़ायदा छुए बिना। पूरे पाँच rounds चलने वाला fix loop मतलब पाँच diffs, पाँच और reviews और एक arbitration, उस task पर जो मिनटों में होना था। project कभी ठहरता भी नहीं: ये साल भर से कम में पहले version से छठे तक पहुँचा और अब भी 125 open issues हैं, तो आज पढ़ी skills अगले update तक बदल चुकी होंगी।

plugin अपना exit ख़ुद plan करता है। इसकी instructions आपके directives को skills से ऊपर रखती हैं, तो आप agent को साफ़ कह सकते हैं कि process skip करो। हमारा नियम: किसी भी feature work पर Superpowers by default on, और छोटे fixes पर जानबूझकर skip।

आपका Claude Code usage	Verdict
घंटों वाले features	install करें: framing आपको ग़लत चीज़ बनाने से रोकती है, छोटे tasks agent को context saturation से दूर रखते हैं, model selection quota को खींचती है, और आपको वो documentation मिलती है जो आप ख़ुद कभी न लिखते
Throwaway scripts और छोटे fixes	छोड़ दें: आप process की fixed cost उन tasks पर चुकाएँगे जिन्हें उसकी ज़रूरत ही नहीं
बीच में	install करें और skip कहना सीखें: prompt में एक लाइन control आपके हाथ में वापस दे देती है

अगर आप सब कुछ अपनाए बिना test करना चाहें, तो कुछ दिन सिर्फ़ brainstorming skill चलने दें। ज़्यादातर फ़ायदा उसी में है, और बाक़ी skills उसके बाद अपने आप जुड़ जाती हैं। plugin अपने चारों वादे निभाता है, बशर्ते आप उसे ceremony के लायक features दें। ये अब हमारे अपने projects पर चलता है, और brainstorming phase वो है जिसे हम अब बंद नहीं करेंगे। repository फ़्री और open source है, और आपके आगे 280,000 लोग लाइन में हैं।