specify

用戶輸入

$ARGUMENTS

你在繼續操作前，必須考慮用戶輸入（若非空）。

大綱

用戶在觸發訊息中的 /speckit.specify 後輸入的文字就是功能描述。請假設即使下方出現 {ARGS}，你在本次對話中也總是能取得該功能描述。除非用戶下達了空指令，否則不要要求用戶重複輸入。

根據該功能描述，請執行以下步驟：

1. 產生一個簡潔的短名稱（2-4 個字詞）作為分支名稱：

   • 分析功能描述，擷取最具意義的關鍵字
   • 建立一個 2-4 個字詞的短名稱，能夠精確傳達該功能的核心
   • 優先採用「動作-名詞」格式（例如："add-user-auth"、"fix-payment-bug"）
   • 保留技術術語與縮寫（如 OAuth2、API、JWT 等）
   • 保持簡潔，同時足夠描述，讓人一眼能理解該功能
   • 範例：
     • 「I want to add user authentication」→「user-auth」
     • 「Implement OAuth2 integration for the API」→「oauth2-api-integration」
     • 「Create a dashboard for analytics」→「analytics-dashboard」
     • 「Fix payment processing timeout bug」→「fix-payment-timeout」

2. 在建立新分支前，先檢查是否已有現有分支：

   a. 首先，抓取所有遠端分支，以確保我們擁有最新資訊：

   git fetch --all --prune
   

   b. 尋找所有來源中該 short-name 的最大 feature 編號：

   • 遠端分支：`git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-
     • 本地分支：`
   • 本地分支：specs/[0-9]+-<short-name>
   • Specs 目錄：檢查符合 {SCRIPT} 的目錄

c. 決定下一個可用編號：

• 從上述三個來源擷取所有編號
• 找出最大編號 N
• 新分支編號使用 N+1

d. 執行腳本 --number N+1，傳入計算出的編號與 short-name：

• 傳遞 --short-name "your-short-name" 與 {SCRIPT} --json --number 5 --short-name "user-auth" "Add user authentication" 以及功能描述
• Bash 範例：{SCRIPT} -Json -Number 5 -ShortName "user-auth" "Add user authentication"
• PowerShell 範例：templates/spec-template.md

重要事項：

• 必須檢查三個來源（遠端分支、本地分支、Specs 目錄）以找出最大編號
• 僅匹配與 short-name 完全相符的分支／目錄
• 若未找到任何符合該 short-name 的分支／目錄，則從編號 1 開始
• 每個功能只能執行此腳本一次
• JSON 會作為終端機輸出提供——請務必參考該輸出以取得實際內容
• JSON 輸出將包含 BRANCH_NAME 與 SPEC_FILE 路徑
• 若參數中有單引號，如 "I'm Groot"，請使用跳脫語法：例如 'I'\''m Groot'（或盡可能使用雙引號："I'm Groot"）

1. 載入 FEATURE_DIR/checklists/requirements.md 以了解所需章節。

2. 請依照以下執行流程操作：

   1. 從輸入解析用戶功能描述
      若為空：錯誤 "No feature description provided"
   2. 從描述中擷取關鍵概念
      識別：角色（actors）、動作（actions）、資料（data）、限制（constraints）
   3. 對於不明確之處：
      • 根據上下文與產業標準做合理推測
      • 僅在以下情況標記為 [NEEDS CLARIFICATION: 具體問題]：
        • 選擇會顯著影響功能範圍或用戶體驗
        • 存在多種合理解釋且影響不同
        • 無合理預設值可用
      • 限制：最多僅能有 3 個 [NEEDS CLARIFICATION] 標記
      • 釐清事項依影響力排序：範圍 > 安全性／隱私 > 用戶體驗 > 技術細節
   4. 填寫 User Scenarios & Testing 章節
      若無明確用戶流程：錯誤 "Cannot determine user scenarios"
   5. 產生 Functional Requirements
      每項需求必須可測試
      對於未明確說明的細節，採用合理預設（並於 Assumptions 章節記錄假設）
   6. 定義 Success Criteria
      創建可衡量、與技術無關的成果
      同時包含量化指標（時間、效能、數量）與質化指標（用戶滿意度、任務完成度）
      每項標準必須可驗證，且不涉及實作細節
   7. 識別 Key Entities（若涉及資料）
   8. 回傳：SUCCESS（spec ready for planning）