口號：「沒有先寫失敗的測試，就不准有正式程式碼。」
這不是口號，是鐵律。從 test-driven-development 到 writing-skills（寫技能也要先有會失敗的測試）再到 systematic-debugging（修 bug 前先寫一支會紅的測試），整個流程每一環都被同一條紀律把關。
為什麼？因為回饋的速度就是你的速度上限。你沒看過測試失敗，就不知道它在測什麼；你沒看過它變綠，就不知道程式真的做了你以為的事。TDD 讓代理每次都拿到「程式真的在運作」的證據，而不是「我猜應該可以」。
Superpowers 的每個技能都是一套明確的流程，不是一段建議。brainstorming 有它的提問結構，systematic-debugging 有它的四階段，subagent-driven-development 有它的任務迴圈與兩階段審查。
ad-hoc 依賴運氣：這把 bug 看起來像那回事就試試看，這次憑感覺改一改。系統化則保證每次都走同一條被驗證過的路。代理壓力越大，越需要流程——壓力會讓人（跟代理）退回憑感覺。
設計文件、計畫、測試、技能文件——全都要求最小、夠用就好。writing-plans 把任務拆到 2–5 分鐘，writing-skills 要求技能文件 <500 字、常用技能 <200 字。複雜度是累積的：每個多餘的環節都會在未來的每個 session 消耗 token 與注意力。
「YAGNI（You Aren't Gonna Need It）」與「DRY」不只是 coding 原則，也被套用到流程本身：不加不需要的環節，不重複寫已經有技能涵蓋的指示。
「測過了」「應該可以」「我記得它可以用」——全部不算數。verification-before-completion 要求：宣告完成之前，真的跑驗證指令、貼出輸出、確認結果。TDD 要求親眼看到紅與綠。
這條原則直接對抗代理最大的通病：過度自信地宣告成功。它把「證據」設為唯一可接受的完成標準，斷言之前必須先有輸出。
這四條不是獨立的口號，它們互相支撐：