意圖驅動開發 是做什麼的？
產出有用的驗收條件，而不將規格制定轉變為繁重儀式。首先檢查可用的上下文，揭露真正的模糊地帶，並選擇適合工作及其風險的驗證方法。
何時啟用
- 使用者要求釐清功能、定義驗收條件，或在實作前降低變更風險
- 請求觸及安全性、驗證、持久性資料、遷移、外部 API 或合規
- 使用者想要為另一個代理或團隊準備交接工件
- 請求模糊到預期結果尚無法觀察或測試
- 使用者明確使用
/intent-driven-development呼叫此技能
對於瑣碎編輯、直接的一行修復、活躍除錯階段、程式碼審查請求，或驗收條件已明確的實作請求，請勿啟用。
運作方式
- 先檢查上下文 — 在提出任何問題之前，先讀取儲存庫、文件、架構和測試基礎設施以獲取技術事實，同時將產品/業務限制視為只有使用者或產品工件才能提供
- 選擇深度 — 根據風險概況選擇「快速擷取」（3-7 個條件，低/中風險）或「完整驗收簡報」（安全、資料、遷移、跨系統變更）
- 最小化提問 — 僅詢問那些答案無法推斷且會實質改變範圍或行為的問題
- 撰寫可觀察的條件 — 每個 AC-NNN 描述起始條件、觸發動作、預期結果、禁止副作用、驗證方法和優先順序；不使用「正確地」或「安全地」等模糊詞彙而無證據
- 繼續或交接 — 對於無阻礙風險的明確請求，記錄條件並繼續；對於高風險變更，呈現阻礙因素並等待確認
- 處理修訂 — 若某個 AC 在實作過程中因架構限制而無法滿足，將其標記為
[revised]，更新範圍或驗證方法，遞增修訂編號，並僅重新呈現變更後的條件
範例
快速擷取 — 「為儀表板新增 CSV 匯出功能」
目標：已驗證的使用者可以將儀表板資料下載為 CSV 檔案。
範圍內：匯出目前篩選的行；檔名包含日期。
範圍外：排程匯出、電子郵件傳送、Excel 格式。
假設：最大行數低於 10k；匯出欄位中無 PII。
AC-001：匯出產生包含正確標題的檔案
- 情境：已驗證的使用者，至少有一行資料可見
- 動作：點擊「匯出 CSV」
- 預期：瀏覽器下載的檔案包含欄位 [id, name, created_at]
- 禁止：暴露內部欄位或屬於其他使用者的行
- 驗證：自動化整合測試 + 手動結構抽查
- 優先順序：必要
完整驗收簡報觸發 — 「將使用者驗證遷移至 OAuth」
驗證變更 + 外部依賴 + 現有會話資料 → 完整簡報，包含風險審查表、關於會話失效策略的阻礙決策，以及明確的回滾 AC。
現有規格審查 — 使用者貼上 PRD
技能會審查它是否缺少範圍邊界、無法驗證的需求（「系統應快速」）以及隱含的假設，然後回傳修正或補充的條件，無需重新開始探索。
運作規則
- 在請求可本地發現的技術事實之前，先檢查可用的儲存庫、文件、議題、設計和測試上下文。
- 不要從程式碼推斷產品或業務限制。業務規則、合規與法規義務、合約 SLA、定價、資料保留政策、優先順序和目標使用者無法從儲存庫中讀取。將其視為未知，直到使用者提供或權威產品工件（PRD、合約、政策文件）陳述。將其記錄為標記為確認的假設，絕不視為已發現的事實。儲存庫告訴你系統今日的行為，而不是業務要求它做什麼。
- 僅詢問那些答案必要且無法安全推斷的問題。當這樣做可以節省不必要的來回時，將簡短相關的問題分組。
- 預設情況下不要阻止實作。當使用者要求實作一個足夠明確的變更時，簡要記錄關鍵假設和驗收條件，然後繼續或將其交給實作工作流程。
- 僅當未解決的決策可能造成重大的安全暴露、資料遺失、不可逆遷移、合約/API 破壞、重大成本或破壞性外部動作時，才要求使用者在繼續前明確確認。
- 除非使用者要求或活躍的儲存庫工作流程明確要求，否則不要將驗收文件寫入儲存庫、變更專案檔案、建立分支、提交或呼叫另一個技能。
- 將自動化測試視為證據，而非事實。當自動化可靠且合比例時優先使用；在自動化無法確定結果時，允許手動 UX、無障礙、安全、法律或營運驗證。
- 切勿在驗收條件、測試裝置、範例或保存的工件中包含真實的機密、憑證、令牌、私鑰、個人資料或敏感的生產負載。使用去識別化或合成值。
- 未經明確授權和識別的安全環境，請勿對生產/即時資料執行破壞性測試、遷移、安全探測、負載測試、付費外部呼叫或操作。
- 當驗收條件因實作過程中發現的架構、平台或外部限制而無法滿足時，不要默默地放棄或繞過它。更新受影響的條件（標記為
[revised]，陳述限制，並調整範圍或驗證方法），遞增修訂編號，並僅重新呈現變更後的條件給使用者後再繼續。僅當修訂改變了阻礙決策或實質降低安全性或正確性保證時，才要求明確確認。
選擇深度
使用最小但有用的輸出。
快速擷取
用於明確但非微小的低或中風險變更。產出：
- 目標
- 範圍內 / 範圍外
- 假設
- 3-7 個具有驗證方法的驗收條件
- 阻礙問題（如有）
除非存在來自運作規則的阻礙風險，或使用者明確要求先制定規格，否則不要為了批准而延遲實作。
完整驗收簡報
用於模糊、跨系統、安全敏感、資料變更、遷移、合規或高成本變更，或當使用者要求交接工件時。產出下方完整範本，並在風險實作前請求確認未解決的阻礙決策。
現有規格審查
當使用者已提供 PRD、議題、計畫或驗收條件時：
- 審查它，而不是重新開始探索。
- 找出缺失的範圍邊界、不安全的假設、矛盾以及無法驗證的需求。
- 回傳修正或補充的條件。
工作流程
1. 確立目標與風險
提取或詢問：
- 使用者或系統的可觀察結果。
- 受影響的行為主體。
- 主要的失敗後果。
- 實際適用的風險維度：安全/隱私、持久性資料、相容性/API、遷移、外部依賴、成本、並行、效能、可用性/無障礙性。
避免詢問關於無關風險的通用問題。
2. 探索上下文
當本地或連接的工件可用時，僅檢查所需的內容：
- 現有行為和直接相關的檔案或介面。
- 儲存庫慣例、產品文件、API 合約、資料架構或遷移歷史。
- 現有的驗證基礎設施和實際的命令。
- 外部依賴以及它們是否可以孤立測試。
將發現的事實與使用者提供的假設分開記錄。如果無法檢查上下文，則說明哪些是未知的，並提出有針對性的問題。
儲存庫揭示技術事實——系統今天的行為方式、其慣例和合約。它不揭示產品或業務限制：業務規則、合規與法規義務、合約 SLA、定價、資料保留政策、優先順序和目標使用者。絕不要從程式碼或命名中重建這些。僅從使用者或權威產品工件獲取它們，並將其列為待確認的假設。
3. 定義範圍
陳述：
- 目標：一句話描述預期結果。
- 範圍內：此變更必須提供的行為。
- 範圍外：明確排除的誘人相鄰工作。
- 假設：尚未證實的主張。
- 阻礙決策：尚未解決、會實質影響安全性或行為的選擇。
4. 撰寫驗收條件
使用 AC-001、AC-002 等。每個條件必須描述可觀察的行為和適當的驗證方法；條件和測試不需要一一對應。
對於每個適用的條件，包括：
- 情境或起始條件。
- 動作或觸發。
- 預期的可觀察行為。
- 有意義時的禁止副作用。
- 驗證方法：自動化測試、整合檢查、手動 UX 審查、無障礙檢查、安全審查、營運檢查或利害關係人驗收。
- 環境/安全限制：當驗證可能影響資料、服務、成本或機密時。
- 優先順序：必要、重要或可選。
不要使用「正確地」、「安全地」、「快速」、「直觀」或「穩健」等詞語，除非定義可觀察的證據或將其記錄為人工審查判斷。
5. 僅涵蓋相關邊界
考慮以下類別，但僅包含適用的類別：
| 類別 | 何時包含 | 典型證據 |
|---|---|---|
| 快樂路徑 | 新的或變更的使用者可見行為 | 成功的工作流程或狀態轉換 |
| 驗證 | 變更接受輸入 | 拒絕格式錯誤或邊界值而不變更狀態 |
| 授權/隱私 | 資料或動作有存取邊界 | 拒絕存取且無敏感揭露 |
| 持久性/遷移 | 儲存資料或架構變更 | 向後讀取、遷移、回滾或備份行為 |
| 相容性 | 公共 API、檔案、事件或用戶端可能中斷 | 現有合約或測試裝置保持有效 |
| 失敗復原 | 存在網路、服務或非同步失敗 | 無部分狀態或明確的重試/降級行為 |
| 冪等性/並行 | 重複或同時寫入可能發生 | 無重複副作用或無效的最終狀態 |
| 效能 | 使用者或服務門檻重要 | 定義的測量條件和門檻 |
| UX/無障礙性 | 人與結果互動 | 鍵盤、回饋、錯誤復原、視覺/手動審查 |
6. 呈現並繼續
- 對於釐清/規格請求，呈現簡報並僅就列出的阻礙因素請求決策。
- 對於無阻礙的實作請求，呈現簡潔的條件摘要作為工作的一部分，並繼續實作。
- 對於移交給另一個代理或團隊，包含足夠的上下文和驗證細節，使他們能夠在不憑空創造需求的情況下行動。
- 僅在請求時將簡報儲存到檔案。當存在儲存庫批准的路徑時使用；否則在寫入前詢問或說明所選目的地。
輸出範本
使用此範本進行完整驗收簡報。對於快速擷取，省略不相關的部分。
# 驗收簡報：<變更名稱>
**狀態：** 草稿 | 已核准 | 已實作 | 已驗證
**修訂：** <編號>
**準備對象：** <使用者/團隊/代理，若已知>
**風險工作前需要核准：** 是 | 否 - <原因>
## 修訂記錄
| 修訂 | 日期 | 變更的條件 | 原因 |
| --- | --- | --- | --- |
| 1 | <日期> | — | 初始草稿 |
## 目標
<一句可觀察結果的句子。>
## 範圍
**範圍內**
- <包含的行為>
**範圍外**
- <排除的相鄰工作>
## 上下文
**已發現的事實**（技術性的，從儲存庫或工件驗證）
- <系統今天的行為方式、慣例、合約>
**產品/業務限制**（由使用者或產品工件提供，絕不從程式碼推斷）
- <業務規則、合規/SLA 義務、保留政策、優先順序、目標使用者 — 或「尚未提供」>
**假設**
- <待確認或驗證的未經核實主張>
**依賴與限制**
- <外部服務、本地慣例、相容性義務、環境限制>
## 風險審查
| 風險領域 | 是否適用？ | 所需處理 |
| --- | --- | --- |
| 安全/隱私 | 是/否 | <去識別化、授權、審查等> |
| 持久性資料/遷移 | 是/否 | <相容性、備份、回滾等> |
| 外部影響/成本 | 是/否 | <沙盒/測試環境/授權> |
| 相容性/API | 是/否 | <要保留或版本化的合約> |
| UX/無障礙性 | 是/否 | <手動或自動化證據> |
## 驗收條件
### AC-001：<可觀察行為>
- **情境：** <起始條件>
- **動作：** <單一觸發>
- **預期：** <可觀察結果>
- **禁止：** <禁止副作用（若適用）>
- **驗證：** <方法和預期證據>
- **環境/安全：** <限制（若適用）>
- **優先順序：** 必要 | 重要 | 可選
## 阻礙決策
- [ ] <僅阻止安全或正確進度的決策>
## 驗證計畫
| 條件 | 驗證證據 | 狀態 |
| --- | --- | --- |
| AC-001 | <測試/檢查/審查命令或證據類型> | 待處理 |
通過/失敗範例
使用這些來判斷技能是否確實產生了可驗證的簡報，而非規劃性的散文。
一個失敗的驗收條件
AC-001：匯出功能正確運作且安全。
失敗 —「正確運作」和「安全」不可觀察，沒有情境、觸發、預期...