Claude Code के लिए Superpowers: निर्णय तालिका, sources, checklist और आगे की गाइड

TL;DR

• Superpowers एक toolbox नहीं, एक process है: चौदह markdown skills जो हर feature को brainstorming session, लिखित plan और नए subagents की एक श्रृंखला से गुज़ारती हैं, और हर एक का review होता है।
• इसे install करें अगर आपके Claude Code sessions ऐसे features बनाते हैं जिनमें घंटों लगते हैं। छोड़ दें अगर आपका उपयोग throwaway scripts और दो-लाइन के fixes तक सीमित है: entry check हर task पर चलता है और कभी बंद नहीं होता।
• Token वाला तर्क असली है, लेकिन वह एक skill के एक ही हिस्से से आता है: Model Selection। Orchestrator हर भूमिका को वह सबसे सस्ता model देता है जो उसे संभाल सके, इसलिए महंगा model सिर्फ architecture और आख़िरी branch review को छूता है।
• Repo स्वस्थ है: 280,597 stars, 25,138 forks, main पर 681 commits, 2026-08-12 को release v6.3.0, और 2025-10-09 को बना।
• जिस शिकायत से video शुरू हुआ, usage stats का 1 से 3 percent होना, वह bug नहीं है: इसका मतलब है कि skills आपके काम पर कभी trigger नहीं होतीं, यानी आप gate का दाम चुकाते हैं और बदले में कुछ नहीं पाते।
• बीच का रास्ता आपके prompt में एक वाक्य है: agent से कहें कि छोटे fixes पर process छोड़ दे, और बाक़ी अपनाने से पहले कुछ दिन सिर्फ़ brainstorming चलने दें।

Sources क्या कहते हैं

Repository के आँकड़े 2026-09-02 को पढ़े गए: 280,597 stars, 25,138 forks और main branch पर 681 commits, main पर आख़िरी commit 2026-08-12 (v6.3.0) का और 2026-08-31 को एक non-main branch पर बाद का push s1। उस दिन Issues tab में 125 open issues दिखे; API का 350 वाला आँकड़ा 225 open pull requests को भी गिनता है, इसलिए दूसरे plugins से तुलना करते समय tab का आँकड़ा बताएँ, API का नहीं s6। Project 2025-10-09 को बना और चौदह skills के साथ आता है s2। Author की launch post इस दाँव को एक पंक्ति में समझाती है: coding agents में क्षमता की कमी नहीं, अनुशासन की कमी है, और वह अनुशासन साधारण markdown files के रूप में बाँटा जा सकता है जिन्हें कोई भी पढ़, fork और edit कर सकता है s5। Plugin आधिकारिक marketplace पर listed है, इसलिए installation एक ही command है और updates marketplace के साथ चलते हैं s4।

Entry point एक skill है जिसे session-start hook बाक़ी सब से पहले load करता है। वह agent को बताती है कि अगर यह शक भी हो कि कोई skill लागू होती है या नहीं, तो उसे load करके जाँचना होगा, जवाब देने या code लिखने से पहले। यही नियम फ़ायदे और स्थायी लागत दोनों का स्रोत है s14।

Brainstorming एक HARD-GATE से शुरू होती है: जब तक आप स्पष्ट intent को validate नहीं करते, कोई code, कोई scaffolding, कोई implementation skill नहीं। फिर request तीन रास्तों में से एक में छाँटी जाती है: spike, जब output code नहीं बल्कि एक जवाब हो; bounded, repo में पहले से मौजूद flow के भीतर छोटे बदलाव के लिए; architectural, उस हर चीज़ के लिए जो project को नया आकार दे। Agent वर्गीकरण की घोषणा करता है ताकि आप उसे काट सकें, और ratchet एक ही दिशा में चलता है: task के बीच मिली छिपी जटिलता रास्ते को ऊपर ले जाती है, कभी नीचे नहीं s9।

Plan लिखने वाली skill ऐसा plan माँगती है जो एक सक्षम developer के लिए लिखा गया हो जिसे आपके codebase का कोई संदर्भ नहीं और, file के अपने शब्दों में, संदिग्ध पसंद है। काम ऐसे tasks में कटा होता है जिनका हर step दो से पाँच मिनट का है: failing test लिखो, चलाकर fail होते देखो, न्यूनतम code लिखो, tests फिर चलाओ, commit करो। हर task बनाई या बदली जाने वाली सटीक files गिनाता है, line numbers तक, और plan एक अनिवार्य header से खुलता है s10।

