receiving-code-review

receiving-code-review 技能總覽

receiving-code-review 技能是做什麼用的

receiving-code-review 技能的目的，是讓 AI 在面對 code review feedback 時，用技術判斷與紀律回應，而不是下意識先同意再說。它做的事其實很單純，但非常有價值：當 reviewer 提出修改建議時，agent 應該先理解對方要求的是什麼、拿實際程式碼與 repo 現況驗證，再決定是要實作、提問，還是合理地提出異議。

這在 review comment 含糊、部分有誤、彼此衝突，或是如果照單全收會有風險時特別有用。receiving-code-review 技能的重點，不是讓你在 PR 討論串裡顯得客氣有禮，而是避免因為「你說得對，我來修」這種社交反射，在問題還沒驗證前就做出錯誤修改。

最適合的使用者

這個技能特別適合：

• 用 AI 協助處理 PR comments 的開發者
• 希望少一點表面附和、多一點技術正確性的團隊
• 在成熟 codebase 中工作的 agent，因為 reviewer 的建議不一定符合本地約束
• 想要一套可重複的 review response workflow，而不只是換個比較好看的 prompt 的使用者

如果你的主要痛點是「模型太快照著 reviewer feedback 改，結果把東西改壞」，那這個技能就是直接針對這種失敗模式設計的。

真正要解決的工作

多數使用者其實不需要 AI 幫忙「讀懂一則 comment」。他們真正需要的是幫忙判斷：

• reviewer 實際上想表達什麼
• 這個建議對這個 repository 來說是否正確
• 在動手修改之前，是否需要先釐清
• 如果 reviewer 的說法有誤或不完整，該怎麼回應
• 如果 feedback 合理，要怎麼安全地實作

這就是 receiving-code-review 技能的實際價值：它把 review feedback 的接收流程，轉成一個驗證導向的 workflow。

這個技能和一般 review prompt 有什麼不同

一般 prompt 常常會把模型推向「先配合再說」：摘要 feedback、感謝 reviewer，然後開始改程式。這個技能則強制一套回應模式：

1. 先讀完整 feedback
2. 重述需求
3. 對照 codebase 現況驗證
4. 評估技術上是否適合
5. 以確認、提問或有根據的異議來回應
6. 一次只實作一個項目

它也明確禁止一些常見但低價值的回應，例如過度稱讚 reviewer，或是在還沒驗證前就立刻承諾會修改。

安裝前你需要知道的事

這是一個用途很聚焦、也很輕量的技能。它不附帶 helper scripts、參考資料，或 repository-specific rules。這對想快速採用的人來說是優點，但也代表輸出品質非常仰賴你提供的 review comment 與程式碼上下文。

請把這個技能理解成 Code Review workflow 的行為護欄，而不是完整的 code review 自動化框架。

如何使用 receiving-code-review 技能

如何安裝 receiving-code-review 技能

從 obra/superpowers repository 安裝：

npx skills add https://github.com/obra/superpowers --skill receiving-code-review

如果你的環境使用不同的 skill loader，請從這裡加入此技能：

https://github.com/obra/superpowers/tree/main/skills/receiving-code-review

由於這個 repository 對此技能只提供 SKILL.md，所以安裝與檢視都很直接。

在 repository 裡先看什麼

如果你正在評估 receiving-code-review install，建議先看：

• skills/receiving-code-review/SKILL.md

這個檔案幾乎包含了所有真正有用的行為規則：

• 核心原則
• 回應模式
• 禁止的回應
• 面對不清楚 feedback 時的處理規則

因為沒有額外的 rules/、resources/ 或支援腳本需要先理解，所以上手成本很低。

實務上什麼時候該啟用 receiving-code-review

最適合使用 receiving-code-review skill 的時機，是 feedback 剛進來、還沒開始改程式的那一刻。

很適合觸發的情境包括：

• 「Please simplify this logic.」
• 「This should use a transaction.」
• 「Fix comments 1–6.」
• 「Why not just cache this?」
• 「Use pattern X instead.」

尤其在以下情況更應該啟用：

• comments 是一批一起來的
• 有些項目不夠清楚
• reviewer 可能不熟本地的架構限制
• AI 很容易忍不住立刻開始 patch

這個技能需要什麼輸入

當你提供以下四種資訊時，這個技能通常表現最好：

1. 原始 review feedback
2. 受影響的 file paths 或 diff
3. codebase 裡相關的限制條件
4. 你希望它做的下一步

實用的輸入包括：

