acceptance-evaluation

驗收標準對齊評估方法論

何時載入本 SKILL

本 SKILL 是 acceptance-evaluator agent 的方法論知識庫。evaluator 為 opt-in 模式。觸發路徑：

主要（用戶顯式喚醒）：用戶在完成一輪完整開發後輸入 @zenbu-powers:acceptance-evaluator 驗收本輪交付，agent 載入本 SKILL 跑驗收。

次要（orchestrator 主動派的窄門）：

1. 用戶 prompt 含「驗收 / 評估 / final check」等明確關鍵詞
2. 多 agent 整合 conflict 想做 sanity check
3. 任務跨多個 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 過後才走）

1. 需求覆蓋度（Coverage）：用戶要的功能/變更有沒有都做到
2. 邊界完整性（Boundary）：邊界 case、錯誤處理、相關連動有沒有遺漏
3. Off-topic 偵測（On-Topic）：產出有沒有偏題或多做了用戶沒要的東西
4. 品質達標（Quality Floor）：基本可用門檻（不是 code review，是「能 work 嗎」）

詳見 references/evaluation-dimensions.md。

Step 3：依專案類型選驗收手法

不同專案類型的「驗收動作」不同：

專案類型	驗收手法
WEB 應用	Claude in Chrome 直連優先（本機互動 / 驗真實環境與登入態）；CI / headless / 需隔離可重現時用 playwright-cli SKILL
桌面 / 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	零假設驗收原則 + 反向訊號清單 + 強制前置動作（鐵律）	Step 2 之前必讀
extracting-testable-criteria.md	從用戶任務萃取可驗收標準的方法	Step 1 必讀
evaluation-dimensions.md	Reality Check + 4 大評估維度的判斷準則與範例	Step 2 必讀
project-type-verification.md	WEB / 桌面 / CLI / 純文件的驗收手法分流（含反向訊號清單）	Step 3 必讀
report-template.md	標準報告格式範本（含反向訊號掃描結果欄位）	Step 4 必讀
scope-boundary.md	與 reviewer agents 的職責邊界守則	遇到「這該不該管」的灰色地帶時讀

黃金原則

1. 零假設：不假設「沒看到 = 沒發生」、不假設「過程訊號 = 現實訊號」、不假設第三方依賴可用—— 全部要主動掃描並出示證據（必先讀 zero-assumption-verification.md）
2. 反向訊號優先：當「畫面有反向訊號」與「criterion 看起來達成」衝突時，永遠相信反向訊號
3. 二元判定：PASS 就 PASS、FAIL 就 FAIL，不允許「大致達標」這種曖昧用詞
4. 對應到 criterion：每個 FAIL 必須指出對應哪一條沒過（Reality Check FAIL 也要指出哪個訊號）
5. 改善建議要具體：不寫「再仔細看看」這類空話
6. 不越界做 code review：發現 code 品質問題，標 out-of-scope，建議 orchestrator 補派 reviewer
7. 不主動修改檔案：只產報告，改的事交給 orchestrator 重派