指令用途
/to-tickets 將計畫、規格或當前的對話內容拆分成一組獨立且可追蹤的 tickets（任務單）。每個 ticket 都會清楚標明它的阻塞邊界（blocking edge），明確哪些前置任務必須先完成。
這就像將一個大計畫拆分成多個小任務，每個小任務都有明確的前置條件和依賴關係。
運作流程
- 讀取輸入：可以是計畫檔案、規格文件，或當前的對話內容。
- 識別任務：找出所有需要執行的任務。
- 建立依賴關係：分析任務之間的依賴和前置條件。
- 拆分為 tickets：將任務拆分為多個獨立的 tickets。
- 標記阻塞邊：為每個 ticket 標明它的阻塞邊。
- 輸出 tickets：以檔案格式或在實際 tracker 中建立。
實戰對話範例
範例一：將計畫拆分為 tickets
- You:
/to-tickets - AI:
正在分析計畫…
識別到的任務：
- 設計資料庫 schema
- 實作資料庫 migration
- 實作 API
- 實作前端介面
- 測試
依賴關係：
- 資料庫 migration 依賴 schema 設計
- API 依賴資料庫 migration
- 前端介面 依賴 API
- 測試依賴所有實作完成
Tickets 已建立：
Ticket #1：設計資料庫 schema
- 阻塞邊：無
- 描述：設計使用者、訂單、商品的資料表結構
Ticket #2：實作資料庫 migration
- 阻塞邊：Ticket #1
- 描述：根據 schema 設計建立資料表
Ticket #3：實作 API
- 阻塞邊：Ticket #2
- 描述：實作商品 API（CRUD）
Ticket #4：實作前端介面
- 阻塞邊：Ticket #3
- 描述：實作商品列表和詳情頁
Ticket #5：測試
- 阻塞邊：Ticket #4
- 描述：編寫和執行測試
檔案已建立：
docs/tickets/2026-08-02-product-search/
範例二：將規格拆分為 tickets
- You:
/to-tickets --spec=docs/specs/auth-system.md - AI:
正在分析規格…
識別到的任務：
- 設計 token 生成介面
- 實作 token 生成邏輯
- 設計 token 驗證介面
- 實作 token 驗證邏輯
- 設計 token 撤銷介面
- 實作 token 撤銷邏輯
- 更新所有 API 使用 token 驗證
- 添加單元測試
依賴關係：
- token 生成邏輯依賴介面設計
- token 驗證邏輯依賴介面設計和 token 生成邏輯
- token 撤銷邏輯依賴介面設計和 token 驗證邏輯
- 更新 API 依賴 token 驗證邏輯
- 測試依賴所有實作完成
Tickets 已建立：
Ticket #1：設計 token 生成介面
- 阻塞邊：無
- 描述：設計 token 生成函數的參數和返回值
Ticket #2：實作 token 生成邏輯
- 阻塞邊：Ticket #1
- 描述：實作 token 生成函數，包括簽名和過期時間
Ticket #3：設計 token 驗證介面
- 阻塞邊：無
- 描述：設計 token 驗證函數的參數和返回值
Ticket #4：實作 token 驗證邏輯
- 阻塞邊：Ticket #2, Ticket #3
- 描述：實作 token 驗證函數，包括簽名驗證和過期檢查
Ticket #5：設計 token 撤銷介面
- 阻塞邊：無
- 描述：設計 token 撤銷函數的參數和返回值
Ticket #6：實作 token 撤銷邏輯
- 阻塞邊：Ticket #4, Ticket #5
- 描述：實作 token 撤銷函數，包括 blacklist 機制
Ticket #7：更新所有 API 使用 token 驗證
- 阻塞邊：Ticket #4
- 描述：將所有 API 更新為使用 token 驗證
Ticket #8：添加單元測試
- 阻塞邊：Ticket #6, Ticket #7
- 描述：編寫和執行所有功能的單元測試
檔案已建立：
docs/tickets/2026-08-02-auth-system/
Ticket 格式
每個 ticket 都會按照以下格式整理：
# Ticket #N: [標題]
## 阻塞邊
- Ticket #X
- Ticket #Y
## 描述
詳細描述這個 ticket 的任務。
## 驗收標準
- [ ] 驗收標準 1
- [ ] 驗收標準 2阻塞邊表示
阻塞邊可以用以下方式表示：
檔案格式：
## 阻塞邊
- docs/tickets/2026-08-02-product-search/ticket-001.md
- docs/tickets/2026-08-02-product-search/ticket-002.mdIssue Tracker 格式：
## 阻塞邊
- #45 (設計資料庫 schema)
- #46 (實作資料庫 migration)輸出檔案
檔案會自動建立到以下位置：
docs/
└── tickets/
└── 2026-08-02-product-search/
├── ticket-001.md
├── ticket-002.md
├── ticket-003.md
└── ticket-004.md或者直接在 issue tracker 中建立 issues。
何時使用
- 已經完成計畫或規格，需要拆分為可執行的任務
- 需要建立清晰的依賴關係和前置條件
- 需要追蹤每個任務的進度
- 需要讓團隊成員清楚知道哪些任務可以並行執行
何時不應該使用
- 計畫或規格還未完成
- 需要進一步探索或訪談
- 任務已經拆分為 tickets
與其他技能的區別
| 技能 | 目的 | 輸出 |
|---|---|---|
/to-spec |
整理對話為規格 | Issue (規格) |
/to-tickets |
拆分為 tickets | 多個 tickets |
/implement |
實作 tickets | 程式碼 |
最佳實踐
- 每個 ticket 應該足夠小：可以在幾個小時內完成
- 每個 ticket 應該有明確的驗收標準：清楚知道什麼時候完成
- 阻塞邊應該準確：避免不必要的等待
- 應該標記可以並行執行的 tickets：提高效率