Shrimp Task Manager

## 任務分析 你必須依序完成以下子步驟，並在最後呼叫 `analyze_task` 工具，將初步設計方案傳遞給下一階段。 1. **分析目的** - 讀取並理解： ``` 任務說明：{description} 任務要求與限制：{requirements} {tasksTemplate} ``` - 確認： - 任務目標與預期成果 - 技術挑戰與關鍵決策點 - 與現有系統／架構的整合需求 2. **識別專案架構** - 查看關鍵配置文件與結構： - 檢視根目錄結構和重要配置文件（package.json, tsconfig.json 等） - 如果 shrimp-rules.md 存在請詳細閱讀並參考 - 分析主要的目錄組織和模組劃分 - 辨識架構模式： - 識別核心設計模式和架構風格（MVC, MVVM, 微服務等） - 確定專案的分層結構和模組邊界 - 分析核心組件： - 研究主要類別/接口設計與依賴關係 - 標記關鍵服務/工具類及其職責和用途 - 記錄既有模式： - 記錄發現的代碼組織方式和架構規律 - 建立對專案技術棧和架構特性的深入理解 3. **收集資訊** 如有任何不確定或信心不足，**必做其一**： - 向用戶提問以釐清 - 使用 `query_task`、`read_file`、`codebase_search`或其他類似的工具查詢現有程式／架構 - 使用 `web_search` 或其他網路搜尋工具查詢不熟悉的概念或技術 禁止憑空臆測，所有資訊必可追溯來源。 4. **檢查現有程式與結構** - 使用精確的搜索策略： - 利用 `read_file`、`codebase_search`或其他類似的工具查詢與任務相關的現有實現方式 - 尋找與當前任務功能類似的現有代碼 - 分析目錄結構尋找相似功能模組 - 分析代碼風格與約定： - 檢查現有組件的命名規則（駝峰式、蛇形等） - 確認註釋風格和格式約定 - 分析錯誤處理模式和日誌記錄方式 - 記錄並遵循發現的模式： - 詳細記錄代碼模式和組織結構 - 計劃如何沿用這些模式進行設計 - 判斷是否與現有功能重疊，並決定「重用」或「抽象重構」 - **不得**先生成設計再查現有碼；必須「先查再設」 5. **任務類型特定指南** 根據任務特性，額外考慮以下特定指南： - **前端/UI 任務**： - 優先查看現有 UI 組件庫和設計系統 - 分析頁面佈局結構和元件組合模式 - 確認樣式管理方式（CSS 模組、Styled Components 等） - 理解狀態管理和數據流模式 - **後端 API 任務**： - 檢查 API 路由結構和命名約定 - 分析請求處理和中間件模式 - 確認錯誤處理和響應格式標準 - 理解授權/身份驗證實現方式 - **數據庫操作**： - 分析現有的數據訪問模式和抽象層 - 確認查詢構建和事務處理方式 - 理解關聯關係處理和數據驗證方法 - 檢查緩存策略和效能優化手段 6. **初步方案產出** - 根據上述，撰寫「初步設計方案」： - 清楚標示 **事實**（來源） vs **推論**（選擇依據） - 禁止模糊語句，須為最終可交付成果 - 確保方案與專案既有架構模式一致 - 說明如何重用現有組件或遵循現有模式 - 過程必須一步一步思考並梳理思緒，如果問題過於複雜可以利用`process_thought`來思考 - **嚴重警告**：禁止一切`假設`與`猜測`與`幻想`，你必須透過一切你`可以使用的工具`來`收集資訊` - 呼叫工具： ``` analyze_task({ summary: <任務摘要>, initialConcept: <初步構想> }) ``` **現在開始呼叫 `analyze_task`，嚴禁不呼叫工具**