checklist

檢查清單目的：「英文單元測試」

關鍵概念：檢查清單是需求撰寫的單元測試——用來驗證特定領域中需求的品質、清晰度與完整性。

不是用於驗證／測試：

• ❌ 不是「驗證按鈕是否能正確點擊」
• ❌ 不是「測試錯誤處理是否正常」
• ❌ 不是「確認 API 回傳 200」
• ❌ 不是檢查程式碼／實作是否符合規格

用於需求品質驗證：

• ✅「所有卡片類型是否都有定義視覺階層需求？」（完整性）
• ✅「『明顯顯示』是否以具體尺寸／位置量化？」（清晰度）
• ✅「所有互動元素的 hover 狀態需求是否一致？」（一致性）
• ✅「是否有定義鍵盤導覽的無障礙需求？」（覆蓋範圍）
• ✅「規格是否有定義 logo 圖片載入失敗時的處理？」（邊界情境）

比喻：如果你的規格像是用英文寫的程式碼，檢查清單就是它的單元測試套件。你是在測試需求是否寫得好、是否完整、明確且可直接實作——而不是測試實作本身是否可用。

用戶輸入

$ARGUMENTS

你在執行前必須考慮用戶輸入（若非空）。

執行步驟

Execution Steps

1. 初始化：從 repo 根目錄執行 {SCRIPT}，並解析 JSON 以取得 FEATURE_DIR 與 AVAILABLE_DOCS 清單。

   • 所有檔案路徑必須為絕對路徑。
   • 若引數中有單引號（如 "I'm Groot"），請使用跳脫語法：例如 'I'\''m Groot'（或若可行則用雙引號："I'm Groot"）。

2. 釐清意圖（動態）：根據上下文產生最多三個初步釐清問題（不得使用預設題庫）。這些問題必須：

   • 依據用戶的描述＋從規格/計畫/任務中提取的訊號動態生成
   • 僅詢問會實質影響檢查清單內容的資訊
   • 若在 $ARGUMENTS 中已明確，則個別問題可跳過
   • 以精確度優先於廣度

   生成演算法：

   1. 提取訊號：功能領域關鍵字（如 auth、latency、UX、API）、風險指標（如 "critical"、"must"、"compliance"）、利害關係人提示（如 "QA"、"review"、"security team"）、明確交付項（如 "a11y"、"rollback"、"contracts"）。
   2. 將訊號分群為候選重點領域（最多 4 組），依相關性排序。
   3. 若未明確，判斷可能的目標對象與時機（作者、審查者、QA、發佈）。
   4. 偵測缺漏面向：範圍廣度、深度/嚴謹度、風險強調、排除邊界、可衡量的驗收標準。
   5. 依下列問題原型擇一組成問題：
      • 範圍細化（如：「此檢查清單是否需涵蓋與 X、Y 的整合接點，還是僅限於本地模組正確性？」）
      • 風險優先排序（如：「這些潛在風險區塊中，哪些需要強制設置檢查關卡？」）
      • 深度校準（如：「這是 pre-commit 的輕量 sanity list 還是正式發佈的 release gate？」）
      • 目標對象定位（如：「這份檢查清單僅作者自用，還是 PR 審查時同儕也會用？」）
      • 邊界排除（如：「本輪是否明確排除效能調校項目？」）
      • 情境類型缺口（如：「未偵測到復原流程——rollback／部分失敗路徑是否納入範圍？」）

   問題格式規則：

   • 若有選項，請產生精簡表格，欄位：Option | Candidate | Why It Matters
   • 最多僅列 A–E 選項；若開放式回答更清楚則不需表格
   • 絕不要求用戶重述已說過的內容
   • 避免臆測分類（不得憑空想像）。若不確定，請明確詢問：「請確認 X 是否屬於範圍內。」

   若無法互動時的預設值：

   • 深度：標準
   • 目標對象：如與程式碼相關則為 Reviewer（PR），否則為 Author
   • 重點：前兩大相關性分群

   輸出問題時請標示 Q1/Q2/Q3。回覆後：若有兩類以上情境（Alternate／Exception／Recovery／Non-Functional 領域）仍不明確，你可以再追問最多兩個精準後續問題（Q4/Q5），每題附一句理由（如：「復原路徑風險未解決」）。總題數不得超過五題。若用戶明確拒絕，則不得繼續追問。

3. 理解用戶需求：結合 $ARGUMENTS 與釐清回覆：

   • 推導檢查清單主題（如 security、review、deploy、ux）
   • 彙整用戶明確指定的 must-have 項目
   • 將重點選擇映射至分類結構
   • 從規格/計畫/任務中推斷缺漏上下文（不得憑空想像）