review-code

🧐 CODE REVIEW MODE (v3)

像鷹眼一樣，根據當前戰況和記憶體庫中的情報，選擇最適合的箭矢，精準打擊程式碼中的潛在問題。

1. PLAN 🎯 (規劃)

Objective

對指定的程式碼變更，進行一次有重點、有上下文、基於啟發式規則的全面審查，並產出一份可直接使用的、結構化的審查報告。此指令不直接寫入 memory-bank，但會大量讀取其中的上下文來提供高質量的反饋。

Guiding Rules

在執行此指令時，AI Agent 必須遵循以下規則：

• 主要規則: .cursor/rules/principles/global.mdc
• 程式碼品質: 相關的 .cursor/rules/backend/overview.mdc 或 .cursor/rules/frontend/overview.mdc
• 測試標準: .cursor/rules/testing/overview.mdc
• 核心隔離: .cursor/rules/isolation_rules/main.mdc

Prerequisites Check

在開始審查之前，請確保：

• ✅ 程式碼已就緒: 有一個清晰的、待審查的程式碼變更集 (PR, diff)。
• ✅ CI/CD 通過: Linter、單元測試等自動化檢查已通過。
• ❌ Failure Action: 如果 CI/CD 失敗，AI 必須拒絕審查，並指出：「自動化檢查失敗。請作者先修復 CI 問題，我才能進行有意義的審查。」

2. DO 実行 (執行)

Core Process

遵循一個包含批判性思維的、上下文驅動的審查流程：

Step 0: 健康檢查 (Health Check)

• 檢查上下文: 審查的程式碼是否附帶了足夠的說明？（如 PR 描述、關聯的 tasks.md ID）。
• 批判性思考: 如果程式碼的意圖不明，AI 必須先提問。例如：「這個變更的 PR 描述是空的，也沒關聯任何任務 ID。為了避免誤解，您能簡要說明一下這個變更的目標是什麼嗎？」

Step 1: 記憶體互動 - 讀取 (Memory Interaction - Read)

• 讀取程式碼變更 (Diff): 這是審查的主要對象。
• 讀取相關記憶:
  • memory-bank/current/tasks.md: 了解此變更對應的任務要求。
  • memory-bank/current/creative-*.md: 了解背後的設計決策。
  • memory-bank/current/projectbrief.md: 理解此變更如何服務於整個專案的目標。
• 這一讀取步驟至關重要，它能讓 AI 的審查超越語法層面，進入設計和架構層面。

Step 2: 確定審查重點 (Determine Review Focus)

• 根據程式碼變更的目的（讀取自 tasks.md 或用戶說明），從 Appendix A 中選擇 1-3 個最相關的「壞味道」分類作為本次審查的重點。

Step 3: 應用啟發式規則 (Apply Heuristics)

• 重點審查: 根據選擇的重點分類，使用 Appendix A 中的術語，逐一檢查程式碼。
• 全面基礎審查: 快速過一遍功能正確性、安全性和測試覆蓋等基本盤。

Step 4: 產出審查報告 (Generate Review Report)

• 不寫入記憶體: 將審查報告格式化為一份獨立的 Markdown 文件。這份報告是輸出，而不是要寫入 memory-bank 的狀態。用戶可以方便地將其複製到 GitHub/GitLab。
• 報告應包含：審查重點、優點、必須修改點 (🔴)、建議改進點 (🟡) 和具體範例。

3. CHECK ✓ (檢查)

Verification Checklist

• 反饋是否聚焦: 報告是否清晰地圍繞著選定的重點？
• 是否引用記憶: 審查意見是否體現了 AI 已理解 tasks.md 和 creative-*.md 中的上下文？
• 建議是否具體: 是否為關鍵問題提供了來自 Appendix A 的術語和具體修改建議？
• 輸出格式是否正確: 審查報告是否是一個格式良好、可直接複製的 Markdown 塊？