走廊測試 是做什麼的？
這個名稱來自於在走廊上隨機抓一個人，讓他們試用產品。在這裡，這個人是尚未看過實作、規格或產生程式碼的對話的子代理，因此它無法「忘記」作者已經知道的資訊。它會閱讀需求和使用者文件，決定應該發生什麼事，實際操作一遍，然後回報現實與預期之間的差異。在 modama 爬蟲專案中，這個方法在一個下午就發現了二十個實驗規模的行為問題，包括測試套件本身已經失效的缺陷。
兩種模式，通常合併使用：
- 行為模式：測試者建立測試輸入，在執行前為每個輸入寫下預期結果，執行工具，進行比較，並分類結果。
- 目視模式：針對人類閱讀的輸出，測試者在真實終端機中操作工具，並判斷螢幕截圖。這能捕捉文字解析永遠看不到的問題：輸出被捲離畫面、雜訊淹沒了訊號、文字換行、分頁器隱藏了診斷資訊。配套的驅動程式
${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py會在虛擬 X 伺服器下啟動一個 xterm，發送按鍵並擷取螢幕截圖；它需要安裝xvfb、xterm、xdotool和imagemagick（ImageMagick 的import），開發容器可以包含這些套件。
一份借用的檢查清單，感謝：MIT 授權的 cli-ux-tester 技能（作者 ali5ter）中的十一項 CLI 可用性準則，位於 ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md，作為命令列工具的額外檢查步驟。
啟動前
與使用者確認以下事項，這些會成為測試者的簡報：
- 測試者可以閱讀的內容。僅限於全新使用者會看到的內容：需求文件、使用者文件、命令的說明。請明確指出檔案或目錄名稱，並明確禁止其他所有內容（原始碼、測試、規格、設計筆記、Git 歷史）。測試的價值在於全新的觀點；每一份額外的文件都會削弱它的效果。
- 工具及其執行方式。命令列或進入點、可以在哪裡建立測試輸入（一個暫存目錄，絕不能在儲存庫中）、可以安裝什麼、絕對不能碰觸什麼（唯讀資料掛載就是唯讀）。
- 必須涵蓋的測試範圍。一份測試者必須涵蓋的案例清單，來自需求以及上次遊玩測試中發現的落差，再加上「你自己設計的實驗」。對於目視測試：情境、終端機大小、要按的按鍵。
- 回答問題的人。當需求未明確說明應該發生什麼事時，測試者會向主對話提問；主對話根據設計回答，並將無法自信回答的項目記錄為待辦事項，交給專案擁有者。
- 報告存放位置以及摘要長度。
簡報
在背景啟動一個通用子代理，並使用 ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md 中的模板建構簡報：角色設定（「一位第一次嘗試這個工具的研究軟體工程師，作為關鍵的早期使用者」）、嚴格的閱讀規則、使用者會看到的命令參考、方法（建立、先寫下預期結果、執行、比較、分類為：符合預期/錯誤/可辯護的意外/落差/問題）、必須涵蓋的範圍、提問的指示，以及報告結構。對於目視測試，請使用 ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md 中的簡報，其中描述了驅動程式並要求測試者僅根據螢幕截圖判斷。
模型：目視測試者可以使用較便宜的模型，因為它只需要觀察與回報；行為測試者則應使用主對話的模型，因為它需要推理應該發生什麼事。
執行期間
根據設計回答測試者的問題，並附上推理過程；當問題暴露了一個錯誤時，告知測試者（然後以正常方式修復該錯誤，附上測試，並告訴測試者工具已變更）。持續記錄你無法自信回答的事項；這些將作為決策交給專案擁有者，而不是你的猜測。
測試後
- 閱讀報告。在接受任何錯誤聲明之前，先針對程式碼驗證每個錯誤；無法存取原始碼的測試者只會描述症狀，而原因可能不同。
- 在專案存放設計筆記的位置（例如
design/playtest.md）撰寫持久記錄：哪些地方卡住了、哪些問題已經修復並附上測試和規格案例、你提供的答案，以及一份給專案擁有者的待辦事項清單（附上你對每個項目的判斷）。 - 對於每個缺陷，回答「什麼能夠預防這個問題」，並加入相應的內容：一個測試、一條規則、一個檢查。沒有這個回答的缺陷只算修復了一半。
- 確保測試者的目錄結構和螢幕截圖是可重現的：一個能夠重新執行任何實驗的小型腳本，儲存在報告旁邊或暫存目錄中，並在記錄中指定路徑名稱。
規則
- 測試者絕不修改儲存庫，絕不閱讀被禁止的內容，並在報告中說明它收到的所有內容，包括測試框架附加但未要求的任何東西。
- 預期結果必須在執行前寫下，否則比較就毫無意義。
- 每個發現都是一個事件：確切的命令、預期的結果、觀察到的結果、相關的 stderr 行或螢幕截圖檔案名稱。
- 不要在測試期間修復測試者以問題形式回報的內容；先決定它是一個錯誤還是設計選擇，然後再修復並附上測試。