技能 receiving-code-review
📦

receiving-code-review

安全

以技術嚴謹性處理程式碼審查回饋

也可從以下取得: Cygnusfear,ZhanlinCui,DYAI2025,obra,davila7,CodingCossack,Cycleaddict

程式碼審查需要技術評估,而非情緒性表現。此技能指導 AI 助理在實作前驗證回饋、提出澄清問題,並在建議技術上不健全時提供有根據的反饋。

支援: Claude Codex Code(CC)
🥉 72 青銅
1

下載技能 ZIP

2

在 Claude 中上傳

前往 設定 → 功能 → 技能 → 上傳技能

3

開啟並開始使用

測試它

正在使用「receiving-code-review」。 審查者:移除舊版 API 版本的舊程式碼路徑

預期結果:

正在檢查相容性需求... 建構目標是 10.15+,但這個 API 需要 13+。舊版路徑仍然是向後相容所必需的。然而,目前的實作有錯誤的 bundle ID。我可以修正 bundle ID,或者我們可以放棄 13 之前的支援。您偏好哪個方向?

正在使用「receiving-code-review」。 審查者:修正 PR 中的第 1-6 項

預期結果:

我理解第 1、2、3 和 6 項。在實作之前我需要澄清第 4 和 5 項。您能詳細說明這兩項需要什麼樣的變更嗎?

正在使用「receiving-code-review」。 審查者:新增適當的錯誤處理,包含重試邏輯和指數後退

預期結果:

已修正。在 api_service.rb:42-58 的 API 呼叫中新增了 Try/Catch 與重試邏輯(3 次嘗試,從 100ms 開始的指數後退)。測試通過。

安全審計

安全
v1 • 2/24/2026

Static analysis flagged 24 instances of backtick patterns and 4 blocker patterns, but all are FALSE POSITIVES. The skill file (SKILL.md) is documentation-only markdown containing instructional text for AI behavior. No executable code, network calls, file operations, or cryptographic functions exist. The backtick patterns are markdown code blocks showing workflow examples, not shell execution. Blocker patterns are misidentified text fragments in documentation.

1
已掃描檔案
219
分析行數
0
發現項
1
審計總數
未發現安全問題
審計者: claude

品質評分

38
架構
100
可維護性
87
內容
32
社群
100
安全
100
規範符合性

你能建構什麼

AI 助理接收人類審查

AI 助理收到人類開發者的程式碼審查回饋時,需要判斷哪些項目應該實作、哪些需要澄清,以及哪些應該以技術理由反饋。

初階開發者學習審查回應

初階開發者學習如何以技術嚴謹性回應資深開發者的回饋,而非表演性同意,在盲目實作前驗證建議。

外部貢獻者處理維護者回饋

外部貢獻者收到專案維護者的回饋時,需要在實作前評估建議是否符合專案架構。

試試這些提示

基本澄清請求
我收到了包含 6 個項目的程式碼審查回饋。我理解第 1、2、3 和 6 項,但在繼續之前需要澄清第 4 和 5 項。您能說明這些特定項目需要什麼樣的變更嗎?
帶有證據的技術反饋
您移除舊版相容層的建議會破壞 macOS 10.15 的支援。目前的實作目標是 10.15+,但使用了需要 13+ 的 API。我應該修正 bundle ID 以維持向後相容,還是完全放棄 13 之前的支援?
實作前的 YAGNI 檢查
審查者建議實作完整的指標追蹤,包含資料庫儲存、日期過濾和 CSV 匯出。我搜尋了程式碼庫,沒有找到這個端點的呼叫者。我應該依照 YAGNI 移除它,還是有我遺漏的使用情境?
錯誤反饋後的優雅修正
我對您的建議提出了反饋,但在檢查測試結果後您是對的。我的理解有誤,因為我忽略了整合測試失敗。現在正在實作修正。

最佳實務

  • 在實作任何變更前,始終針對實際程式碼庫驗證回饋
  • 一次實作一個變更並單獨測試每個變更,以便及早捕捉回歸問題
  • 當建議會破壞現有功能時,以技術理由提出反饋

避免

  • 在驗證回饋之前說「您完全正確!」或「說得好!」
  • 盲目實作回饋而不檢查是否會破壞現有功能
  • 實作第 1-3 和 6 項同時跳過不清楚的第 4-5 項而不先詢問

常見問題

如果程式碼審查回饋不明確,我該怎麼辦?
在實作任何內容之前停下來請求澄清。項目可能是相關的,部分理解會導致錯誤實作。清楚說明哪些項目您理解,哪些需要澄清。
什麼時候適合對審查者回饋提出反饋?
當建議會破壞現有功能、審查者缺乏完整上下文、對未使用功能違反 YAGNI、對您的技術棧技術上不正確,或與架構決策衝突時提出反饋。
如何提出反饋而不顯得防衛?
使用技術推理、提出具體問題、參考運作正常的測試或現有程式碼,如果問題是架構性的則請您的人類夥伴參與。陳述事實,而非情緒。
如果我提出反饋後後來發現錯了怎麼辦?
事實性地承認修正:「您是對的 - 我檢查了 X,它確實做 Y。現在正在實作。」避免長篇道歉或為自己為什麼最初提出反饋辯護。
為什麼我應該避免說謝謝或表演性同意?
行動勝於言語。直接修正問題並展示程式碼變更。表演性同意浪費時間,可能會掩蓋需要解決的實際技術問題。
我應該如何不同地處理外部審查者回饋與我的人類夥伴?
對外部審查者要更加懷疑。檢查建議對您的程式碼庫是否技術上正確、是否不會破壞現有功能,以及審查者是否理解完整上下文。必要時以推理提出反饋。

開發者詳情

檔案結構

📄 SKILL.md