指令用途
/to-spec 將當前的對話內容綜合整理成一份正式的規格文件，並發佈到專案的 issue tracker（如 GitHub Issues）。
這不是進一步訪談或探索，而是將你已經討論過、決定好的內容，整理成結構化的規格文件。
運作流程
- 讀取對話歷史：讀取當前會話的所有訊息。
- 識別關鍵資訊：找出問題陳述、解決方案、約束條件、驗收標準。
- 整理成規格：按照標準規格格式整理內容。
- 發佈到 issue tracker：將規格發佈到 GitHub Issues。
- 返回連結：提供 issue 的連結。
實戰對話範例
範例一：功能規格
- You:
/to-spec - AI:
正在整理對話內容…
識別到的資訊：
- 問題：使用者需要更快地找到商品
- 解決方案：新增搜尋功能
- 約束：不使用外部搜尋服務，自己實作
- 驗收標準：搜尋時間 < 100ms
規格已整理，正在發佈…
已發佈：Issue #45
規格內容：
# 商品搜尋功能 ## 問題陳述 使用者反映難以找到所需的商品，需要花費大量時間瀏覽分類。 ## 解決方案 在首頁新增搜尋功能，允許使用者輸入關鍵字搜尋商品。 ## 約束條件 - 不使用外部搜尋服務 - 搜尋時間必須 < 100ms - 支援模糊搜尋 ## 驗收標準 - [ ] 使用者可以在首頁看到搜尋框 - [ ] 輸入關鍵字可以搜尋商品 - [ ] 搜尋時間 < 100ms - [ ] 支援模糊搜尋（例如輸入「手機」可以找到「智慧型手機」） ## 後續任務 - 設計搜尋介面 - 實作搜尋功能 - 優化搜尋效能
範例二：技術規格
- You:
/to-spec - AI:
正在整理對話內容…
識別到的資訊：
- 問題：認證系統過於複雜
- 解決方案：使用 JWT token 簡化認證
- 約束：必須支援現有的使用者資料庫
- 驗收標準：所有現有 API 必須正常工作
規格已整理，正在發佈…
已發佈：Issue #46
規格內容：
# JWT Token 認證系統 ## 問題陳述 目前的認證系統過於複雜，需要維護多個狀態和會話，造成開發和維護困難。 ## 解決方案 使用 JWT token 替代傳統的 session-based 認證。 ## 約束條件 - 必須支援現有的使用者資料庫 - 必須向下相容現有的 API - token 有效期為 7 天 ## 技術方案 ### Token 生成 - 使用使用者 ID 和過期時間生成 token - 使用密鑰簽名 ### Token 驗證 - 解析 token 並驗證簽名 - 檢查 token 是否過期 ### Token 撤銷 - 使用 token blacklist 機制 - 支援使用者主動登出 ## 驗收標準 - [ ] 使用者可以登入並獲得 token - [ ] token 可以驗證使用者身份 - [ ] token 過期後無法使用 - [ ] 使用者可以登出並撤銷 token - [ ] 所有現有 API 正常工作 ## 後續任務 - 設計 token 生成和驗證的介面 - 實作 token 生成邏輯 - 實作 token 驗證邏輯 - 實作 token 撤銷邏輯 - 更新所有 API 使用 token 驗證 - 添加單元測試
規格格式
規格會按照以下格式整理：
# [標題]
## 問題陳述
描述要解決的問題。
## 解決方案
描述解決方案的概述。
## 約束條件
- 約束 1
- 約束 2
## 驗收標準
- [ ] 驗收標準 1
- [ ] 驗收標準 2
## 後續任務
1. 任務 1
2. 任務 2何時使用
- 對話已經充分討論，需要整理成規格
- 已經做出決定，需要記錄到 issue tracker
- 需要將對話內容分享給團隊成員
- 需要建立正式的追蹤機制
何時不應該使用
- 對話還在探索階段，沒有做出決定
- 需要進一步訪談或探索
- 對話內容不足以形成規格
與其他技能的區別
| 技能 | 目的 | 是否訪談 |
|---|---|---|
/brainstorming |
探索需求和設計 | 是 |
/grill-me |
磨利計畫或設計 | 是 |
/to-spec |
整理已討論的內容 | 否 |
/to-tickets |
拆分計畫為 tickets | 否 |
輸出
- 連結到 issue tracker 中的 issue
- 規格內容會直接在 issue 中顯示
- 可以直接從 issue 開始後續工作