using-superpowers

using-superpowers skill 概覽

using-superpowers skill 實際上在做什麼

using-superpowers 是來自 obra/superpowers repo 的一個工作階段啟動控制 skill。它的主要用途不是直接解決某個領域任務，而是確保 agent 在回覆之前、甚至在提出釐清問題之前，就先檢查是否有適合的 skills 可用。實務上，它會把「直接用 base model 回答」改成「先找對的 skill，再往下做」。

什麼情況最適合 using-superpowers

如果你希望在 Claude Code、Gemini CLI，或其他支援 skill 啟用的相容環境中採用「skills 優先」的工作流程，這個 skill 就很適合。尤其當你安裝了多個 skills，想要更穩定地被發現、更正確地路由指令，並降低 agent 忘記使用專門 workflow 的機率時，using-superpowers 會特別有價值。

真正要解決的工作需求

這個 skill 真正對應的需求，是治理與一致性：只要有任何合理可能適用的 skill，就要求 agent 把 skill lookup 視為必做步驟。如果你的核心問題是「助理明明有可用 skills，卻常常直接臨場發揮」，那 using-superpowers 就是直接對症下藥。

為什麼使用者會安裝它

使用者在決定是否採用 using-superpowers 前，通常最在意三件事：

1. 它能不能降低漏用 skill 的情況？
2. 它會不會和我自己的 repo 指令衝突？
3. 它能不能在我目前的工具環境中運作？

就這幾點來看，這個 skill 表現不錯：它明確寫出使用者指令仍然是最高優先權，也提供了 Claude-style tools、Codex-style tools 與 Gemini CLI 的平台對應參考。

和一般提示詞相比，關鍵差異在哪裡

using-superpowers 和普通那種「有需要時請使用工具」的 prompt 不一樣，它的規則更明確、也更嚴格。它定了一條硬規則：只要有哪怕一點點可能適用某個 skill，agent 就必須呼叫它。它也把指令優先順序與不同環境的啟用方式寫清楚，所以比起模糊提醒，它更接近可執行的操作規範。

先知道的重要限制

只有在你的環境真的支援 skills，或至少有等效的啟用機制時，using-superpowers 才有實際價值。它也包含 subagent 的停止條件，因此目標是主工作階段，而不是每一個被委派出去的子任務。如果你本來就不是走 skill-enabled workflow，那它帶來的比較像是政策約束，而不是功能提升。

如何使用 using-superpowers skill

安裝 using-superpowers 時要注意的情境

目前 repo 節錄中沒有提供 skill 內建的安裝指令，所以你需要透過自己的 skill manager，或依平台特定的 skill 設定方式，從 obra/superpowers repository 安裝，並選擇 skills/using-superpowers 裡的 using-superpowers skill。

如果你的工具支援以 repo 為基礎的安裝語法，請先到你所用環境的官方文件確認正確指令，再決定是否照抄第三方頁面的範例。真正重要的是：這個 skill 在 https://github.com/obra/superpowers 裡的路徑是 using-superpowers。

using-superpowers 在工作流程中應該放在哪裡

using-superpowers 應該在對話或工作階段一開始就使用，而不是等到流程已經走很深才中途插入。它的用途，是在 agent 開始選工具、發問或規劃工作之前，先把行為規則設定好。

正確的心智模型如下：

• 先啟用 using-superpowers
• 再描述你的任務
• 接著讓 agent 去發現並呼叫更具體、真正適合的 skill

實務上 using-superpowers 是怎麼被呼叫的

repo 對預期的啟用方式寫得很清楚：

• 在 Claude Code 中，使用 Skill 工具
• 在 Gemini CLI 中，使用 activate_skill
• 在類似 Codex 的環境中，原生遵循 skill 指示，並參照對應文件找到等效工具

如果你的平台本身支援 skill activation，就不要把 skill 檔案當純文字直接讀；這個 skill 已經明確要求要透過正確的 skill 機制來呼叫。

using-superpowers 需要什麼輸入

