/sdlc:spec — 定 AC（DOR 門檻）

把目前的對話與 codebase 理解綜合成一份 spec。不要重新訪談使用者—— 還有沒收斂的決策才用 /sdlc:grill-with-docs 補，那是這個 skill 的前一步。

先讀 docs/agents/sdlc.md（tracker 參數）。找不到就停下，請使用者先跑 /sdlc:init。

預設是「更新既有 story 的 body」，不是「開新 issue」

Epic 容器 issue 絕不修改或關閉。

流程

1. 讀 CONTEXT.md，spec 全程用領域詞彙；尊重要動的區域的 ADR。 spec 用設定檔指定的文件語言寫——讀者是批准者（和客戶），不是 AI。
2. 想清楚測試要下在哪些 seam。優先用既有的 seam、越高越好，理想數量是一。
3. 依下方模板寫 spec、更新 issue body。
4. RIPER-5 收尾：
   • story Status → 1.Research Review
   • 留 comment 請批准者審 AC
   • 停下來等批准。 未批准不得進 Plan（不得跑 /sdlc:plan）。

Spec 模板

## Problem            ← 使用者視角的問題
## Solution           ← 使用者視角的解法
## User Stories       ← 長的編號清單：As a…, I want…, so that…
## Implementation Decisions ← 模組、介面、schema、契約。不寫檔案路徑與程式碼（會過期）
## Testing Decisions  ← 議定的 seam、prior art、什麼是好測試（只測外部行為）
## Acceptance Criteria
  - [ ] 每條都能被單獨驗證（測得出來、看得到、點得到）
  - [ ] 禁用「妥善處理」「適當顯示」這類無法判定的措辭
  - [ ] 對照 User Stories 逐條回推，沒有故事沒有 AC
## 不做               ← 明確排除的事，防範圍膨脹。視覺類驗不了收就明講
## 外部依賴           ← 卡在客戶／第三方的前置，逐一標對應 issue 的完整網址。沒有寫「無」

寫完後 DOR 自我核對：

• 消除歧義：AC 有無邏輯衝突或多重解釋？
• 資訊缺口：有無缺少的外部數據或裁示？（有 → 列成 Q1、Q2⋯， 標出題目之間的相依與淘汰關係，附你的建議答案）
• 這張 story 達到 Ready 了嗎？

未決問題（Q1、Q2⋯）寫進 body，不是只留在 comment—— 開工後才浮出來的問題是票沒寫好的證據。