• 原封不動貼上的 PR comments
• 目前的實作內容
• test failure 或效能限制
• 可能和建議衝突的架構規則
• 你想要的是回覆草稿、技術評估，還是實作協助

如果缺少 codebase context，這個技能仍然可以幫你解讀 comment，但在驗證技術適配性時就會弱很多。

把模糊需求改寫成強 prompt

弱 prompt：

Handle this review feedback.

更強的 prompt：

Use the receiving-code-review skill.

Review feedback:
"Please combine these queries and move validation into the controller."

Context:
- Files: app/services/order_sync.rb, app/controllers/orders_controller.rb
- Current pattern: validation is intentionally kept out of controllers
- This code handles retry behavior and partial failures
- I want to know whether the suggestion is correct for this codebase

Please:
1. Restate what the reviewer is asking
2. Identify any ambiguity
3. Verify the suggestion against the current design
4. Recommend whether to implement, ask a question, or push back
5. If valid, propose the smallest safe change

這種寫法效果更好，因為它給了技能完成關鍵步驟所需的素材：不是只做改寫或摘要，而是真正去驗證。

一套實用的 receiving-code-review 工作流程

一個可靠的 receiving-code-review usage 流程大致如下：

1. 貼上完整的 review thread 或 comment batch
2. 要求 agent 先把明確項目與不明確項目分開
3. 要求它重述每一個要求修改的點
4. 讓它逐項對照 codebase 檢查
5. 請它給出建議：實作、釐清，或不同意
6. 只有在這之後，才開始進入修改，而且一次只處理一個問題

這可以避免一種常見錯誤：在還沒真正理解整批 comments 的情況下，就先部分實作其中幾項。

receiving-code-review 如何處理不清楚或綁在一起的 comments

這個技能最強的一個觀念是：只要有任何一項不清楚，就先停下來，不要實作。

這在真實 PR 裡很重要，因為 comments 常常彼此有關聯。假設 reviewer 說「Fix points 1–6」，但其中 4–5 不夠清楚，那麼先改 1–3 和 6，反而可能把你鎖進錯的方向。

這裡可以用一個很強的 prompt：

Use receiving-code-review. Group this feedback into:
- clear and ready to verify
- unclear and needs clarification
Do not recommend implementation until all linked items are understood.

這個技能的好輸出應該長什麼樣子

好的結果，不會只是「Thanks, great catch.」而已。它應該包含：

• 對 reviewer 技術要求的清楚重述
• 其中的假設或模糊點
• 對實際程式碼的驗證
• 有理由的判斷結果
• 接著給出釐清問題、尊重但明確的異議，或安全的實作方案

如果輸出直接從 comment 跳到 code change，那就表示這個技能沒有被正確使用。

適合 Code Review 工作的 prompt 範本

可以依照你的目標使用不同模式。

如果只想做評估：

Use the receiving-code-review skill to evaluate whether this review comment is technically correct for this repository. Do not implement yet.

如果要起草回覆：

Use the receiving-code-review skill to write a concise technical reply to this PR comment. Avoid praise language. Ask for clarification if needed.

如果是在驗證後才進入實作：

Use the receiving-code-review skill. First verify the reviewer's request against the codebase. If valid, propose the smallest testable change and list risks before editing.

能明顯提升輸出品質的實務技巧

一些小幅度的輸入升級，效果其實差很多：

• 放入 reviewer 的原話，不要只給你自己的轉述
• 提供相鄰程式碼，不要只貼目標 function
• 說清楚 reviewer 在談的是 style、correctness、performance，還是 architecture
• 告訴模型你們 codebase 裡哪些原則不能動
• 要它指出 reviewer 可能建立在哪些未被證實的前提上

當 agent 能把要求中的變更，和 repository 的實際狀況做對照時，這個技能會明顯更準。

receiving-code-review 技能常見問題

receiving-code-review 只適合拿來回覆 PR 裡的人類嗎？

不是。它同樣很適合用在你正式回覆之前的內部判讀。很多情況下，receiving-code-review 最好的第一步其實是私下使用：先判斷這則 comment 到底是正確、不完整，還是照做有風險，再決定要不要公開回應。

這個技能對新手友善嗎？

是的，但有一個前提。這套流程本身很容易理解，不過新手仍可能缺乏足夠的技術背景，無法判斷 feedback 是否符合 codebase。這個技能能提升處理上的紀律，但不能取代工程判斷。

它和一般「analyze this PR feedback」這類 prompt 差在哪裡？

