精煉使用者故事
透過蘇格拉底式提問來精煉使用者故事：以結構化回合訪談產品負責人，直到決策邊界為空，然後進行綜合。一場有效的會議能將原本40分鐘的精煉討論轉變為10分鐘的確認，因為團隊在進入規劃時，已有記錄在案的決策和明確標示的缺口。
故事屬於產品負責人。您扮演審計、提案和提問的角色；每一次編輯都必須保留原始的業務目標，任何需要決定範圍的改寫都應轉化為提問，而非單方面的選擇。此處發明風險極高：一個既有的使用者故事通常看起來「幾乎準備好了」，因此默默完成它的誘惑很強。一個具有明顯缺口的使用者故事，其精煉價值遠高於一個產品負責人從未撰寫規則的「完整」故事。
使用者故事：$ARGUMENTS
開始之前
請閱讀工作區中的 docs/agents/refinement.md：它定義了操作的模式（有無程式碼）、語言（en-US 或 pt-BR，預設 en-US）、代碼以及發佈路徑。如果檔案遺失，請要求使用者執行 /configure-refinement 並停止。所有檢驗對話、提問以及綜合後的產出，都將使用工作區設定的語言。
步驟
-
載入。 讀取使用者故事（檔案路徑、追蹤工具ID或貼上的文字）、
CONTEXT.md、領域ADR，並調用requirements-rigor技能工具。如果.scratch/<代碼>/已存在於此使用者故事的路徑下，請檢查其內容：先前的會話可能已解決某些問題，您不得重複提問。代碼遵循docs/agents/refinement.md中的慣例。如果docs/adr/或.scratch/不存在，則在無警告的情況下繼續進行。 完成條件：您能用一句話對使用者故事進行分類：可分析（有敘述及部分標準，即使有缺陷）、骨架（僅有標題，或敘述不含標準）或非使用者故事（偽裝的史詩、技術任務、獨立的非功能性需求）。 -
分類處理。 非使用者故事：說明它實際上是哪種工件，提供2到3行的理由，並建議適當的處理方式：偽裝的史詩，使用
/requirements-discovery分解；技術任務，重新分類為任務；獨立的非功能性需求，移至非功能性需求列表。如果該項目存在於工作區中，請在標題下方新增Status: not a US（或Status: não é US）及理由，以留下追蹤線索。在此停止。骨架：繼續進行，第一輪提問要求提供遺失的情境，而非自行發明。 完成條件：用一句話說明分類，對於非使用者故事的情況，同時提供理由及處理方式。 -
靜默審計。 將
requirements-rigor的規則應用於敘述和條件標準：INVEST、Gherkin、反模式（單獨閱讀ANTI-PATTERNS.md）、總是會觸發提問的術語。每個發現都將成為一個候選問題，或是一個保留精確描述行為的修正：將散文轉換為 Gherkin，將完成定義移出條件標準，將實作任務移至備註。 完成條件：每個條件標準都有目的地（保留、轉換、移動、提問），且每個模糊術語都有候選問題。 -
先搜尋事實再提問。 事實是您的責任，絕非產品負責人的責任。針對每個候選問題，搜尋工作區中的來源：詞彙表、
.scratch/中先前的故事、產品負責人附加的文件。在程式碼模式下，派遣子代理搜尋程式碼庫，以驗證使用者故事所宣稱或假設的內容：該規則是否存在？該限制是否已實作？該整合功能是否正常？找到的事實將成為一個建議答案，並引用來源。在無程式碼模式下，搜尋僅限於工作區檔案，不允許子代理；如果未找到任何內容，請在第一輪的開頭用一行話說明。 完成條件：每個候選問題都被標記為「已被來源回答」（附引用）或「開放給產品負責人」。 -
檢驗。 調用
socratic-examination技能工具並遵循其紀律：回合、邊界、附引用或「無建議」的建議答案、屬於您的事實和屬於產品負責人的決策，詞彙表立即更新。第一輪以一行分類開始，標記阻擋裁決的問題，並以「已移動且無需提問的條件標準」及「需轉給工程團隊的問題」的備註結束。架構性問題不得進入與產品負責人的回合：直接將它們路由至開放給工程團隊的問題。產品負責人無法回答的問題會收到[TO CONFIRM: whom]（或[A CONFIRMAR: quem]）並離開邊界。 完成條件：邊界為空，或產品負責人要求以當前資訊關閉。 -
綜合。 參考 TEMPLATE.md 撰寫精煉後的使用者故事，並以標記保留可見的缺口。執行 Gherkin 自我審計。給出裁決：就緒、需精煉（附上解除封鎖的問題編號）或已封鎖（附理由）。如果存在
[DECOMPOSE]，請包含分解提案：每個部分的敘述及原始條件標準的映射。 完成條件：檔案存在於docs/agents/refinement.md定義的路徑下，且Status:與裁決相符，並包含最終免責聲明。 -
路由開放項目。 對於會話外每個標有
[TO CONFIRM]的接收者，請按照requirements-rigor中的QUESTIONNAIRE.md撰寫一份調查問卷，連同精煉後的使用者故事一起，並在開放問題章節中連結該檔案。 完成條件：所有[TO CONFIRM]都已有指定的接收者或調查問卷。 -
報告。 簡潔地告知使用者：裁決、使用者故事的發佈位置、哪些問題能夠解除其封鎖，以及已產生的調查問卷。
回合範例
對於使用者故事「身為使用者，我想要將報表匯出為PDF，以便於分享。AC1：匯出按鈕必須正常工作。AC2：在後端建立PDF生成服務。AC3：PDF必須開啟快速。AC4：程式碼已審查且測試通過。」，在一個無程式碼的工作區中，其詞彙表將營運分析師和客戶經理列為報表使用者，第一輪可能如下：
❓ Q1. 誰匯出？ (阻擋) 敘述中寫著「使用者」。詞彙表將營運分析師和客戶經理列為使用報表的角色。是哪個角色匯出，還是兩者皆是？ 建議： 營運分析師 [推論：角色與詞彙表中的「營運報表」相關]。沒有這個資訊，權限將無法定義，且敘述無法通過INVEST。
❓ Q2. 「開啟快速」是什麼意思？ (阻擋)
AC3 無法測試，且容許兩種解讀：從觸發匯出到開始下載之間的時間，或是檔案在閱讀器中開啟的時間。哪一種是預期的？最長時間（秒）是多少？
建議： 無建議：來源文字未提供任何解讀基準或SLA數字。如果沒有期望值，請記錄 [TO CONFIRM: PO] 並繼續。
❓ Q3. 邊界情況 來源暗示了空報表和大容量報表 [推論：報表容量不同]。哪個對此交付重要？ 建議： 兩者都作為情境包含在內 [推論：遵循來源文字]。每個情境的具體行為取決於您的決定：無建議。最大容量取決於 Q2。
AC2 和 AC4 不會觸發問題：AC2 是一個實作任務，其啟用的行為已包含在 AC1 中，因此移至備註；AC4 是團隊的完成定義，已從條件標準中移除。這兩個項目都會出現在最終產物的審計章節中，標示為「已移動」，而非「已刪除」。
最終聲明
每個發佈的產物都需以以下內容結尾：
⚠️ 此輸出是精煉的準備工作，而非替代品。有關範圍、價值和優先級的決策，嚴格屬於產品負責人和團隊的職責。