這個 skill 本身幾乎不需要額外輸入。真正關鍵的是你在啟用後立刻提供的任務內容。太弱的輸入通常會很寬泛、也缺乏足夠細節，例如：

• 「幫我看看我的 codebase」

更好的輸入，則會提供足夠的任務形狀，讓 skill discovery 有依據：

• 「我需要 review 一個 Python PR 的正確性，找出高風險變更，並建議後續測試。」
• 「我想在這個 repo 裡實作一個功能，請遵循專案既有慣例和 agent workflow。」
• 「幫我判斷，針對不穩定的 CLI integration test 除錯，應該用哪個 superpowers skill。」

你的目標、產物和執行環境描述得越具體，後續的 skill 選擇就越準。

把模糊目標改寫成更好的 using-superpowers prompt

一個實用的 using-superpowers usage 寫法是：

1. 先說任務
2. 指出涉及的 repo 或檔案
3. 補上限制條件
4. 明確要求 agent 在繼續前先找出並使用相符的 skills

例如：

Activate using-superpowers. I need to refactor src/auth/session.ts, preserve public behavior, avoid new dependencies, and follow this repo’s conventions. Check for any applicable skills before proposing changes.

這種寫法有效，是因為它讓 skill discovery 這一步拿到足夠上下文，能選出比一般 coding 回應更具體的東西。

評估 using-superpowers for Skill Discovery 時，先讀哪些 repository 檔案

如果你正在評估 using-superpowers for Skill Discovery，建議先看這幾個檔案：

1. skills/using-superpowers/SKILL.md
2. skills/using-superpowers/references/codex-tools.md
3. skills/using-superpowers/references/gemini-tools.md

這個閱讀順序能最快回答安裝決策最重要的問題：核心規則、指令優先權，以及平台相容性。

SKILL.md 裡最值得先看的重點

閱讀 SKILL.md 時，優先看這四個部分：

• 工作階段啟動要求
• 「只要有 1% 機率適用 skill」的規則
• 指令優先順序
• 平台存取指引

這幾段才是真正會影響 agent 行為的內容。它們能幫你判斷 using-superpowers 對你的情境來說，到底是有幫助、太強勢，還是能和現有設定相容。

平台適配指引

references 資料夾比表面上更實用。它把 Claude Code 為中心的工具名稱，翻成其他環境能理解的對應方式：

• references/codex-tools.md 說明了像 Task 對應 spawn_agent、TodoWrite 對應 update_plan，以及沒有 named agent registry 這類差異
• references/gemini-tools.md 說明了像 Skill 對應 activate_skill，並特別指出 Gemini CLI 不支援 subagent

如果你不是用 Claude Code，這些檔案往往就是「這個 repo 看起來很有趣」和「這個 workflow 我真的用得起來」之間的差別。

啟用 using-superpowers 後，建議怎麼跑流程

一個實用的 using-superpowers guide 可以這樣走：

1. 啟用 using-superpowers
2. 提供具體任務，包含檔案、限制條件與成功標準
3. 讓 agent 辨識是否有適用的專門 skill
4. 實際執行時，遵循那個專門 skill 的流程
5. 如果有任何衝突，再重新確認像 AGENTS.md、CLAUDE.md 或 GEMINI.md 這類使用者層級指令

這樣的流程能讓 using-superpowers 回到它正確的角色：做守門與路由，不是直接負責完成最終任務。

採用前要先理解的取捨與限制

最大的取捨是嚴格度。using-superpowers 可以提升一致性，但如果你平常只用一兩個 skills，或偏好比較鬆散、對話式的探索流程，它可能會讓整體操作感覺變重。它本身也很有立場：甚至在提出釐清問題之前，就傾向先推動 skill invocation，這對部分使用者來說可能太僵硬。

最大的限制則是生態成熟度。如果你的環境對 skills 的支援還不夠完整，那規則本身可能比實際執行路徑還清楚。

using-superpowers skill 常見問題

如果我只用少數幾個 skills，還值得安裝 using-superpowers 嗎？