關鍵差別在於它內建了「拒絕秒同意」的機制。SKILL.md 裡的 receiving-code-review guide 核心放在驗證、釐清，以及有依據的異議。一般 prompt 往往優先追求社交上順暢的語氣，而不是技術上的正確性。

什麼情況下不該使用 receiving-code-review 技能？

如果任務已經完全定義清楚，而且執行上幾乎沒有風險，就可以跳過，例如：

• 修一個明顯的 typo
• 重新命名一個不影響行為的 symbol
• 遵循團隊已明文確認的慣例

另外，這也不是拿來對別人的程式做完整 outbound code review 的工具。這個技能非常明確，是用來幫你「接收 feedback」接得更好。

如果 reviewer 說錯了，receiving-code-review 幫得上忙嗎？

可以，而且這正是它最強的用途之一。這個技能鼓勵的是有理有據的技術回應，而不是防衛性的口氣，也不是自動配合。如果 reviewer 的建議和 codebase 衝突，你應該預期 agent 會解釋原因，並提出更清楚的回覆方式。

它支援整批 review feedback 嗎？

支援，但前提是你要提供完整的一批內容，並讓技能先把明確與不明確的項目拆開。這個技能非常強調：只要理解仍然是局部的，就不應該開始實作。這對「把這些 comments 全部修掉」這類情境尤其有用。

如何改進 receiving-code-review 技能的使用效果

給技能 repository 的真實脈絡，不要只丟 reviewer 文字

想最快提升 receiving-code-review 的輸出品質，最有效的方法就是把 comments 搭配以下資訊一起提供：

• file paths
• 目前的實作片段
• 限制條件
• tests
• 相關架構模式

如果一個 review suggestion 會牽涉本地設計決策，那就不可能只靠抽象文字來判斷對錯。

不要只要摘要，要它做判斷

很多表現不佳的執行結果，都是因為 prompt 只叫 agent 「處理」feedback。更好的做法，是強迫它做選擇：

• 實作
• 提一個釐清問題
• 提出有理由的異議
• 因缺少上下文而暫緩

這樣 receiving-code-review 才會變成可操作的 workflow，而不只是描述性摘要。

主動防止最常見的失敗模式

最大的失敗模式，就是太早開始實作。模型看到 reviewer suggestion 就開始改，但還沒檢查：

• reviewer 是否真的理解目前程式碼
• 限制條件是否讓這個建議不成立
• 其他 comments 是否會改變這句話的意思
• 這個要求的修改是否有隱藏副作用

請明確告訴 agent：Do not implement until verification is complete.

面對含糊的 review thread，提供更強的輸入框架

如果 feedback 很模糊，請自己補上必要的判讀框架：

Use receiving-code-review.

The reviewer says: "This flow should be simplified."
Please identify at least 3 plausible interpretations, map each to the current code, and tell me what clarification question would unblock implementation safely.

這比起叫模型自己猜一種意思，然後直接往下做，要好得多。

要求異議簡短、技術導向、以證據為基礎

如果 reviewer 錯了，最好的輸出通常是短、準、而且有證據。你可以要求它提供：

• reviewer 看起來正在假設什麼
• codebase 裡哪個事實和這個假設衝突
• 一段最小但足夠尊重的回覆，說明這個落差

這樣可以讓 receiving-code-review for Code Review 的流程保持實用，而不會變成對立或情緒化。

第一輪回答後，再補缺的資訊重跑

第一輪做完之後，如果還有不足，就補上真正缺的那一塊資訊：

• reviewer 意圖仍不清楚
• 缺少程式碼片段
• 架構限制沒說明
• 缺少 test 證據
• diff context 不完整

一個很實用的第二輪 prompt 是：

Re-run receiving-code-review with this added context. Update your recommendation and tell me whether the original review comment is now clear enough to implement.

先驗證，再搭配實作技能

最好的採用方式，是分成兩階段：

1. 先用 receiving-code-review 評估 comment
2. 確認之後再要求修改程式碼

這種切分可以提高信任感，因為你能先檢查 reasoning，再讓模型動手改檔案。

把這個技能當成團隊標準，而不是一次性 prompt

如果你的團隊想讓 AI 在 PR workflow 裡有一致行為，可以把這個技能變成處理 inbound review 的預設指令：

• 不要先稱讚再說
• 不要盲目實作
• 不清楚就先問
• 對照本地程式碼驗證
• 技術上站得住腳時就提出異議

這也是 receiving-code-review skill 最有長期價值的地方：不是一次性的 prompt 技巧，而是一種可重複執行的操作習慣。