Name: review-code
Author: Zenobia000

Prompt file imported from Zenobia000/cursor-agentic-coding-template (.cursor/commands/review-code.md). Copyright stays with the author.

🧐 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 塊？

4. ACT 改善 (行動)

Finalization

向用戶交付報告: AI 在完成後，應告知用戶：「程式碼審查已完成。以下是審查報告，您可以將其複製到您的 Pull Request 中。」

Next Steps

程式碼審查是推動品質內建的關鍵活動。

👉 Primary Next Step: 等待作者根據反饋修改程式碼，然後再次執行 /review-code 進行第二輪審查。
💡 Alternative: 如果審查中發現了嚴重的設計問題，應建議執行 /creative 模式，對該部分進行重新設計。

Appendix A: Code Smell & Engineering Heuristics

(The appendix from v2 remains here, unchanged) ... (略)

Install review-code and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# 🧐 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 塊？ ## 4. ACT 改善 (行動) ### Finalization - **向用戶交付報告:** AI 在完成後，應告知用戶：「程式碼審查已完成。以下是審查報告，您可以將其複製到您的 Pull Request 中。」 ### Next Steps > 程式碼審查是推動品質內建的關鍵活動。 - 👉 **Primary Next Step:** 等待作者根據反饋修改程式碼，然後再次執行 `/review-code` 進行第二輪審查。 - 💡 **Alternative:** 如果審查中發現了嚴重的設計問題，應建議執行 `/creative` 模式，對該部分進行重新設計。 --- ## Appendix A: Code Smell & Engineering Heuristics (The appendix from v2 remains here, unchanged) ... (略)

{ "prompt": "# 🧐 CODE REVIEW MODE (v3)\n\n> 像鷹眼一樣，根據當前戰況和記憶體庫中的情報，選擇最適合的箭矢，精準打擊程式碼中的潛在問題。\n\n## 1. PLAN 🎯 (規劃)\n\n### Objective\n> 對指定的程式碼變更，進行一次**有重點、有上下文、基於啟發式規則**的全面審查，並產出一份可直接使用的、結構化的審查報告。此指令**不直接寫入** `memory-bank`，但會**大量讀取**其中的上下文來提供高質量的反饋。\n\n### Guiding Rules\n> 在執行此指令時，AI Agent 必須遵循以下規則：\n- **主要規則:** `.cursor/rules/principles/global.mdc`\n- **程式碼品質:** 相關的 `.cursor/rules/backend/overview.mdc` 或 `.cursor/rules/frontend/overview.mdc`\n- **測試標準:** `.cursor/rules/testing/overview.mdc`\n- **核心隔離:** `.cursor/rules/isolation_rules/main.mdc`\n\n### Prerequisites Check\n> 在開始審查之前，請確保：\n- ✅ **程式碼已就緒:** 有一個清晰的、待審查的程式碼變更集 (PR, diff)。\n- ✅ **CI/CD 通過:** Linter、單元測試等自動化檢查已通過。\n- ❌ **Failure Action:** 如果 CI/CD 失敗，AI **必須拒絕審查**，並指出：「自動化檢查失敗。請作者先修復 CI 問題，我才能進行有意義的審查。」\n\n## 2. DO 実行 (執行)\n\n### Core Process\n> 遵循一個包含批判性思維的、上下文驅動的審查流程：\n\n**Step 0: 健康檢查 (Health Check)**\n- **檢查上下文:** 審查的程式碼是否附帶了足夠的說明？（如 PR 描述、關聯的 `tasks.md` ID）。\n- **批判性思考:** 如果程式碼的意圖不明，AI **必須先提問**。例如：「這個變更的 PR 描述是空的，也沒關聯任何任務 ID。為了避免誤解，您能簡要說明一下這個變更的目標是什麼嗎？」\n\n**Step 1: 記憶體互動 - 讀取 (Memory Interaction - Read)**\n- **讀取程式碼變更 (Diff):** 這是審查的主要對象。\n- **讀取相關記憶:**\n - `memory-bank/current/tasks.md`: 了解此變更對應的任務要求。\n - `memory-bank/current/creative-*.md`: 了解背後的設計決策。\n - `memory-bank/current/projectbrief.md`: 理解此變更如何服務於整個專案的目標。\n- 這一**讀取**步驟至關重要，它能讓 AI 的審查**超越語法層面，進入設計和架構層面**。\n\n**Step 2: 確定審查重點 (Determine Review Focus)**\n- 根據程式碼變更的目的（讀取自 `tasks.md` 或用戶說明），從 `Appendix A` 中選擇 1-3 個最相關的「壞味道」分類作為本次審查的重點。\n\n**Step 3: 應用啟發式規則 (Apply Heuristics)**\n- **重點審查:** 根據選擇的重點分類，使用 `Appendix A` 中的術語，逐一檢查程式碼。\n- **全面基礎審查:** 快速過一遍功能正確性、安全性和測試覆蓋等基本盤。\n\n**Step 4: 產出審查報告 (Generate Review Report)**\n- **不寫入記憶體:** 將審查報告格式化為一份獨立的 Markdown 文件。這份報告是**輸出**，而不是要寫入 `memory-bank` 的狀態。用戶可以方便地將其複製到 GitHub/GitLab。\n- 報告應包含：審查重點、優點、必須修改點 (`🔴`)、建議改進點 (`🟡`) 和具體範例。\n\n## 3. CHECK ✓ (檢查)\n\n### Verification Checklist\n- [ ] **反饋是否聚焦:** 報告是否清晰地圍繞著選定的重點？\n- [ ] **是否引用記憶:** 審查意見是否體現了 AI 已理解 `tasks.md` 和 `creative-*.md` 中的上下文？\n- [ ] **建議是否具體:** 是否為關鍵問題提供了來自 `Appendix A` 的術語和具體修改建議？\n- [ ] **輸出格式是否正確:** 審查報告是否是一個格式良好、可直接複製的 Markdown 塊？\n\n## 4. ACT 改善 (行動)\n\n### Finalization\n- **向用戶交付報告:** AI 在完成後，應告知用戶：「程式碼審查已完成。以下是審查報告，您可以將其複製到您的 Pull Request 中。」\n\n### Next Steps\n> 程式碼審查是推動品質內建的關鍵活動。\n- 👉 **Primary Next Step:** 等待作者根據反饋修改程式碼，然後再次執行 `/review-code` 進行第二輪審查。\n- 💡 **Alternative:** 如果審查中發現了嚴重的設計問題，應建議執行 `/creative` 模式，對該部分進行重新設計。\n\n---\n\n## Appendix A: Code Smell & Engineering Heuristics\n(The appendix from v2 remains here, unchanged)\n... (略)", "variables": [], "notes": "CODE REVIEW - Context-aware, heuristic-based code review with explicit memory interaction.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/Zenobia000/cursor-agentic-coding-template", "path": ".cursor/commands/review-code.md", "ref": "fcb47ed223d57b61f1ac182c90a0141b03fd5713", "url": "https://github.com/Zenobia000/cursor-agentic-coding-template/blob/fcb47ed223d57b61f1ac182c90a0141b03fd5713/.cursor/commands/review-code.md", "key": "Zenobia000/cursor-agentic-coding-template/.cursor/commands/review-code.md" } } }

review-code

About