通常還是值得，前提是那幾個 skills 對你很重要，而且你希望它們能被穩定使用。如果你本來就很少忘記手動呼叫 skills，那效益會小一些。最適合安裝的情況，是 skill discovery 漏掉時，會直接造成輸出品質下降或 workflow 不一致。

using-superpowers 對新手友善嗎？

算友善，但有一個前提：新手確實能從「先檢查 skill」這種強預設中受益，但仍然需要知道自己所用平台是怎麼啟用 skills 的。這時 reference 檔案就很有幫助，尤其是 Gemini CLI 和類 Codex 環境。

using-superpowers 會蓋掉我的專案指令嗎？

不會。這個 skill 明確寫出：使用者指令的優先權高於 superpowers skills，而 superpowers skills 只會覆蓋預設系統行為。如果你的 repo 層級指令明確說不要使用某種 workflow，那個更高優先級的指令會勝出。

什麼情況下不該使用 using-superpowers？

以下情況可以跳過：

• 你的環境對 skills 支援不好
• 你只是想做一次性的快速互動，根本沒有 skill ecosystem
• 你是以 subagent 身分執行一個範圍很窄的委派任務，因為這個 skill 本身就包含 subagent stop instruction

using-superpowers 和直接叫模型去用 skills，有什麼不同？

差別在於強制力與清晰度。一般 prompt 比較像建議；using-superpowers 則是有明確優先權處理與平台說明的結構化操作規則。因此在重複使用時，它的表現通常更可靠。

using-superpowers 是否特別適合 Skill Discovery？

是，而且這正是它的核心價值。當你的 skill 庫逐漸擴大，希望 agent 把 discovery 當成必做步驟、而不是可做可不做時，using-superpowers for Skill Discovery 的效果會特別明顯。

如何改進 using-superpowers skill 的使用效果

啟用 using-superpowers 之後，把任務描述寫得更好

影響品質最大的槓桿，不是啟用動作本身，而是啟用後的第一則任務訊息。建議至少包含：

• 明確目標
• 相關檔案或目錄
• 限制條件
• 偏好的 workflow
• 完成定義

這樣比起寬泛需求，更容易得到正確的 skill 匹配。

常見失敗模式：目標太模糊，導致 skill 選擇變弱

如果你只說「幫我看看這個 repo」，agent 可能仍然會找到某個 skill，但它幾乎沒有足夠依據去選最適合的那一個。比較好的做法，是把模糊請求改成更有任務形狀的描述，例如：

• 「幫我找出適合 review 高風險 migration diff 的 skill」
• 「在提出 debug CI failure 的計畫前，先使用任何相關的 superpowers skill」
• 「判斷這個任務更適合 planning、implementation，還是 review skill」

常見失敗模式：平台不匹配

很多人採用失敗，是因為在別的環境裡把 Claude-style 的工具名稱照字面理解。解法是：先看對應你平台的 reference 檔案，再評估這個 skill 值不值得用。Codex 先看 references/codex-tools.md；Gemini CLI 先看 references/gemini-tools.md。

搭配 repo 層級指令，能讓 using-superpowers 更好用

如果你的 repo 已經在 AGENTS.md、CLAUDE.md 或 GEMINI.md 中寫了清楚、且優先級高的指令，using-superpowers 會更容易發揮效果。因為這個 skill 會尊重這些檔案，所以本地指引越清楚，衝突越少，被發現的 skills 也越容易正確套用。

把 using-superpowers 當成路由層，不要當最終方法

常見誤解之一，是期待 using-superpowers skill 本身包含所有執行細節。比較正確的看法，是把它當成導向整個 superpowers 生態系的路由器。想得到更好的結果，最好搭配明確的下游 skill，而不是停在 activation 這一步。

第一次回應不理想時，繼續迭代

如果第一輪回應沒有明確辨識或呼叫相關 skill，不要立刻放棄這個 workflow，先把 prompt 收斂得更具體。你可以補上：

• 要操作的確切產物
• 所需工作的類型
• 任何重要限制
• 明確要求在繼續前先檢查適用 skills

這通常能同時提升 skill discovery 和後續執行品質。