وبلاگ / راهنمای مسیر یادگیری و فناوری
راهنمای مسیر یادگیری و فناوری

Superpowers برای Claude Code چیست؟ آموزش نصب و اجرای Workflow توسعه مبتنی بر Skill

Superpowers مجموعه‌ای از Skillهای مهندسی برای Brainstorming، برنامه‌ریزی، TDD، Debug و Review است. در این راهنما نصب افزونه در Claude Code و اجرای امن یک Workflow واقعی را یاد می‌گیرید.

· ۲۶ بازدید

وقتی یک عامل کدنویسی به Repository دسترسی دارد، مشکل اصلی معمولاً کمبود توان تولید کد نیست؛ مسئله این است که عامل چگونه از یک ایده مبهم به طراحی، برنامه، تست، پیاده‌سازی و بازبینی می‌رسد. یک چارچوب Skillمحور برای ایجاد همین نظم در ابزارهایی مانند است.

مدل جدیدی به Claude اضافه نمی‌کند و کیفیت پروژه را به‌صورت جادویی تضمین نمی‌کند. این افزونه مجموعه‌ای از رویه‌های قابل‌فراخوانی برای Brainstorming، نوشتن Plan، توسعه تست‌محور، Debug سیستماتیک، Review و تحویل کار ارائه می‌دهد. در این راهنما افزونه را از Marketplace نصب می‌کنیم، محتوای آن را بازبینی می‌کنیم و یک Workflow کوچک و قابل‌آزمون می‌سازیم.

چیست؟

یک پروژه متن‌باز با مجوز MIT است که Skillهای توسعه نرم‌افزار را برای چند Agent و Coding Harness بسته‌بندی می‌کند. در به شکل Plugin نصب می‌شود و Skillهای آن براساس نوع کار در دسترس عامل قرار می‌گیرند. Repository رسمی آن روی GitHub نگه‌داری می‌شود و Manifest افزونه نام، نسخه، مجوز و منبع را مشخص می‌کند.

هسته ایده ساده است: به‌جای اینکه در هر Prompt دوباره بنویسیم «اول مسئله را روشن کن، بعد برنامه بده و سپس Test بنویس»، این قراردادها در Skillهای Version‌شده قرار می‌گیرند. نتیجه می‌تواند فرایندی تکرارپذیرتر باشد، به شرط آنکه کاربر هنوز Scope، Plan، Diff و Test را کنترل کند.

چه چیزهایی به Workflow اضافه می‌کند؟

مرحلهSkill یا الگوخروجی مورد انتظارگیت انسانی
کشف مسئلهbrainstormingنیاز روشن و Design تأییدشدهتأیید طرح پیش از کدنویسی
برنامه‌ریزیwriting-plansکارهای کوچک با مسیر فایل و آزمونReview محدوده و ترتیب
پیاده‌سازیtest-driven-developmentچرخه Red، Green و Refactorمشاهده Failure واقعی
رفع اشکالsystematic-فرضیه و شواهد قابل تکراررد حدس‌های بی‌مدرک
بازبینیrequesting-code-reviewDiff و یافته‌های اولویت‌بندی‌شدهپذیرش یا اصلاح
تکمیلverification-before-completionخروجی آزمون تازهتأیید ادعای نهایی

نام و جزئیات Skillها ممکن است با نسخه پروژه تغییر کنند. پیش از اتکا به یک Workflow، README، Manifest و پوشه skills همان نسخه‌ای را که نصب کرده‌اید بررسی کنید. یک مقاله یا ویدیو ممکن است مربوط به نسخه قدیمی باشد.

پیش‌نیاز نصب در

ابتدا را نصب و احراز هویت کنید و مطمئن شوید فرمان‌های Plugin در نسخه شما موجودند. Repository پروژه باید تحت Version Control باشد تا بتوانید هر تغییر را با Diff بررسی و در صورت نیاز بازگردانی کنید. نصب افزونه شخص ثالث به معنی ورود Instructionها و Hookهای جدید به Context عامل است؛ بنابراین منبع را مانند Dependency کد بازبینی کنید.

  • Repository رسمی باید obra/superpowers باشد.
  • مجوز، نسخه و Commit مورد استفاده را ثبت کنید.
  • فایل‌های SKILL.md و Hookهای افزونه را مرور کنید.
  • نصب را ابتدا در پروژه آزمایشی انجام دهید.
  • Permissionهای را مستقل و محدود نگه دارید.

نصب از Marketplace رسمی Claude

README رسمی پروژه اعلام می‌کند از Marketplace رسمی Pluginهای Claude قابل نصب است. فرمان زیر را داخل نشست اجرا کنید، نه در PowerShell یا Bash سیستم:

Command
/plugin install superpowers@claude-plugins-official
UTF-8Command

پس از نصب، را طبق راهنمای نسخه خود Refresh یا Restart کنید و فهرست Pluginها را ببینید. فقط ظاهرشدن نام افزونه کافی نیست؛ یک کار کوچک آزمایشی تعریف کنید و بررسی کنید Skill مرتبط در زمان درست فعال می‌شود و قبل از تأیید Design وارد تغییر فایل نمی‌شود.

