Imported from bibirock/spex (assets/skills/spex-challenge/SKILL.md). Install upstream with npx skills add bibirock/spex --skill spex-challenge. Copyright stays with the author.

Spex: Challenge — 對抗式詰問閘門

規則載入

依 adapters/README.md 的 grep+offset SOP 讀取 .claude/rules/sdd-workflow.md 的「對抗式詰問」「章戳鏈（蓋章 / 驗章）」「Fail 判定」章節（grep 不到 → fallback 整檔讀）。

Overview

唯一職責：判定階段產出是否值得交棒，PASS / FAIL 二擇一，判定必須有證據。

• 詰問者 = challenger agent（.claude/agents/challenger.md）：全新上下文、唯讀、立場敵對。
• 本 skill 永不修改產出——FAIL 只產出修正清單，修正是原階段的事（詰問的不動手）。
• 與 selfcheck 分工：challenge 問「做的東西齊不齊、偷沒偷懶、格式對不對」；selfcheck 問「AC 過沒過」（機器證據 + 獨立驗收）。兩者都是硬閘門，不互相取代。

接點與詰問輸入

「詰問對象」≠「圍欄內容」：本表「詰問對象」是 challenger C1–C6 的審視範圍（完整產物，作為詰問輸入附件）；challenge-draft 圍欄內容永遠＝將寫入 tracker 的該階段留言草稿本體（章面 sha256 綁定對象），兩者不是同一份文件。把完整產物（任務清單全文／計畫全文）塞進圍欄 → 章綁不到留言，驗章 S5 必炸、整輪作廢。

（selfcheck 的獨立驗收走 verifier agent 與驗收章，不在本 skill 範圍。）

Process

Phase 1: 打包詰問輸入

依上表組裝；統一編號 AC / In Scope / 邊界條件清單。禁止放入產出階段的推理與對話歷史（獨立性來源）。

證據包（必附）：詰問輸入須附「可查證事實清單」——變動／預計變動檔案清單、關鍵設計決策及其依據出處（file:line 或套件內路徑加行號）、已核實的 library 行為事實、前輪 verdict 摘要（重詰問時）。目的：challenger 以逐項查證證據包為主（開檔對行核實）、範圍外抽查為輔，取代全量從零掃碼。

鐵則：證據包任一條查證不實 → 該接點直接 FAIL（假證據比缺證據更重）；證據包只能列可獨立查證的事實，不得夾帶產出階段的推理結論。查證不實的精確定義：出處檔案或符號不存在／引用的行為‧語義與原始碼實際內容不符／斷章取義扭曲原意——以「檔案＋符號＋語義內容」三者查證為準；行號區間端點誤差 ≤2 行且內容與符號相符＝列 non-blocking 修正建議，不構成 FAIL（否則閘門會空轉在括號計數上，無品質增益）。

重詰問輪（round ≥2）證據包追加：詰問輸入必須逐字附上前一輪的結構化修正清單（含「怎樣才算過」欄）——這是 challenger 覆核前輪修正的基準文件；缺附屬派發方缺陷，challenger 應回報「詰問輸入不完整」不蓋章。

Phase 2: 派發 challenger（全新上下文，唯讀）

以 Agent 工具派發 challenger（不指定模型），逐項詰問並回 verdict + 證據。同步鐵則：必須同步等待 challenger 回傳（run_in_background: false）——未取得 challenger 回傳原文前，禁止進入 Phase 3 判定與任何後續步驟；非同步派發後自行推測／代寫 verdict = 造假，等同 FAIL 並記教訓。

蓋章協定：派發 prompt 必須（1）註明本次接點 stage、輪次 round 與卡片編號 card（＝本次詰問所屬 tracker item 的 ID；驗章器據此把輪次上限與收斂判定限縮在單張卡，批次跑多卡時才不會互相牽連——缺 card 時整份事件流的同 stage 章會累加，第 4 張卡即使首輪就 PASS 也會被判超限）；（2）將受審草稿逐字放入圍欄區塊：

```challenge-draft
<受審草稿全文，逐字>
```

challenger 對該圍欄內容計算正規化雜湊並蓋章（章面格式與雜湊指令見 .claude/agents/challenger.md）。

圍欄內容必須逐字 = 未來要寫入 tracker 的該階段留言草稿本體；❌ 絕不含 challenge 宣稱行／驗收章行——連佔位符（第 n 輪｜章 <待填>）與 ## challenge：（待回填） 這類佔位標題行（凡 ^#+\s*challenge[:：] 開頭者）都不行：這些行驗章器一律 strip、不入雜湊比對，夾進圍欄＝章結構性必炸 S5，逐字重現也修不了；challenger 遇之直接退件不蓋章。宣稱行於 PASS 後發出留言時追加在本體之後——先起草留言、再送詰問。階段完整產物（技術計畫全文 / diff / 驗收報告）作為詰問輸入的另一節附上供 challenger 查驗（C5 上游一致性：留言草稿與完整產物矛盾即 FAIL），不入圍欄。

