Claude Skills 實戰：我把 5 個最常用的 Skill 串成一套工作流
整理版優先睇
作者分享用5個Claude Skills串成工作流，從模糊需求到驗收通過
呢篇文章係一個開發者分享自己點樣將5個常用嘅Claude Skills串成一套工作流。佢用開一個叫superpowers嘅Skill集合，但發現Skill越多越亂，唔知幾時用邊個。為咗解決呢個問題，佢將brainstorming、writing-plans、test-driven-development、systematic-debugging同verification-before-completion排咗個固定順序。
每個Skill都有清晰嘅入口同出口：brainstorming將模糊需求問清楚，writing-plans將清楚需求拆成步驟，TDD邊測邊寫，systematic-debugging喺卡住時系統化排查，verification-before-completion確保自驗通過先叫完成。作者用一個React彈窗組件做例子，示範點樣行完呢條線。由一句「加個彈窗」開始，經過brainstorming問咗一堆問題，得出清楚需求清單；writing-plans變成五個實施步驟；TDD先寫FormField測試；中間卡住時用systematic-debugging排查；最後verification強制測試、類型、真實環境都過曬先完成。
整體結論係：單個Skill嘅價值有限，但按「需求→方案→實現→排錯→驗收」串起嚟，就能變成有效工作流。呢個流程最適合「有不確定性嘅中等任務」——需求模糊、實行路徑多、要排查問題。簡…
- 五個Skill按順序：brainstorming → writing-plans → TDD → systematic-debugging → verification-before-completion，每個有清晰入口出口。
- brainstorming嘅核心係反向提問，唔係發散想法；writing-plans逼你動手前過腦，唔係照抄方案。
- TDD喺前端嘅真實價值係逼你先諗清楚組件接口，唔係追求測試覆蓋率。
- systematic-debugging強制「明確現象→最小復現→假設清單→逐個排除→找到根因先改」，避免亂試。
- verification-before-completion要求所有測試通過、類型檢查冇錯、真實環境用過、邊界場景試過、console冇warning error，先算完成。
點解要串起呢5個Skill？
單個Skill調用好簡單，難嘅係
唔知幾時用邊個
。作者發現自己常用5個Skill，但實際寫code時容易亂用。佢嘅解決方法係將呢5個Skill排咗個固定順序，每個有明確入口出口。
- brainstorming：將模糊需求問清楚（反向提問，唔係發散想法）
- writing-plans：將清楚需求拆成實施步驟
- test-driven-development：邊測邊寫，唔一口氣糊一坨
- systematic-debugging：卡住時按圖索驥，唔亂捉藥
- verification-before-completion：自驗通過先叫完成
逐個Skill示範：用React彈窗組件行一次
先調brainstorming：比句「加一個React彈窗組件，填郵箱和手機號」。佢會
反問一堆問題
：校驗實時定失焦？loading按鈕點樣？等。逐個答完，需求從一句話變成清楚功能描述。
入口：一句話需求；出口：寫得出來嘅需求清單
呢步嘅核心係
反向提問，唔係發散想法
。需求冇問清楚，後面三步都係錯嘅地基上蓋樓。
接着調writing-plans：基於上一步需求寫實施方案。佢會輸出結構化方案，包含組件結構、狀態管理等。呢步嘅價值係
逼你動手前過腦
，唔係照抄。
真寫嘅時候發現某步唔啱，返嚟改方案再繼續，比邊寫邊想要順得多。
然後行TDD：先調test-driven-development，生成測試檔案。跑後全紅，寫最小實現變綠。
呢度唔考慮樣式動畫，只考慮「令測試過」
。TDD嘅真實價值係
逼你先諗清楚組件嘅接口
，唔係測試覆蓋率。
卡住時調systematic-debugging：例如input value冇同步。佢會要求
明確現象、最小復現、假設清單、逐個排除
，找到根因先改。前端的疑難bug多數離唔開
狀態、渲染時機、引用相等性
呢三類。系統化排查唔會令你寫code更快，但能令你卡住時有路走。
最後verification-before-completion：強制跑清單——所有測試通過、類型檢查冇錯、
真實環境用過、邊界場景試過、console冇warning error
。任何一項未過，就未完成。
前端尤其要在瀏覽器裏真用一遍，類型對測試過唔代表交互對。
串起成條線：點樣固定行呢條路
一個組件從需求到上線，作者固定流程：brainstorming → writing-plans → TDD → systematic-debugging（卡時才用） → verification-before-completion。
每一步都有明確嘅「我而家喺邊一步、要進下一步需要乜」
。簡單需求跳過頭兩步就得。
唔係所有任務都適合呢個流程
以下情況套用五件套反而拖時間：
- 明確嘅小改動：改文案、調樣式、加一個class，直接動手
- 探索性嘗試：試某個庫能用唔用，直接寫demo
- 一次性腳本：臨時拉數據、批量改名，冇必要走完整流程
- 修一個typo：直接改
五件套最適合嘅係
「有不確定性嘅中等任務」——需求模糊、實現路徑多、要排查問題
。呢種任務唔走流程就容易亂。
Skill唔係裝得越多越好用，係用得越有序越好用。
單一個 Skill 調好用就好簡單，難在唔知幾時要用邊個。呢篇講我自己成日用嘅 5 個 Skill 點樣串成一條線，由模糊需求到驗收通過，每一步都有明確嘅入口同出口。
寫喺前面
Skill 越裝越多，問題反而出嚟。
每個 Skill 單獨睇都好有用，但實際寫 code 嘅時候好易唔記得邊個應該喺邊個時候用。好多人需求模糊就直接開幹，卡住就亂試，寫完冇自驗就話完成——呢啲唔係 Skill 唔好用，係冇將佢哋放喺啱嘅位置。
我將自己最常用嘅 5 個 Skill 排咗個順序，固定行呢條線。唔係每次都行曬，但係每一步要去下一步之前，至少知道自己而家喺邊一格。
呢 5 個全部嚟自 superpowers 呢個 Skill 集合，分別係：
下面拎一個真實嘅前端場景串一次：做一個帶表單校驗嘅彈窗組件。
一、brainstorming：先將「模糊」問走
需求嚟嗰陣多數係咁：
「畀我加一個彈窗，俾用戶填 email 同電話號碼。」
聽落好清楚，寫起上嚟成個陷阱。email 必填？電話號碼支援國際號段？校驗失敗提示喺邊度彈？關閉掣要唔要二次確認？提交失敗嘅狀態係點？
需求裏便冇講嘅地方，寫 code 嗰陣都要做決定。先將呢啲問題問出嚟，再決定點寫。我會先叫 brainstorming：
佢會反過嚟問我一大串問題：
我一邊答一邊發現自己其實冇諗清楚。等問完一輪，需求由一句話變成咗一個清楚嘅功能描述。
呢一步嘅入口同出口好明確：
需求冇問清楚，後面三步都係喺錯嘅地基上起樓。
二、writing-plans：將清單變成步驟
需求清楚咗唔等於可以寫。個腦覺得清楚同寫成文字之後清楚係兩件事。
跟住叫 writing-plans：
佢會輸出一個結構化嘅方案，大概係咁：
呢個方案我會讀一次，改兩三個唔啱嘅地方。改完就係我嘅「施工圖」。
呢一步嘅價值唔係叫你照抄，係逼你喺動手前過一次腦。 真係寫嗰陣發現某步唔啱，返嚟改方案再繼續，好過邊寫邊想要順好多。
三、test-driven-development：邊測邊寫
到呢度好多人會直接開始寫組件。我而家習慣先叫 TDD：
佢會先生成測試檔案，例如：
行一次，全部紅（測試失敗）。然後寫最小實現令佢變綠（通過）。呢個過程入面我唔會一開波就諗樣式、動畫、a11y，只會諗「令測試過」。基礎邏輯行得通先補外圍。
TDD 喺前端嘅真實價值唔係「測試覆蓋率」，係逼你先諗清楚組件嘅接口係點樣。 接口諗清楚咗，實現自然順。
四、systematic-debugging：卡住嗰陣按圖索驥
寫到一半總會卡。例如表單值更新咗，但係 input 顯示冇變。
冇流程嘅時候，除錯好易變成「估一下、改一下、睇一下」嘅循環：加幾個 console.log、改改 useState 寫法、將 code 註釋一段再放開，試到啱為止。
叫 systematic-debugging 之後流程會變得好有規矩：
佢會強制行呢幾步：
呢個流程嘅核心係唔畀你喺猜測同修改之間來回跳。猜還猜，改還改，驗還驗，三件事分開做。
前端嘅疑難 bug 多數都離唔開狀態、渲染時機、引用相等性呢三類。 系統化排查唔會令你寫 code 快啲，但係可以令你卡住嘅時候有路行。
五、verification-before-completion：自驗通過先話完成
寫完唔等於完成。類型啱、本地識渲染，離「真係用得」仲差一截。
最後一步永遠叫 verification-before-completion：
佢會強制你行一次清單：
任何一項唔過，就仲未完成。
前端尤其要喺瀏覽器裏面真係用一次。 類型啱、測試過，唔代表交互啱。表單 focus 狀態、loading 時按鈕嘅鼠標態、流動裝置鍵盤彈起之後嘅佈局——呢啲類型檢查發現唔到。
六、串起上嚟到底係點
一個組件由需求到上線，我而家嘅流程固定係咁：
每一步都有明確嘅「我而家喺邊一步、要去下一步需要咩」。卡住嗰陣唔會焦慮，因為知道而家係邊一格。
簡單需求（例如改個文案、調個間距）唔需要行曬，brainstorming 同 plans 跳過就得。但係只要係「做一個新嘢」，五步都過一次可以少好多返工。
七、幾時唔好套呢個流程
唔係所有任務都應該行五件套。下面幾種情況套咗反而拖時間：
五件套適合嘅係「有唔確定性嘅中等任務」——需求模糊、實現路徑唔止一條、出問題要排查。呢種任務唔行流程就易亂。
寫喺最後
Skill 唔係裝得越多越好用，係用得越有序越好用。
單一個 Skill 嘅價值有限，將佢哋按「需求 → 方案 → 實現 → 排錯 → 驗收」呢條線串起嚟，先係工作流。
單個 Skill 調好用很簡單，難的是不知道什麼時候該用哪個。這篇講我自己常用的 5 個 Skill 怎麼串成一條線，從模糊需求到驗收通過，每一步都有明確的入口和出口。
寫在前面
Skill 越裝越多，問題反而出來了。
每個 Skill 單獨看都很有用，但實際寫代碼的時候很容易忘了哪個該在什麼時候用。很多人需求模糊就直接開幹，卡住就亂試，寫完沒自驗就說完成——這些不是 Skill 不好用，是沒把它們放在合適的位置。
我把自己最常用的 5 個 Skill 排了個順序，固定走這條線。不是每次都全走完，但每一步要進下一步之前，至少知道當前在哪一格。
這 5 個全部來自 superpowers 這個 Skill 集合，分別是：
下面拿一個真實的前端場景串一遍：做一個帶表單校驗的彈窗組件。
一、brainstorming：先把"模糊"問沒
需求來的時候大概率是這樣的：
「給我加一個彈窗，讓用戶填郵箱和手機號。」
聽起來很清楚，寫起來全是坑。郵箱必填嗎？手機號支持國際號段嗎？校驗失敗提示在哪兒彈？關閉按鈕要不要二次確認？提交失敗的狀態是什麼樣？
需求裏沒說的地方，寫代碼的時候都要做決定。先把這些問題問出來，再決定怎麼寫。我會先調 brainstorming：
它會反過來問我一堆問題：
我一邊回答一邊發現自己其實沒想清楚。等問完一輪，需求從一句話變成了一個清楚的功能描述。
這一步的入口和出口很明確：
需求沒問清楚，後面三步都是在錯的地基上蓋樓。
二、writing-plans：把清單變成步驟
需求清楚了不等於能寫。腦子裏覺得清楚和寫成文字後清楚是兩件事。
接着調 writing-plans：
它會輸出一份結構化的方案，大概長這樣：
這個方案我會讀一遍，改兩三處不合適的地方。改完就是我的"施工圖"。
這一步的價值不是讓你照着抄，是逼你在動手前過一遍腦。 真寫的時候發現某步不對，回來改方案再繼續，比邊寫邊想要順得多。
三、test-driven-development：邊測邊寫
到這裏很多人會直接開始寫組件。我現在習慣先調 TDD：
它會先生成測試文件，比如：
跑一下，全紅（測試失敗）。然後寫最小實現讓它變綠（通過）。這個過程裏我不會一上來就考慮樣式、動畫、a11y，只考慮"讓測試過"。基礎邏輯跑通了再補外圍。
TDD 在前端的真實價值不是"測試覆蓋率"，是逼你先想清楚組件的接口長什麼樣。 接口想清楚了，實現自然順。
四、systematic-debugging：卡住時按圖索驥
寫到一半總會卡。比如表單值更新了，但 input 顯示沒變。
沒流程的時候，調試很容易變成"猜一下、改一下、看一下"的循環：加幾個 console.log、改改 useState 寫法、把代碼註釋一段再放開，試到對為止。
調 systematic-debugging 之後流程會變得很規矩：
它會強制走這麼幾步：
這個流程的核心是不讓你在猜測和修改之間反覆橫跳。猜歸猜，改歸改，驗歸驗，三件事分開做。
前端的疑難 bug 多半繞不開狀態、渲染時機、引用相等性這三類。 系統化排查不會讓你寫代碼更快，但能讓你卡住的時候有路走。
五、verification-before-completion：自驗通過才說完成
寫完不等於完成。類型對、本地能渲染，離"真的能用"還差一截。
最後一步永遠調 verification-before-completion：
它會強制你跑一遍清單：
任何一項沒過，就還沒完成。
前端尤其要在瀏覽器裏真用一遍。 類型對、測試過，不代表交互對。表單 focus 狀態、loading 時按鈕的鼠標態、移動端鍵盤彈起後的佈局——這些類型檢查發現不了。
六、串起來到底什麼樣
一個組件從需求到上線，我現在的流程固定是這樣的：
每一步都有明確的"我現在在哪一步、要進下一步需要什麼"。卡住的時候不焦慮，因為知道當前格子是哪個。
簡單需求（比如改個文案、調個間距）不需要全走完，brainstorming 和 plans 跳過就行。但只要是"做一個新東西"，五步都過一遍能少不少返工。
七、什麼時候不要套這個流程
不是所有任務都該走五件套。下面幾種情況套了反而拖時間：
五件套適合的是"有不確定性的中等任務"——需求模糊、實現路徑不止一條、出問題要排查。這種任務不走流程就容易亂。
寫在最後
Skill 不是裝得越多越好用，是用得越有序越好用。
單個 Skill 的價值有限，把它們按"需求 → 方案 → 實現 → 排錯 → 驗收"這條線串起來，才是工作流。