Execution subagent-driven development skill है: हर task के लिए एक नया subagent, हर task के बाद review, और अंत में पूरे branch का review। मुख्य session code लिखना बंद करके dispatch करता है। हर subagent को सिर्फ़ अपने task का संदर्भ मिलता है, आपकी session history कभी नहीं, जिससे आपकी अपनी window coordination के लिए खाली रहती है। Subagent के implement, test, commit और self-review करने के बाद orchestrator दो-भाग का review चलाता है, पहले spec compliance, फिर code quality, और हर task के लिए एक reviewer की सीट आरक्षित रहती है। File हर task पर loop को अधिकतम पाँच rounds तक सीमित करती है s11। काम का isolation खुद एक worktree skill को सौंपा गया है, इसलिए plan कभी आपके मौजूदा checkout पर नहीं चलता s13।

Model Selection वाला हिस्सा एक नियम से शुरू होता है: वह सबसे कम सक्षम model इस्तेमाल करें जो भूमिका संभाल सके। एक-दो files को छूने वाला अच्छी तरह specified mechanical task छोटे model को जाता है; जब plan में लिखने वाला code पहले से मौजूद हो, तो implementation सिर्फ़ transcription और tests है, इसलिए सबसे सस्ता tier काफ़ी है। कई files का coordination और debugging standard model को जाते हैं। Architecture और आख़िरी branch review उपलब्ध सबसे सक्षम model माँगते हैं। व्यवहार में दो बातें मायने रखती हैं: dispatch पर model का नाम हमेशा स्पष्ट लिखें, और चुनने से पहले orchestrator को हर task की कठिनाई आँकने दें s12। यही वह तंत्र है जो बीस डॉलर के Pro plan पर महंगे model को वहन-योग्य बनाता है: वह सिर्फ़ उन फ़ैसलों पर काम करता है जो इसके लायक हैं।

Documentation का फ़ायदा process का साइड इफ़ेक्ट है। Specs और plans ऐसे chat messages नहीं जो ग़ायब हो जाएँ; वे repo में सहेजी और काम के साथ commit की गई markdown files हैं, इसलिए बाद में reviewer पढ़ता है कि बदलाव क्यों किया गया, सिर्फ़ यह नहीं कि क्या बदला s3।

लागत वही है जिसका repo विज्ञापन नहीं करता। जिस thread ने video को शुरू किया वह usage stats का 1 से 3 percent होना बताता है और पूछता है कि इस्तेमाल न करने के अलावा नुक़सान क्या है s7। Files में जवाब यह है कि brainstorming अपनी औपचारिकता को task के हिसाब से घटाती-बढ़ाती है लेकिन इंसानी validation कभी नहीं छोड़ती s9। दो-लाइन के fix पर भी आप framing सवालों के जवाब देते हैं, दो वाक्य के design को मंज़ूर करते हैं और पूरे चक्र का इंतज़ार करते हैं। Dispatch briefs, हर task पर दो reviews और tracking ledger वे tokens हैं जो आप हर बार चुकाते हैं, और यह सबसे छोटे tasks पर साफ़ दिखता है। कम usage stats का मतलब है कि skills आपके काम से मेल नहीं खा रहीं, और पढ़ने लायक असली संकेत यही है।

Usage के अनुसार निर्णय

सोमवार को यह करें

• आधिकारिक marketplace से install करें और plugin cache खोलें: चौदहों SKILL.md files एक बार पढ़ें, वे छोटी हैं और वही पूरा product हैं।
• एक असली feature को gate से शुरू से अंत तक चलाएँ: brainstorming, plan, subagent dispatch, branch review। Process को उसी पर परखें, किसी fix पर नहीं।
• एक हफ़्ते बाद अपने usage stats देखें। कुछ percent से नीचे हों तो skills आपके काम से मेल नहीं खा रहीं: या तो आपके tasks बहुत छोटे हैं या आपको requests को features की तरह लिखना होगा।
• अपने project instructions में एक skip नियम जोड़ें: कुछ लाइनों से छोटे single-file fixes पर सीधे बदलाव पर जाएँ, brainstorming नहीं।
• Plugin छोड़ भी दें तो Model Selection की सीढ़ी अपने subagent prompts में कॉपी करें: हर dispatch पर model का नाम स्पष्ट लिखें।
• Plugin जो specs और plans लिखता है उन्हें मिटाने के बजाय commit करें; वही आपका design record हैं।
• किसी दूसरे plugin से तुलना करने से पहले open issues Issues tab से गिनें, API के आँकड़े से नहीं।

आगे बढ़ें

