---
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`