版本
v5.0.7（npm package & plugin.json）
SessionStart hook 強制注入 using-superpowers meta-skill，
把 14 個 markdown-defined skill 變成「描述匹配即必須觸發」的硬約束，
把 brainstorm → spec → plan → subagent-driven TDD → two-stage review → finish 的工作流程
變成 agent 無法繞過的執行軌道。
這節要把整個 repo 最關鍵的一句話講清楚：Superpowers 的核心不是「給 AI 多塞知識」，而是「讓 AI 接到任務時，先進入正確的流程」。
原本的 AI 是聊天模式：你說一句、它接一句、想到什麼回什麼。
裝了 Superpowers 的 AI 是流程模式：每次接到任務，會先看「現在這件事屬於哪個 skill 管的，然後照那條 skill 的 SOP 做」。
using-superpowers 這個技能的內容，由啟動腳本（hook）直接塞進 AI 的「腦袋」裡，所以你不必特別下指令，它就知道要照規矩做事。把 Superpowers 看成一個「跨 harness 的 agent 治理層」會比看成「一組 prompts」更精準。它做的事可以分成五個並列的概念：
它並沒有真的「控制模型」——LLM 的權重沒被改、解碼也沒被攔。
更精準的說法是：它透過 hook 注入 + skill description routing +
markdown workflow + hard gates + verification evidence 五個機制，
把 agent 的可能行為軌道收斂到設計者選定的範圍。模型仍然有自由度，但「跳過流程」的成本被刻意拉高。
session start
└→ hooks/session-start (注入 using-superpowers 全文 + 鐵律)
└→ agent context now contains:
"any task → check skill first (≥1% match → must invoke)"
user message: "幫我做 X"
└→ agent 呼叫 Skill tool 列舉 skill descriptions
└→ in-context skill router (LLM 自己做語意匹配)
└→ invoke matched skill (SKILL.md 全文進 context)
└→ skill 內含：HARD-GATE / Iron Law / Red Flags / 流程圖
└→ agent 沿軌道執行；不允許繞過閘門
hooks/session-start — bootstrap 的 shell 實作；多 harness JSON 變體skills/using-superpowers/SKILL.md — 「skill 匹配=必觸發」鐵律與 Red Flags 表skills/brainstorming/SKILL.md — HARD-GATE：未獲設計核可前禁止任何實作 skillskills/test-driven-development/SKILL.md — Iron Law: NO PRODUCTION CODE WITHOUT FAILING TESTskills/verification-before-completion/SKILL.md — Iron Law: 完成宣稱必須附本輪驗證證據README.md — 七步工作流的對外定義用一個比喻：你雇了一個「會自動駕駛的 AI 工程師」，但它沒駕照、不問路、會在你後座抽煙。Superpowers 是那本厚厚的「駕訓教科書」，灌進它腦袋之後，它每次上路前都會被一個內建教練盯著做完七步檢查。
你只負責下一句話：「幫我做 X」。下面這些都是 AI 自己會跑出來的流程，你只需要在每個關卡看一下、回個「OK」或「不對，要這樣改」。
這是 Superpowers 最有特色的設計：直接用「鐵律」（Iron Laws）這種強烈字眼，讓 AI 沒辦法說服自己「這次例外一下」。
Superpowers 不是一個會「執行」的程式；它是一組會被 agent 在執行期讀取的 markdown，搭配一個 SessionStart hook。重點不在「有什麼程式碼」，而在「如何把規範強制注入 LLM 的 context window」。
Superpowers 沒有改模型，也沒有 fine-tune。它的「自動觸發」完全靠三層 prompt-engineering：
hooks/hooks.json 註冊 SessionStart: startup|clear|compact 事件，腳本會把 using-superpowers/SKILL.md 全文塞進 agent 啟動 context。同一支腳本依環境變數判斷要輸出
additional_context（Cursor）、hookSpecificOutput.additionalContext（Claude Code）或 top-level additionalContext（Copilot CLI / SDK 標準），這就是它能跨 harness 的關鍵。
<EXTREMELY-IMPORTANT> If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. </EXTREMELY-IMPORTANT>
搭配一張「Red Flags 表」列舉 LLM 最常見的合理化字眼（例：「這只是個簡單問題」「我先看一下檔案」）， 預先把 agent 想跳過 skill 的內心戲擋掉。這是把 LLM 自我說服的失敗模式 當成「對抗性測試案例」設計出來的。
每個 SKILL.md 的 YAML frontmatter 都有像
"Use when implementing any feature or bugfix, before writing implementation code"
這樣的觸發描述。這份 description 會在 agent 呼叫 Skill tool 列表時呈現，
由 LLM 自行根據語意匹配。Superpowers 的設計原則是：description 必須能在最噪雜的情境下還能正確匹配到該 skill。
using-superpowers 明確規定三層優先序，這是它和很多「用 system prompt 強壓行為」的方案最大的差別：
這個層級設計避免了 skills library 變成另一個「無法關掉的 system prompt」，反而讓專案層級的 CLAUDE.md 可以對 skills 做 override。
這是 Superpowers 最有架構野心的部分。它把「執行任務」「驗證符不符合規格」「驗證程式碼品質」三件事拆成獨立的 fresh subagent，避免 context pollution、避免 self-review 的 bias。
per task:
1. dispatch implementer subagent (./implementer-prompt.md)
└─ implements + tests + commits + self-reviews
2. dispatch spec-reviewer subagent (./spec-reviewer-prompt.md)
└─ "does the diff match the spec?"
└─ if gaps → 回到 implementer 修
3. dispatch code-quality-reviewer subagent (./code-quality-reviewer-prompt.md)
└─ "is this code clean / idiomatic?"
└─ if issues → 回到 implementer 修
4. mark task complete in TodoWrite
關鍵是「fresh」二字：每個 subagent 都拿到精準裁切過的 context，不繼承父 session 的歷史。父 agent 變成 orchestrator，自己的 context window 只用來協調，不被任務細節塞滿。對使用 LLM agent 的人這個模式不算新，但 Superpowers 把它「規範化」，並把 prompts 抽成可版控的 markdown 檔。
Superpowers 有一個獨特的書寫風格：用宗教式語言寫工程規範。這不是修辭癖，是針對 LLM 行為失敗模式的回應。
test-driven-development — NO PRODUCTION CODE WITHOUT A FAILING TEST FIRSTsystematic-debugging — NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRSTverification-before-completion — NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE每個 skill 都附一張「Thought / Reality」對照表，列舉最常被 LLM 拿來合理化偷懶的內心話：
CLAUDE.md（給 contributor 看的） 還明白寫了：
這是把 prompt 當作 production code 在版控的一個典範案例。
同一份 skills 內容，靠多個 manifest 與一個共用 hook 同時供應給六種代理平台。
.claude-plugin/ plugin.json + marketplace.json ← Claude Code .codex-plugin/ plugin.json ← Codex CLI .codex/ manifest ← Codex App .cursor-plugin/ plugin.json ← Cursor .opencode/ plugins/superpowers.js + INSTALL ← OpenCode (用 npm 入口) gemini-extension.json ← Gemini CLI hooks/ hooks.json + run-hook.cmd + session-start ← 共用
session-start 腳本以 env var 判斷 harness 種類，輸出對應 JSON 結構；
.version-bump.json 一次同步全部 manifest 的版本欄位。
package.json 的 main 指向 .opencode/plugins/superpowers.js，但整個 repo
對任何 npm 套件零依賴——這是設計原則，PR 加任何依賴都會被拒。
writing-skills+ adversarial pressure tests）Skill tool / 從不輸出 "I'm using the X skill" 開場 → router 失靈官方在 CLAUDE.md 寫得很直白：新 harness 整合的 acceptance test 就是 送 "Let's make a react todo list" → brainstorming 必須自動觸發， 做不到就不算整合。
| Skill | 類別 | 定位 |
|---|---|---|
| using-superpowers | meta | SessionStart 注入的 bootstrap，內含「skill 匹配=必觸發」鐵律與 Red Flags 表 |
| writing-skills | meta | 用 TDD 寫 skill；對抗性壓力測試 + 評分 |
| brainstorming | collab | Socratic 式設計精煉；HARD-GATE 在沒設計與用戶確認前禁止任何實作 skill |
| writing-plans | collab | 把 spec 切成 2–5 分鐘的 bite-sized 任務；File Structure 先決 |
| executing-plans | collab | 無 subagent 環境下，依 checkpoint 執行 plan |
| subagent-driven-development | collab | 同 session 內，每任務 fresh subagent + 兩段式審查 |
| dispatching-parallel-agents | collab | 多個獨立問題並行；每問題一個 agent |
| using-git-worktrees | collab | 系統化選目錄、跑乾淨測試 baseline、隔離工作區 |
| finishing-a-development-branch | collab | tests pass → 提供 merge / PR / keep / discard 選項並收尾 |
| requesting-code-review | collab | 用 SHA 區間派 code-reviewer subagent，分嚴重度回報 |
| receiving-code-review | collab | 禁 "You're absolutely right!"；驗證後再實作或合理 pushback |
| test-driven-development | testing | RED-GREEN-REFACTOR；違反者刪 code 重來 |
| systematic-debugging | debug | 四階段流程：找根因 → 設計修正 → 實作 → 驗證 |
| verification-before-completion | debug | 宣稱完成前必須在當前訊息內跑驗證指令 |
/plugin install superpowers，少數情境用 CLAUDE.md override。skills/using-superpowers/SKILL.md 與 hooks/session-start，把同樣的 bootstrap+router 模式套到自己內部 agent。writing-skills 是少數把 "TDD for prompts" 寫成可執行流程的文獻；adversarial pressure testing 部分對自家 prompt eval 有直接價值。以下章節都是 FALO 觀點的設計模式轉譯，不是把 Superpowers「FALO 化」，也不是宣傳頁。我們先承認它原本服務的是 coding agent，再說明這些設計概念如何被搬到企業 AI 工作流卡上。不論你切到「新手」或「架構師」視角，下面這幾節都會顯示，因為它們同時是策略觀點與設計規格。
Superpowers 是給 coding agent 的方法論。它服務的是「在 IDE / CLI 裡寫 production code 的 LLM」，不是「在企業現場處理訪談、整理、審核的一線員工 + AI」。所以下面這句話不是正確的對應：
更精準的說法是：
| 層級 | Superpowers 原生 | FALO 轉譯 |
|---|---|---|
| 對象 | coding agent（一個 LLM） | 一線員工 + AI + SME + 主管（多角色協作） |
| 任務 | 寫 code、修 bug、code review、finish branch | 訪談、整理、審核、模型菜、KM/CM、AI AUDIT |
| 控制方式 | skill + hook + gate + verification | 工作情境卡 + 權限 + 審核 + 證據 |
| 輸出 | spec / plan / test / review / verification | SOP / 模型菜 / audit trail / 交付文件 |
| 核心價值 | 讓 agent 照工程流程走 | 讓人與 AI 照工作情境走 |
換句話說：「方法論可以借，劇本要重寫。」 Superpowers 借的是「skill-as-code、hook 注入、hard gate、verification 證據」這些設計樣式； FALO 要寫的是企業現場的劇本——情境、角色、權限、審核、可交付物。
企業 AI 工作流卡不是普通 prompt library。它必須同時滿足七個性質才能進入企業現場：
這是給「卡」這個物件的最小可用 schema。實作可以是 YAML / JSON / 加密容器；下面以 YAML 表達語意：
card_id: # 全域唯一識別（建議 ULID/UUID） card_name: # 對人可讀的名稱 scenario: # 適用的工作情境（例：客戶訪談紀要審核） applicable_when: # 觸發條件（什麼時候該用這張卡） not_applicable_when: # 反向條件（什麼時候不要用） visible_instruction: # 給人看的操作指引（公開層） input_required: # 此卡執行所需的輸入欄位 ai_can_do: # AI 在此卡內被授權做的事 ai_cannot_do: # AI 在此卡內被明確禁止的事 human_gate: # 必須由人完成的審核點 evidence_required: # 完成本卡必須留下的證據（檔案、簽章、log） output_format: # 交付物的格式與規範 audit_fields: # 審核者要看到的欄位（含決策紀錄） version: # SemVer 或日期版本 signature: # 卡片完整性簽章 visibility: # public / partner / internal / restricted editability: # editable / read-only / template runtime_mode: # interactive / batch / scheduled / agent-driven
frontmatter description（什麼時候用我）、流程主體（怎麼做）、Iron Law 與 Red Flags（什麼時候不能跳過）。FALO 把這套結構放大成「企業卡片」，再加上人 / 角色 / 證據 / 簽章四個維度。
企業流程卡和 open-source skill 不一樣——它必須在不同情境下「以不同形態被看到」。同一張卡可能會同時存在六種型態：
| 類型 | 適合情境 | 內容狀態 | 目的 |
|---|---|---|---|
| 公開版 | 教學、展示、銷售、內訓 | 去敏、可讀 | 讓人理解方法 |
| 加密版 | 正式導入、客戶現場 | 隱藏 prompt / 規則 / know-how | 保護治理邏輯 |
| 可編修版 | 顧問客製、SME 調整 | 可改流程與欄位 | 快速迭代 |
| 不可編修版 | 一線執行、稽核流程 | 鎖定、簽章 | 防誤改、防繞過 |
| 範本版 | 新卡建立 | 半完成或空白 | 複製成新工作卡 |
| 執行版 | 給 runtime / AI agent | 機器可讀，可能編碼 | 實際驅動 AI 工作 |
這個多型態觀念，本質上是把 Superpowers 的「指令優先層級」做了權限分層的擴張：在 Superpowers 是 user → skill → system 三層；在 FALO 是 viewer → editor → executor → auditor 四層，而且每層只看到自己權限內的卡片狀態。
如果不是 Server/Client 模式，而是地端部署，流程卡不能只是明文 .md / .json / .html，因為員工可能直接打開或修改下面這些治理性內容：
| 模式 | 可防什麼 | 防不了什麼 |
|---|---|---|
| 明文卡 | 幾乎防不了 | 誤改、偷看、複製 |
| 編碼 / 混淆卡 | 防一般誤看誤改 | 防不了懂技術的人 |
| 加密卡 + 本地 key | 提高破解成本 | key 在本機仍可能被抓 |
| 簽章卡 | 可偵測竄改 | 不一定防止被讀 |
| Server / Client | 可真正控權限與邏輯 | 需要後端與網路成本 |
這部分超出 Superpowers 的範圍——Superpowers 因為服務的是工程師自己的 coding agent，所以 skills 是公開明文 markdown，沒有這層安全考量。FALO 要進企業就必須補這一塊：你不能拿一份「對工程師來說剛好的明文制度」，直接放進客戶的法遵與營運場景。
FALO 會產生很多「模型菜」讓客戶套用與調整。這類工作如果一開始就硬套 Superpowers 的 plan + TDD，AI 很容易只「模仿表面」、把原型的字面格式照抄一遍而沒抓到 native logic。正確流程應該是先把原型讀懂，再用 Superpowers 的紀律收斂，最後才轉成 FALO 卡：