新功能、修 bug、收尾交付：Superpowers 在真實工作的使用套路

寫程式這件事，表面上是「改檔案」，實際上多半是：先搞清楚要幹嘛、再動手、再證明沒炸、最後交出去。Superpowers 那堆 skill 聽起來很多，但在真實工作裡，你可以把它想成一張 「碰到這種事，第一步先叫誰」 的備忘單。這篇不幫你把前面幾篇整本重講一遍，只把最常見的四種情境排成 可照抄的順序；讀完你至少會知道：現在該先啟用哪個流程，而不是一進對話就讓代理亂衝。

情境一：做新功能

第一步：using-superpowers。
不是迷信儀式，是讓代理先走「有 skill 就先讀、有流程就先排」的習慣，避免你一開口它就開始改十個檔。

第二步：需求還在霧裡 → brainstorming。
只要你心裡有一句「其實我也還不確定怎麼做最好」，就先別急著實作。把意圖、限制、取捨攤開，讓選項變成選擇題。

第三步：範圍變大、步驟變多 → writing-plans（或你環境裡對應的「先寫計畫再動手」流程）。
有計畫再實作，返工會少很多；這點在系列的 spec／plan／implementation 那篇會講更細，這裡你只要記：大功能＝先寫路線圖。

第四步：要動程式了 → 依計畫走實作；若你們團隊習慣測試先行，可搭配 test-driven-development。
重點不是背名詞，是 「先定義怎麼算對，再寫到對」。

口訣： 新功能＝先啟用習慣 → 先對焦需求 → 大活先計畫 → 再實作與驗證。

情境二：修 bug

第一步：還是 using-superpowers。
bug 修到一半才發現「根本改錯戰場」超常見，開場先把流程拉起來，心態會穩很多。

第二步：systematic-debugging。
把「猜」換成「有證據的排查」：重現步驟、觀察現象、縮小範圍、驗證假設。新手最常缺的往往不是智商，是 少問一句「我怎麼知道是這裡壞的」。

第三步：找到原因、要改程式前，若改動會牽連多處 → 可回到簡短計畫或至少列出影響面。
小修可以短，但 只要心裡發毛「會不會動到別人」，就多寫兩行取捨說明再動手。

第四步：改完 → verification-before-completion 類型的驗證習慣。
跑過該跑的指令、看過該看的輸出，再說「好了」。這比半夜被同事 tag 療癒多了。

口訣： bug＝先 using-superpowers 開場 → 再系統性除錯 → 改動前想清楚影響 → 說完成前要驗證。

情境三：回應 code review

為什麼這裡第一步寫 receiving-code-review，不像前兩個情境先寫 using-superpowers？白話講：若你和代理已經在同一個任務脈絡裡（例如剛實作完、現在要消化 PR 上的 comment），回 review 本來就是既有流程的「下一步」，直接叫 receiving-code-review 最貼題。相對地，新功能、修 bug 常常是從一片模糊進場，更需要先用 using-superpowers 把「有流程先走」的習慣拉起來。若你是重新開一段對話、或換了一個全新脈絡，心裡沒底時仍然可以先 using-superpowers，確認當下該走哪條 skill，再進 receiving-code-review——兩種做法不衝突，差在 進場時你已經站在流程的哪一站。

第一步：receiving-code-review。
這類 skill 的精神是：先理解回饋在講什麼、哪些必改、哪些要討論，不要一進來就「好的我全改」或「我覺得你不懂」兩極跳。

第二步：需要補測試、補邊界、或改動變大 → 用計畫或清單把「回覆 review 的任務」拆開。
把 review 當成小型需求：每條 comment 對應一個可驗證的結果。

第三步：改完再驗證 → 同樣適用「完成前要有證據」的習慣。
review 的回覆不只是改碼，還包括 你能說清楚「我怎麼確認沒回歸」。

口訣： review＝先讀懂與分類 → 再當任務拆 → 最後用驗證收尾。

情境四：收尾交付

第一步：verification-before-completion。
要 merge、要發版、要交 PR 之前，先跑完你承諾的檢查：測試、lint、手動重現路徑——證據先於口號。

第二步：若改動夠大或牽涉多人 → requesting-code-review（或請另一個代理／同事做結構化審視）。
目的不是找碴，是 在合進主線前再抓一次盲點。

第三步：分支上的工作怎麼收斂 → finishing-a-development-branch 這類「收尾決策」習慣。
合併、開 PR、或先整理 WIP——選一條清楚的路，不要讓分支變成考古現場。

口訣： 交付＝先驗證 → 需要時再請人看 → 最後用明確方式收斂分支。

新手最小可行套路

如果你現在腦容量只夠記一組，那就記這 五個字順序：啟 → 清 → 計 → 做 → 證。

啟： using-superpowers —— 先讓代理進入「會用 skill」的模式。
清：不確定要做什麼就先 brainstorming；不確定哪裡壞就先 systematic-debugging。
計：大任務先寫計畫（writing-plans 一路）。
做：再實作；能測試先行就用 TDD 那套習慣頂著。
證：說做完之前，用 verification-before-completion 的節奏跑一輪；要交出去再加 review／收尾相關流程。

這不是唯一正解，但對初學者來說，最貴的錯誤通常是順序錯了：該釐清時在寫碼、該驗證時在辯論。先把順序站穩，效率會奇怪地變好。

下一步

想從「spec、plan、implementation」把落地流程補齊：spec、plan、implementation 有什麼差別？Superpowers 的正確落地流程。
想搞懂開工前為什麼要先 brainstorming：using-superpowers 與 brainstorming：為什麼不能跳過設計直接開工。
想先把整條路徑與系列地圖一次看清楚：Superpowers 入門課。

回到系列總覽

這篇整理的是 真實工作裡四種常見情境與建議的 skill 順序。若要回到系列的閱讀地圖、建議順序與其他篇主題，請開 Superpowers 入門課。