• Skill files से पहले design की मंशा के लिए launch post पढ़ें: वह बताती है कि अनुशासन code के बजाय markdown के रूप में क्यों बाँटा गया s5।
• README का philosophy हिस्सा method का छोटा रूप है और यह जाँचने की जगह है कि वह आपके काम करने के ढंग से मेल खाती है या नहीं s3।
• Skills library वाला हिस्सा चौदहों skills को एक-एक पंक्ति के उद्देश्य के साथ गिनाता है; directory खँगालने से यह तेज़ है s16।
• Subagent skill की प्रति task अधिकतम पाँच rounds की सीमा एक कठोर stop है जिसे हाथ से लिखे किसी भी orchestration में कॉपी करना सार्थक है s11।
• एक thread पूछता है कि क्या इस तरह का plugin ज़्यादा मज़बूत models के सामने टिकेगा; जो हिस्से टिकते हैं वे framing gate और commit की गई plans हैं, जो हिस्से models सोख लेते हैं वे mechanics हैं s19।
• Orchestration की औपचारिकता से जल गई साप्ताहिक usage limit की एक रिपोर्ट वह उलट-मामला है जिसे छोटे कामों पर अपनाने से पहले पढ़ना चाहिए s20।
• एक प्रतिस्पर्धी instruction set से तुलना सौदा दिखाती है: कम लेकिन सख़्त skills बनाम नियमों की बड़ी सूची s18।
• Open issues की सूची यह जानने का सबसे तेज़ तरीक़ा है कि आज दूसरे users के लिए क्या टूट रहा है s6।

Sources

• obra/superpowers on GitHub, GitHub. क्यों पढ़ें: counters और release history, उद्धृत करने से पहले खुद पढ़ें।
• The fourteen skills (skills/ directory), GitHub. क्यों पढ़ें: product यही files हैं, और कुछ नहीं।
• Superpowers philosophy (README), GitHub. क्यों पढ़ें: method कुछ अनुच्छेदों में, यह तय करने के लिए काफ़ी कि वह आपको जँचती है या नहीं।
• Superpowers on the Claude plugin marketplace, Anthropic. क्यों पढ़ें: आधिकारिक listing और install command।
• Superpowers for Claude Code (origin story), Jesse Vincent. क्यों पढ़ें: क्षमता के ऊपर अनुशासन का दाँव, author की ज़ुबानी।
• Open issues, obra/superpowers, GitHub. क्यों पढ़ें: इस हफ़्ते असली users के लिए क्या फ़ेल हो रहा है।
• Whats u experience with superpowers plugin? Is it worth it or a tokens killer?, r/ClaudeCode. क्यों पढ़ें: 1 से 3 percent usage का वह सवाल जिसका जवाब video देता है।
• brainstorming/SKILL.md, GitHub. क्यों पढ़ें: HARD-GATE और तीन रास्ते, वह skill जिसमें ज़्यादातर फ़ायदा है।
• writing-plans/SKILL.md, GitHub. क्यों पढ़ें: task के आकार का नियम, हर step दो से पाँच मिनट।
• subagent-driven-development/SKILL.md, GitHub. क्यों पढ़ें: dispatch loop, दो-भाग का review और पाँच rounds की सीमा।
• Model Selection section, GitHub. क्यों पढ़ें: वह सीढ़ी जो token की बचत को ठोस बनाती है।
• using-git-worktrees/SKILL.md, GitHub. क्यों पढ़ें: plan आपके checkout से अलग-थलग कैसे चलता है।
• using-superpowers/SKILL.md, GitHub. क्यों पढ़ें: entry check, जो स्थायी लागत भी है।
• The skills library (README), GitHub. क्यों पढ़ें: हर skill की एक पंक्ति।
• Superpowers vs Everything Claude Code, r/ClaudeAI. क्यों पढ़ें: नियमों की सूची वाले तरीक़े से तुलना।
• Is superpower or related plugin still going to be useful?, r/ClaudeCode. क्यों पढ़ें: मज़बूत models के सामने क्या टिकता है।
• My weekly usage limit was being burned, r/OpenaiCodex. क्यों पढ़ें: orchestration की लागत पर उलट-मामला।

FAQ

क्या Superpowers tokens बचाता है या जलाता है?

दोनों। Features पर model selection mechanical tasks को छोटे models को भेजती है और महंगा model architecture और branch review के लिए रखती है, इसलिए quota खिंचती है। छोटे fixes पर briefs, हर task के दो reviews और ledger सिर्फ़ overhead हैं।

Usage stats का 1 से 3 percent होना क्या दर्शाता है?

Skills तभी trigger होती हैं जब कोई स्थिति उनसे मेल खाए। कम आँकड़े का मतलब है कि आपके tasks plugin की भाषा में features नहीं हैं, इसलिए आप entry check का दाम चुकाते हैं और उस हिस्से तक कभी नहीं पहुँचते जो लागत वसूल करता है।

क्या मैं इसका सिर्फ़ एक हिस्सा रख सकता हूँ?

हाँ। सिर्फ़ brainstorming में ज़्यादातर फ़ायदा है, और Model Selection की सीढ़ी हाथ से लिखे किसी भी subagent prompt में काम करती है। Agent से कहें कि छोटे fixes पर process छोड़ दे और नियंत्रण आपके हाथ में रहता है।