重詰問覆核協定（防假修）：round ≥2 時 challenger 報告第一節必須是「前輪修正項逐項覆核表」——對前輪修正清單每一項判 真修｜假修｜未修 並附開檔證據（file:line 或草稿段落）；假修（宣稱已修但實質未修、或僅字面改寫未改實質）→ 該輪直接 FAIL 並置頂標注做假訊號（做假重於缺陷）。

判準穩定鐵則（防「過不了的困境」）：round ≥2 新增的 blocking FAIL 項必須附「為何前輪未發現」歸因（新事證浮現／前輪修正引入的新缺陷／前輪確屬疏漏並自認）；無法歸因者一律降列 non-blocking 建議，不得作為該輪 FAIL 的唯一依據——防判準漂移每輪換靶。前輪修正項全數真修、且無合格新增 blocking 項 → 該輪應 PASS。

增量重詰問（唯一合法省工路徑）：round ≥2 派發必附前一輪 challenge-draft 圍欄原文；challenger 先以確定性 diff 比對兩版——未變動段落且前輪該判項 PASS → 可引前輪 verdict 免全量重審（另隨機抽查 1 段防漂移）；變動段落＋前輪 FAIL 項＋前輪修正清單覆核 → 一律全量重審。省的是模型重掃未變內容的時間，判定證據標準不降。呼叫方若聲稱某段未變而 diff 顯示有變 = 做假 → 直接 FAIL。缺附前輪圍欄＝派發缺陷：challenger 逕行全量重審（可靠性不降），但必須在報告置頂標注「派發輸入不完整：缺前輪圍欄原文」——全量重審逐輪挖深＝輪次上限被長尾缺陷燒穿，成本歸因於缺附方。

implement 接點測試執行縮減：implement 接點 challenger 不重跑全量測試束（全量已有 selfcheck 確定性 Gate 把關）；改為（a）讀碼查證 diff 與證據包；（b）抽驗 ≤2 條窄範圍指令（如單一測試檔或單一測試名 pattern）：1 條驗留言宣稱的具體數字＋至少 1 條由 challenger 自選（變動檔中自挑，不受執行者宣稱引導——防「只宣稱安全項」的賽局漏洞）——宣稱數字與抽驗不符、或自選抽驗失敗，仍直接 FAIL。

需求錨定鐵則（防無限追問→過度設計）：每一項 blocking FAIL 必須錨定下列二者之一，並在修正清單逐項引用錨文：（a）卡片規格原文——AC 條文、邊界條件表列、In Scope 項、驗收場景的逐字內容（卡片要求什麼就驗什麼，驗到卡片要求的深度為止）；（b）可靠性判準——假證據、假綠（零匹配／恆真／測試弱化／指令構不到宣稱對象）、範圍外變更、權限或資料隔離破口。無法錨定者一律 non-blocking：測試風格偏好、「更全面」的雙面斷言主張（規格只述單面時）、超出卡片邊界表的新邊界案例、防禦性設計建議、未來擴充性、驗收指令與紅測的命名 pattern 一致性——這些是過度設計壓力，不是缺陷。

聚焦裁決：詰問重心＝實作結果與程式碼品質。唯一 blocking 類別＝(1) 結構性缺漏（In Scope / AC / 邊界條件漏做，C1）、(2) AC↔測試對映不存在或斷言假綠（C2）、(3) 偷懶縮水 / TODO / 佔位符（C3）、(4) 型別逃生口（C3）、(5) 假證據／假數字／範圍外變更／權限或資料隔離破口、(6) 上游一致性實質矛盾（C5）。一切精細文字一律 non-blocking 放行：措辭、命名 pattern、留言／註解／驗收指令的字面精確度、格式微差、標點全半形、雙面斷言「更完整」主張。判不準是「文字」還是「實質」時，以「把實作換成空殼會不會照樣綠」為準——會綠才 blocking，否則放行。卡片文字是有限集合，錨定使 FAIL 空間有界、輪次由構造收斂；challenger 每輪「挖得更深」只允許發生在查證手段上，不允許發生在標準定義上。

階段判準邊界（鐵則）：詰問對象限於該接點的產出物（上表「詰問對象」欄）。下游階段尚未發生的工作不得作為 FAIL 理由——task 接點不得以「代碼尚未實作」「測試檔尚未存在」判 FAIL（那是 implement / selfcheck 接點的判準）；反之 implement 必須驗實際 diff 與真實測試。C3 的「佔位符」指產出物文件內的佔位符與空欄，不指 codebase 現況。

Phase 3: 判定與路由

