| name | acceptance-evaluation |
| description | 驗收標準對齊評估方法論。給定用戶原始任務需求 + 上游 agent 產出，本 SKILL 提供萃取 testable criteria、4 大評估維度、報告格式、與 reviewer agents 的職責邊界、以及 WEB / 桌面 / CLI / 純文件的驗收手法分流。供 acceptance-evaluator agent 載入；orchestrator 直接 evaluate 簡單任務時也可參考。 |
驗收標準對齊評估方法論
何時載入本 SKILL
本 SKILL 是 acceptance-evaluator agent 的方法論知識庫。evaluator 為 opt-in 模式。觸發路徑：
主要（用戶顯式喚醒）：用戶在完成一輪完整開發後輸入 @zenbu-powers:acceptance-evaluator 驗收本輪交付，agent 載入本 SKILL 跑驗收。
次要（orchestrator 主動派的窄門）：
- 用戶 prompt 含「驗收 / 評估 / final check」等明確關鍵詞
- 多 agent 整合 conflict 想做 sanity check
- 任務跨多個 sub-agent + 高風險 / 不可逆領域（auth / payment / external-api / 資料遷移）
任務分級由 evaluator 內部依 testable criteria 自行決定——orchestrator 不依「重量任務 / 多維度」做分級派發。
與 reviewer agents 的關係（最重要）
| 角色 | 審查軸 | 例子 |
|---|
*-reviewer agents | Code 品質（best practice、安全、效能、可維護性） | react-reviewer 看 hook 用法、wordpress-reviewer 看 nonce、security-reviewer 看 OWASP |
| acceptance-evaluator | 用戶意圖對齊（需求覆蓋、邊界完整、off-topic 偵測） | 用戶要 A 結果做了 B 嗎？該包進去的邊界有缺漏嗎？產出有沒有偏題？ |
兩者正交不重疊。詳見 references/scope-boundary.md。
核心流程
Step 1：建立 testable criteria
從用戶原始任務 + 上下文萃取可驗收的具體標準。詳見 references/extracting-testable-criteria.md。
若 orchestrator dispatch 時已提供 criteria，直接用；若未提供，本 SKILL 教你怎麼自行推導並在報告中標明來源。
Step 2：對齊產出與 criteria
先過 Reality Check 前置鐵律，再走 4 大維度：
維度 0：Reality Check（前置鐵律 — 必先過）
主動掃描產出中所有反向訊號（錯誤、警告、未啟用、不可用）+ 驗證第三方依賴可用性 + 走完證據鏈到最終狀態。
不可假設「沒看到 = 沒發生」、不可把過程訊號（跳轉成功、exit 0、200）當現實訊號。
詳見 references/zero-assumption-verification.md（必讀，列入強制前置動作）。
4 大評估維度（Reality Check 過後才走）
- 需求覆蓋度（Coverage）：用戶要的功能/變更有沒有都做到
- 邊界完整性（Boundary）：邊界 case、錯誤處理、相關連動有沒有遺漏
- Off-topic 偵測（On-Topic）：產出有沒有偏題或多做了用戶沒要的東西
- 品質達標（Quality Floor）：基本可用門檻（不是 code review，是「能 work 嗎」）
詳見 references/evaluation-dimensions.md。
Step 3：依專案類型選驗收手法
不同專案類型的「驗收動作」不同：
| 專案類型 | 驗收手法 |
|---|
| WEB 應用 | Claude in Chrome 直連優先（本機互動 / 驗真實環境與登入態）；CI / headless / 需隔離可重現時用 agent-browser（外部 CLI，未安裝先提示 npm install -g agent-browser） |
| 桌面 / GUI 應用 | 要求 orchestrator/用戶提供截圖（無法自動化） |
| CLI / API | 跑指令、Read 輸出檔、grep 關鍵字 |
| 純文件 / 規格 | Read 對照、語意一致性檢查 |
詳見 references/project-type-verification.md。
Step 4：產出報告
依標準格式輸出，二元判定 PASS / FAIL，逐條對應 criterion。詳見 references/report-template.md。
Step 5：交回 orchestrator
- PASS：結束流程
- FAIL：orchestrator 重派原 agent → 修正後再次 spawn 本 SKILL 的使用者（acceptance-evaluator）複審
- 最多 3 輪迴圈，超過則建議用戶介入
References 索引
黃金原則
- 零假設：不假設「沒看到 = 沒發生」、不假設「過程訊號 = 現實訊號」、不假設第三方依賴可用——
全部要主動掃描並出示證據（必先讀
zero-assumption-verification.md）
- 反向訊號優先：當「畫面有反向訊號」與「criterion 看起來達成」衝突時，永遠相信反向訊號
- 二元判定：PASS 就 PASS、FAIL 就 FAIL，不允許「大致達標」這種曖昧用詞
- 對應到 criterion：每個 FAIL 必須指出對應哪一條沒過（Reality Check FAIL 也要指出哪個訊號）
- 改善建議要具體：不寫「再仔細看看」這類空話
- 不越界做 code review：發現 code 品質問題，標 out-of-scope，建議 orchestrator 補派 reviewer
- 不主動修改檔案：只產報告，改的事交給 orchestrator 重派