نصب از Marketplace پروژه

پروژه یک Marketplace جدا نیز دارد. این مسیر زمانی مفید است که نسخه یا افزونه‌های همراه Marketplace پروژه را می‌خواهید. ابتدا Marketplace را ثبت و سپس افزونه Core را نصب کنید:

Command
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace
UTF-8Command

دو منبع را هم‌زمان نصب نکنید مگر مستندات نسخه صریحاً چنین چیزی بخواهند. وجود نسخه‌های تکراری می‌تواند تشخیص Skill و به‌روزرسانی را مبهم کند. برای تیم، یک منبع و نسخه مشخص انتخاب و آن را در راهنمای Onboarding ثبت کنید.

Workflow پیشنهادی برای یک قابلیت کوچک

فرض کنید می‌خواهید به یک API، فیلتر جست‌وجوی ساده اضافه کنید. درخواست خام «فیلتر را بساز» برای Agent فضای تفسیر زیادی دارد. Workflow منظم، کار را به گیت‌های قابل مشاهده تقسیم می‌کند.

  1. Brainstorm: رفتار، ورودی نامعتبر، Pagination، Performance و معیار پذیرش را روشن کنید.
  2. Design approval: پیش از تغییر کد، طرح کوتاه را بخوانید و تأیید کنید.
  3. Plan: هر Task باید فایل، تغییر، Test و فرمان Verification داشته باشد.
  4. Red: Test شکست‌خورده‌ای بنویسید که رفتار موردنظر را ثابت کند.
  5. Green: کمترین تغییر لازم را برای عبور Test اعمال کنید.
  6. Refactor: فقط با سبزبودن Test، ساختار را تمیز کنید.
  7. Review: Diff را از نظر Correctness، Security و Scope بررسی کنید.
  8. Verify: فرمان آزمون تازه اجرا و خروجی واقعی ثبت شود.

می‌تواند عامل را به رعایت این ترتیب هدایت کند، اما تأیید معیار پذیرش و تصمیم درباره Trade-off هنوز وظیفه تیم است. اگر Design اشتباه تأیید شود، اجرای منظم فقط همان تصمیم اشتباه را سریع‌تر پیاده می‌کند.

چگونه یک Prompt مناسب بنویسیم؟

برای شروع، مسئله و محدودیت را بگویید و از Agent بخواهید Skill مناسب را به‌کار بگیرد. خروجی مورد انتظار و گیت توقف را نیز مشخص کنید. نمونه زیر کوتاه است اما Scope را روشن می‌کند:

prompt.txtText
برای endpoint جست‌وجوی محصولات، فیلتر category اضافه کن.ابتدا با Skill brainstorming نیازها و edge caseها را روشن کن.تا زمانی که Design را تأیید نکرده‌ام هیچ فایلی را تغییر نده.پس از تأیید، Plan شامل فایل‌ها، تست‌ها و فرمان verification بساز.
UTF-8Text

Prompt نباید اجرای هر Instruction موجود در Repository را مجاز کند. فایل‌ها و متن‌های پروژه داده غیرقابل‌اعتماد هستند و ممکن است دستورهای ناسازگار با هدف شما داشته باشند. Scope، مسیرهای ممنوع، Permission و Secretها را جدا از Skill مدیریت کنید.

در چگونه کمک می‌کند؟

ارزش فقط داشتن Test نیست؛ مشاهده Failure پیش از Implementation نشان می‌دهد Test واقعاً رفتار جدید را اندازه می‌گیرد. اگر Test از ابتدا سبز باشد، ممکن است معیار اشتباه یا رفتار موجود را بررسی کند. Skill توسعه تست‌محور باید Agent را به چرخه کوچک و قابل مشاهده هدایت کند.

سه کنترل برای جلوگیری از Test نمایشی

  • نام Test باید رفتار و شرط را توضیح دهد، نه جزئیات Implementation را.
  • خروجی Failure باید علت مورد انتظار را نشان دهد.
  • پس از Green شدن، تغییر موقت در Implementation باید Test را دوباره قرمز کند.

برای کد Legacy ممکن است ابتدا Characterization Test لازم باشد. Agent نباید صرفاً برای عبور Test، Assertion را ضعیف یا Test را حذف کند. تغییر Test و Production code را در Diff جداگانه مرور کنید.

Debug سیستماتیک به‌جای تغییرهای تصادفی

عامل‌های کدنویسی گاهی با دیدن خطا چند Fix محتمل را پشت سرهم امتحان می‌کنند. Debug سیستماتیک ابتدا بازتولید، مرز خرابی، داده ورودی، Log و فرضیه قابل ابطال می‌خواهد. هر آزمایش باید یک سؤال را جواب دهد.

رویکردرفتارریسک
تصادفیچند تغییر هم‌زمانعلت واقعی پنهان می‌شود
سیستماتیکیک فرضیه و یک آزمایشکندتر در شروع، قابل اعتمادتر در پایان
Fix بدون Testتکیه بر مشاهده دستیRegression بازمی‌گردد
Fix با Regression TestFailure بازتولید و سپس رفع می‌شودرفتار آینده محافظت می‌شود