• 全 PASS → 放行：回呼叫階段續行（寫留言 / 開卡 / 交棒）。發出留言時，本體必須逐字＝該輪 challenge-draft 圍欄（唯一允許差異＝引章行回填輪次與章號）；蓋章後任何潤飾——刪注記、改措辭、增刪段落——都會使內容綁定失效，整輪作廢。發出前自行以蓋章同款雜湊指令複核 sha256 與章面一致。該階段留言附一行引章宣稱：

  challenge：PASS（第 <n> 輪｜章 <章號>）
  

  章號 = 該次 Agent 派發的 tool_use_id（toolu_…）或 Agent 回傳尾部的 agentId（兩者皆 harness 生成、可驗，任一即可）。無章號的 PASS 宣稱在驗章（spex-stamp，S1）一律擋下，等同未過閘。

• 任一 FAIL → 產出結構化修正清單（缺失 / 證據位置 / 怎樣才算過）退回原階段修正；修正後重跑本 skill（第 n+1 輪）。

• 點名即全類別掃描義務：challenger 每點名一項缺失，修正清單該項必須（a）以一句話宣告其缺陷類別（可據以機械判定「還有哪裡同病」的操作性定義）；（b）當輪即以該類別掃描產出物全文，列出全部命中實例（含檔位／段落），禁止只列樣本——「同類其他處下輪再說」＝本 skill 違紀（drip-feed 燒輪）。派發方據全集一輪修完；下一輪 challenger 若以同一類別再抓到本應命中的實例，疏漏歸屬前輪詰問，不計入執行者違紀但輪次照燒。

• 輪次上限 N（單一來源：.claude/rules/sdd-workflow.md「詰問輪次上限」行；不得在本檔或任何檔案另行寫死數字）：第 N 輪仍 FAIL → 停止，升級人工（彙整歷輪 verdict 與未過項）。此上限由驗章器程式碼硬執行（S3/S4：宣稱輪次 >N 或同 stage 章 >N 枚 → 產物一律無效），第 N+1 輪起即使 challenger 回 PASS 也不放行。

• 詰問結果翻覆（同項 PASS↔FAIL 兩輪）→ 立即升級人工（判定不穩定訊號）。

• 章面缺失＝FAIL 重派：challenger 回傳末行必須是結構化章面（[CHALLENGE-VERDICT …]）——回傳無章面、章面殘缺、或尾文語氣曖昧 → 一律視為 FAIL，重派同輪（重派不加輪次）；執行者絕對禁止自行補寫章面、自算 sha、或以「內容看起來通過」推斷 PASS——自書章行＝偽造，事件層驗章（章必須以 tool_result 落事件流）百分之百識破，接點全作廢、記做假訊號置頂。

• verdict 鐵則（呼叫方不可改判）：PASS 的唯一證據 = 最後一輪 challenger 原文輸出整體 PASS。呼叫階段不得以「修正已納入產出」「FAIL 數已下降」「超過閾值改為整合」等任何理由自行宣告 PASS；FAIL 後唯二路徑 = 修正後重詰問取得新 verdict、或超限升級人工。headless／批次驅動下「升級人工」= 輸出 challenge 超限升級人工 的 blocked 報告並停止，不產出交棒產物（留言 / 開卡 / ACTION 區塊）。

• FAIL 不蓋章（收斂鐵則，程式硬執行）：蓋章的唯一前提＝該 stage 的 challenge 收斂到 PASS。一個 stage 最新一次已完成 challenger 章面 verdict != PASS（且無後續 PASS 取代）＝未收斂，一律不可蓋章、不可交棒——不論留言用什麼字眼（含以非正式散文寫「✅ PASS」、貼章號卻不走引章格式）都無效。此規則由驗章器 strict 模式的「S2-收斂」硬執行：尾端 challenger verdict≠PASS → 整流 block。r1 FAIL→r2 PASS 正規流程取較晚者＝PASS，不誤觸；澄清若只在散文、未重派 challenger 取得 PASS 章，仍屬未收斂。故 FAIL 後不得直接輸出交棒產物，必先修正碼／產出、同 session 重派 challenger 取 PASS 章（≤輪次上限）。

Red Flags

• ❌ challenger 修改任何檔案（詰問與修正必須分離）
• ❌ 把產出過程的推理餵給 challenger
• ❌ 無證據判 PASS；或把 non-blocking 風格建議當 FAIL 理由
• ❌ FAIL 後未修正就重跑、或超過輪次上限仍自動重做
• ❌ 跳過本閘門直接寫留言 / 開卡 / 交棒
• ❌ 執行者自行補寫章面或自算 sha256（＝偽造）

Verification

• 詰問輸入不含產出推理
• C1–C6 逐項有 verdict + 證據
• FAIL 時修正清單結構化且已退回原階段；輪次已記錄
• PASS 時該階段留言附引章宣稱行，且本體逐字＝圍欄內容