114 lines
3.5 KiB
Markdown
114 lines
3.5 KiB
Markdown
|
---
|
|||
|
|
description: 重申需求、評估風險並建立逐步實作計畫。在開始修改任何程式碼之前，必須等待使用者確認。
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 規劃指令 (Plan Command)
|
|||
|
|
|
|||
|
|
此指令會呼叫 **planner** agent，在撰寫任何程式碼之前建立一份全面的實作計畫。
|
|||
|
|
|
|||
|
|
## 此指令的功能
|
|||
|
|
|
|||
|
|
1. **重申需求** - 澄清需要建置的內容。
|
|||
|
|
2. **識別風險** - 找出潛在的問題與阻礙。
|
|||
|
|
3. **建立步驟計畫** - 將實作拆解為多個階段。
|
|||
|
|
4. **等待確認** - 在繼續之前，必須獲得使用者的核准。
|
|||
|
|
|
|||
|
|
## 何時使用
|
|||
|
|
|
|||
|
|
在以下情況使用 `/plan`：
|
|||
|
|
- 開始一項新功能開發時。
|
|||
|
|
- 進行重大架構變更時。
|
|||
|
|
- 處理複雜的重構任務時。
|
|||
|
|
- 會影響多個檔案/元件時。
|
|||
|
|
- 需求不明確或存在歧義時。
|
|||
|
|
|
|||
|
|
## 運作原理
|
|||
|
|
|
|||
|
|
Planner agent 會執行以下操作：
|
|||
|
|
|
|||
|
|
1. **分析請求**並以清晰的術語重申需求。
|
|||
|
|
2. **拆解為多個階段**，包含具體且可執行的步驟。
|
|||
|
|
3. **識別元件之間的依賴關係**。
|
|||
|
|
4. **評估風險**與潛在的阻礙因素。
|
|||
|
|
5. **估算複雜度** (高/中/低)。
|
|||
|
|
6. **展示計畫**並等待您的明確確認。
|
|||
|
|
|
|||
|
|
## 使用範例
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
使用者：/plan 我需要在市場結算時加入即時通知功能
|
|||
|
|
|
|||
|
|
Agent (planner)：
|
|||
|
|
# 實作計畫：即時市場結算通知
|
|||
|
|
|
|||
|
|
## 需求重申
|
|||
|
|
- 當使用者關注的市場結算時，向其發送通知
|
|||
|
|
- 支援多種通知管道 (App 內、電子郵件、Webhook)
|
|||
|
|
- 確保通知可靠送達
|
|||
|
|
- 包含市場結果與使用者的部位狀況
|
|||
|
|
|
|||
|
|
## 實作階段
|
|||
|
|
|
|||
|
|
### 階段 1：資料庫 Schema
|
|||
|
|
- 新增 notifications 表格，包含：id, user_id, market_id, type, status, created_at
|
|||
|
|
- 新增 user_notification_preferences 表格，用於儲存管道偏好
|
|||
|
|
- 在 user_id 和 market_id 上建立索引以優化性能
|
|||
|
|
|
|||
|
|
### 階段 2：通知服務
|
|||
|
|
- 在 lib/notifications.ts 中建立通知服務
|
|||
|
|
- 使用 BullMQ/Redis 實作通知佇列
|
|||
|
|
- 為發送失敗加入重試邏輯
|
|||
|
|
- 建立通知模板
|
|||
|
|
|
|||
|
|
### 階段 3：整合點
|
|||
|
|
- 介入市場結算邏輯 (當狀態變更為 \"resolved\" 時)
|
|||
|
|
- 查詢在該市場中持有部位的所有使用者
|
|||
|
|
- 為每位使用者將通知加入佇列
|
|||
|
|
|
|||
|
|
### 階段 4：前端元件
|
|||
|
|
- 在頁首建立 NotificationBell 元件
|
|||
|
|
- 新增 NotificationList 彈窗
|
|||
|
|
- 透過 Supabase 即時訂閱實作即時更新
|
|||
|
|
- 新增通知偏好設定頁面
|
|||
|
|
|
|||
|
|
## 依賴項
|
|||
|
|
- Redis (用於佇列)
|
|||
|
|
- 電子郵件服務 (SendGrid/Resend)
|
|||
|
|
- Supabase 即時訂閱
|
|||
|
|
|
|||
|
|
## 風險評估
|
|||
|
|
- 高 (HIGH)：電子郵件送達率 (需要設定 SPF/DKIM)
|
|||
|
|
- 中 (MEDIUM)：每個市場超過 1000 名使用者時的效能問題
|
|||
|
|
- 中 (MEDIUM)：若市場結算頻繁，可能造成通知騷擾 (Notification spam)
|
|||
|
|
- 低 (LOW)：即時訂閱的額外負擔
|
|||
|
|
|
|||
|
|
## 預估複雜度：中 (MEDIUM)
|
|||
|
|
- 後端：4-6 小時
|
|||
|
|
- 前端：3-4 小時
|
|||
|
|
- 測試：2-3 小時
|
|||
|
|
- 總計：9-13 小時
|
|||
|
|
|
|||
|
|
**正在等待確認**：是否執行此計畫？ (yes/no/modify)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 重要注意事項
|
|||
|
|
|
|||
|
|
**關鍵 (CRITICAL)**：在您明確以 "yes"、"proceed" 或類似的肯定回覆確認計畫之前，Planner agent **不會**撰寫任何程式碼。
|
|||
|
|
|
|||
|
|
如果您希望進行調整，請回覆：
|
|||
|
|
- "modify: [您的變更內容]"
|
|||
|
|
- "different approach: [替代方案]"
|
|||
|
|
- "skip phase 2 and do phase 3 first" (跳過階段 2，先執行階段 3)
|
|||
|
|
|
|||
|
|
## 與其他指令的整合
|
|||
|
|
|
|||
|
|
規劃完成後：
|
|||
|
|
- 使用 `/tdd` 透過測試驅動開發進行實作。
|
|||
|
|
- 若出現建置錯誤，請使用 `/build-fix`。
|
|||
|
|
- 使用 `/code-review` 審查完成的實作。
|
|||
|
|
|
|||
|
|
## 相關 Agent
|
|||
|
|
|
|||
|
|
此指令會呼叫位於以下路徑的 `planner` agent：
|
|||
|
|
`~/.claude/agents/planner.md`
|