از Agent بخواهید پیش از Fix، شواهد و فرضیه را بنویسد. اگر بیش از یک فایل تغییر می‌کند، توضیح ارتباط هر تغییر با علت ریشه‌ای را بخواهید. این کار Review را بسیار ساده‌تر می‌کند.

Plan خوب چه ویژگی‌هایی دارد؟

Plan خوب فهرست آرزوها نیست. هر Task باید خروجی مستقل و قابل‌آزمون داشته باشد. مسیر دقیق فایل، Test موردنظر، تغییر حداقلی و فرمان Verification باید مشخص باشند. اگر Task آن‌قدر بزرگ است که چند Component نامرتبط را تغییر می‌دهد، باید شکسته شود.

  • هر مرحله یک هدف قابل قبول یا رد دارد.
  • Dependencies میان مراحل روشن‌اند.
  • Migration، Security و Rollback فراموش نشده‌اند.
  • فرمان Verification متناسب با Scope است.
  • هیچ Secret یا داده Production در Plan نوشته نمی‌شود.

برای آشنایی عمیق‌تر با ساختار Skill و Progressive Disclosure، راهنمای ساخت Agent Skills و SKILL.md را ببینید. یک نمونه عملی از تبدیل روش کار به Skill است.

نکات امنیتی نصب Plugin و Skill

Plugin می‌تواند Instruction، Command، Hook یا منبع اضافی وارد محیط Agent کند. محبوبیت Repository جایگزین Review نیست. نسخه‌ای را که نصب می‌کنید با Manifest رسمی تطبیق دهید و تغییرات Update را پیش از استفاده روی Repository حساس مرور کنید.

  • نصب را از Repository و Marketplace رسمی پروژه انجام دهید.
  • Hookها و Scriptهای اجرایی را قبل از فعال‌سازی بخوانید.
  • Permissionهای را به افزونه واگذار نکنید.
  • فایل‌های .env، Key و Credential را Deny کنید.
  • برای پروژه ناشناس از Sandbox یا Container استفاده کنید.
  • فرمان مخرب، انتشار یا Push را بدون بازبینی تأیید نکنید.
  • Update افزونه را مانند Update Dependency بررسی کنید.

Skill یک متن Instruction است و می‌تواند اشتباه، قدیمی یا بیش از حد گسترده باشد. خروجی Agent را با مستندات پروژه و Test واقعی تطبیق دهید. هیچ Skillی مسئولیت انسانی برای Merge و انتشار را حذف نمی‌کند.

اشتباه‌های رایج

  • نصب هم‌زمان نسخه رسمی و Marketplace پروژه و ایجاد تداخل.
  • شروع Implementation پیش از تأیید Design.
  • نوشتن Plan بزرگ بدون Task قابل‌آزمون.
  • سبزکردن Test با ضعیف‌کردن Assertion.
  • اعتماد به ادعای «همه تست‌ها پاس شدند» بدون خروجی تازه.
  • اجرای Skill روی Repository حساس بدون بازبینی منبع.
  • استفاده از Workflow کامل برای تغییر بسیار کوچک و افزایش سربار.
  • نادیده‌گرفتن Diffهای خارج از Scope.

چک‌لیست اولین اجرای موفق

  • منبع و نسخه Plugin تأیید شده است.
  • Repository آزمایشی و Git clean است.
  • Permissionها حداقل و Secretها خارج از Scope هستند.
  • مسئله و معیار پذیرش نوشته شده‌اند.
  • Brainstorming پیش از تغییر فایل انجام شده است.
  • Design به تأیید کاربر رسیده است.
  • Plan شامل فایل، Test و Verification است.
  • Failure تست پیش از Implementation مشاهده شده است.
  • Diff فقط Scope توافق‌شده را پوشش می‌دهد.
  • خروجی آزمون نهایی تازه و قابل تکرار است.

جمع‌بندی

برای یک کتابخانه Skill و روش توسعه است؛ هدفش این نیست که مدل را باهوش‌تر نشان دهد، بلکه می‌خواهد تصمیم‌ها و گیت‌های مهندسی را قابل مشاهده‌تر کند. Brainstorming، Plan، ، Debug و Verification زمانی ارزش دارند که خروجی هر مرحله واقعاً Review شود.

برای شروع، افزونه را از منبع رسمی در یک Repository آزمایشی نصب کنید. یک قابلیت کوچک انتخاب کنید، پیش از کدنویسی Design را تأیید و پس از اجرا Diff و Test را مستقل بررسی کنید. سپس فقط Workflowهایی را که برای تیم شما ارزش دارند نگه دارید.

امروز را فقط روی یک پروژه آزمایشی نصب کنید و یک قابلیت کوچک را تا مرحله Design و Plan پیش ببرید؛ پیش از تأیید دستی، اجازه تغییر فایل ندهید.

منابع رسمی