everything-claude-code/docs/zh-TW/commands/plan.md

description

description
Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.

Plan 指令

此指令呼叫 planner Agent，在撰寫任何程式碼前建立全面的實作計畫。

此指令的功能

1. 重述需求 - 釐清需要建構什麼
2. 識別風險 - 揭示潛在問題和阻礙
3. 建立步驟計畫 - 將實作拆解為階段
4. 等待確認 - 必須在繼續前收到使用者批准

何時使用

在以下情況使用 /plan：

• 開始新功能
• 進行重大架構變更
• 進行複雜重構
• 多個檔案/元件會受影響
• 需求不清楚或模糊

運作方式

planner Agent 會：

1. 分析請求並以清晰的語言重述需求
2. 拆解為階段，包含具體、可執行的步驟
3. 識別相依性元件之間的關係
4. 評估風險和潛在阻礙
5. 估計複雜度（高/中/低）
6. 呈現計畫並等待您明確確認

使用範例

使用者：/plan 我需要在市場解決時新增即時通知

Agent（planner）：
# 實作計畫：即時市場解決通知

## 需求重述
- 當使用者關注的市場解決時發送通知
- 支援多個通知管道（應用內、Email、Webhook）
- 確保通知可靠送達
- 包含市場結果和使用者持倉結果

## 實作階段

### 階段 1：資料庫結構描述
- 新增 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（用於佇列）
- Email 服務（SendGrid/Resend）
- Supabase 即時訂閱

## 風險
- 高：Email 送達率（需要 SPF/DKIM）
- 中：每個市場 1000+ 使用者時的效能
- 中：如果市場頻繁解決可能造成通知垃圾訊息
- 低：即時訂閱的開銷

## 估計複雜度：中
- 後端：4-6 小時
- 前端：3-4 小時
- 測試：2-3 小時
- 總計：9-13 小時

**等待確認**：繼續此計畫？（是/否/修改）

重要提醒

關鍵：planner Agent 不會撰寫任何程式碼，直到您明確以「是」、「繼續」或類似肯定回應確認計畫。

如果您想要修改，回應：

• "修改：[您的變更]"
• "不同的方法：[替代方案]"
• "跳過階段 2，先做階段 3"

與其他指令的整合

計畫後：

• 使用 /tdd 以測試驅動開發實作
• 如果發生建置錯誤，使用 /build-fix
• 使用 /code-review 審查完成的實作

相關 Agent

此指令呼叫位於以下位置的 planner Agent： ~/.claude/agents/planner.md