expo-skill-eval

Expo Skill Eval

評測 plugins/expo/skills/ 中的 Skill，涵蓋觸發準確度、產出的程式碼品質，以及／或在 Expo Go 中的執行階段渲染效果。

系統需求：安裝有 Xcode（iOS 模擬器）的 macOS、包含至少一個 AVD 的 Android SDK，以及 bun。不假設具備其他裝置工具。

工作區根目錄：/private/tmp/expo-skill-eval-<skill-name>/iteration-N/（例如 /private/tmp/expo-skill-eval-expo-ui/iteration-4/）。

開始之前 — 明確評測範圍

在執行任何流水線作業前，請先確認以下所有事項 — 請勿遺漏任何一項（僅當請求中已明確指明該選擇時方可跳過）。請使用 AskUserQuestion 將問題分批提問（每批最多 4 個問題），並依循以下順序：

1. 要評測哪一個 Skill（若請求中未明確說明）。
2. Prompts（提示詞） — 用於驅動評測的提示詞。內建提示詞（來自 Skill 的評測案例）預設為全選；可剔除任意項目、新增自訂文字提示詞，或根據上傳的螢幕截圖建立（即 Skill 必須重現的目標 UI）。詳見下方的 Prompts。
3. 要驗證的項目 — 包含三個選項的多選題：執行階段 + 螢幕截圖 / 觸發準確度 / 程式碼檢查（不安裝裝置）。詳見下方的 要驗證的項目。
4. Expo SDK — 最新版本（預設，自動偵測）或指定的固定版本。
5. Runner（執行器） — Expo Go（預設）或 Development build（開發建置）。
6. 平台 — iOS / Android / Web（永遠提供這三種選項）。
7. claude -p 的權限標記 — skip-permissions（預設）或 accept-edits。
8. 檢視器交付方式 — 僅限本機（預設）或發布可分享的 Artifact。
9. 若選擇了觸發準確度 — 確認已停用（或未安裝）已發布的 expo 外掛程式。

各項詳細說明如下。第 4–6 項（SDK、Runner、平台）可自然組合在同一個 AskUserQuestion 提問中。

若請求中未明確要評測的 Skill，請列出 plugins/expo/skills/ 中所有可用的 Skill，並詢問要評測哪一個。

受測 Skill 的載入機制 — 分為兩個階段，各使用不同的機制（請勿全局套用單一機制）：Executor 執行階段透過檔案路徑引用（SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md，明確讀取）；而觸發評測階段則將其載入為外掛程式（--plugin-dir plugins/expo，以便模型能根據其 description 自動選擇）。兩者均指向本機 / 儲存庫內的版本 — 這才是您正在評測的對象。您不需要任何特殊標記來啟動 Harness 對話本身（Harness 會透過儲存庫路徑找到 Skill）；這些機制僅套用於其產生的 claude -p 子程序。請參閱步驟 1 與 3 了解各階段差異的原因。一項執行前的必要檢查（當評測範圍包含觸發準確度時）：若已安裝／啟用已發布的 expo 外掛程式，請在啟動 Harness 之前將其停用（透過 /plugin），並在事後重新啟用。單次停用是全域設定的變更，當前對話與產生的 claude -p 子程序皆會繼承此設定。為何觸發評測需要此步驟：該階段會透過 --plugin-dir 載入本機 Skill，而第二個已安裝的 expo 會產生衝突 — 模型可能會觸發已發布的 expo:expo-ui，由於偵測機制僅能看到工具調用名稱，您可能會在無意中對已發布的描述進行評分，而非您在本機修改的版本（此衝突也可能直接拋出錯誤）。Executor / 執行階段 / 靜態階段則不受影響 — 它們是透過本機 SKILL_PATH 讀取受測 Skill，無需 --plugin-dir — 因此未包含觸發評測的執行可跳過此停用步驟。停用 expo 並不會停用 expo-skill-eval（它是一個獨立的專案 Skill，不屬於 expo 外掛程式的一部分），因此 Harness 仍可正常使用。

請將此作為事前確認明確提示給使用者 — 就像您確認要評測哪個 Skill 一樣。當評測範圍包含觸發準確度時，請在開始步驟 1 之前要求使用者確認已發布的 expo 外掛程式已被停用（或未安裝）；若仍處於啟用狀態，請暫停並讓他們透過 /plugin 進行停用。在使用者確認前請勿執行觸發評測 — Harness 無法可靠地自行偵測已安裝的外掛程式（讀取全域外掛程式設定或執行 claude plugin list 會觸發提示），因此這是人工確認而非自動檢查。

選擇 Prompt — 內建、自訂，或目標螢幕截圖。 Prompt 是驅動 Executor（使用 Skill 與不使用 Skill）的輸入；它們與您要驗證的內容是分開的。請透過 AskUserQuestion 進行確認（若請求中已指定 Prompt 則可跳過）：

• 內建 Prompts — 透過讀取受測 Skill（其 SKILL.md + references/）以及 references/runtime-matrix.md 所產生的具代表性 Prompt，涵蓋 Skill 的標準使用場景。（若 Skill 已在 evals/evals.json 下附帶評測案例，亦可將其 prompt 欄位納入 — 但多數 Skill 未附帶，因此通常由您推導出）。預設全選，以便預設執行能測試 Skill 的標準場景；允許使用者取消勾選任何項目。
• 自訂文字 Prompt — 使用者輸入的單次 Prompt。不需要為此專門占用一個選項位置：AskUserQuestion 會自動新增 "輸入其他內容" / Other 選項，在此處輸入的任何內容都會成為自訂文字案例。
• 根據上傳的螢幕截圖建立 — 使用者提供目標螢幕截圖（要重現的 UI）的路徑。Executor 會被告知開啟該圖片 — claude -p 會透過其 Read 工具讀取 PNG — 並建置符合該圖片的 App；此案例會將路徑記錄為 reference_image，評分階段則會將產生的 App 與該目標進行比較（步驟 6）。這是 UI Skill 最強大的視覺測試手段："照著 這個 建置。"

遵循 AskUserQuestion 每題最多 4 個選項的限制，並按以下優先順序處理（需避免的 Bug：選項填滿 4 個後，上傳選項被默默吃掉）：

1. 永遠為「根據上傳的螢幕截圖建立」預留一個選項位置。 這是視覺評測的核心重點，絕不能成為被剔除的選項。
2. 不要手動新增「自訂文字 Prompt」選項 — 自動產生的 "輸入其他內容" / Other 選項已經涵蓋此功能。
3. 用預先選取的內建／代表性 Prompt 填滿剩餘的 ≤3 個位置。若數量超過 3 個，請將其合併為一個預先選取的 "所有內建 Prompts（預設）" 選項，並在隨後的簡短追問中提供子集選擇，以確保上傳選項仍能放得下。

請將此呈現為多選題。當選擇「根據上傳的螢幕截圖建立」時，請在後續追問中詢問目標圖片的路徑。每個選中的 Prompt（內建、手動輸入或圖片）都會成為一個評測案例（分別在有 Skill 和無 Skill 的情況下執行）。

除非請求中已毫無懸念，否則務必確認要驗證的項目。 請提供以下選項供使用者選擇一或多個（粗體為根據 Skill 在 references/runtime-matrix.md 中的紀錄所推薦的預設值）：

選項	功能說明	何時建議作為預設值
執行階段 + 螢幕截圖	完整流水線：專案 fixture → Executor → 靜態門檻檢查 → 在 iOS/Android 上執行 App 並截圖。Runner（Expo Go 或 dev build）是另一個獨立問題 — 切勿在此處命名。	預設適用於任何會渲染 App 畫面的 Skill（references/runtime-matrix.md 中的 expo-go/dev-build 列）。需要已啟動的模擬器。
觸發準確度	透過 claude -p 執行真實 Prompt，檢查 Skill 是否被讀取。測量召回率（僅限應觸發的查詢）。	作為獨立檢查時永遠有用。
程式碼檢查（無裝置）	tsc --noEmit + 差異感知 Lint + expo export，加上評分器會根據您提供的任何自訂預期檢查產生的程式碼。不需要裝置。	預設適用於 static-only 與 n/a 的 Skill，以及任何您只想驗證程式碼模式（正確的 import 路徑、Host 包裹器……）而不執行 App 的情況。

請將這些呈現為單一多選題 — "您想要驗證什麼？" 這些是評分維度（如何評判建置出的成品） — 與 Prompts 階段（要建置什麼）不同。使用者可以選擇任何組合。當 Prompt 為上傳的螢幕截圖時（參見 Prompts），請務必包含 "執行階段 + 螢幕截圖"，以便 Harness 擷取產生的 App，使評分器能對照目標進行打分。

在提出建議前，請先閱讀 references/runtime-matrix.md 以查找 Skill 的預設模式。若請求中已指定模式（例如「只需檢查是否觸發」、「在裝置上執行」），請跳過此問題並繼續。

預先一次選定 Expo SDK 版本。 透過 bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh 偵測最新版本（它會印出主版本號，例如 56；其內部使用 bun 執行 npm view expo dist-tags --json 並透過 JSON.parse/semver 讀取主版本號，此操作受 bash-scripts 規則約束 — 因此請勿自行在行內執行 registry 查詢，那會引發提示）。接著透過 AskUserQuestion 進行確認：預設使用最新的 SDK，或允許使用者指定舊版本（例如為了重現特定版本的 issue）。在建立專案 fixture 的所有地方都使用選定的版本 — 將其作為 <sdk> 參數傳遞給 make-fixture.sh，並寫入每個評測案例的 runtime.sdk 中。若請求中已指定版本（「在 SDK 54 上評測」），請跳過偵測並直接使用該版本。

預設使用最新版本 — 它能與 expo start 安裝在裝置上的 Expo Go 保持相容。指定比裝置上已安裝的 Expo Go 更舊的 SDK 會導致 expo start 嘗試提示「是否安裝推薦的 Expo Go 版本？」；而在沒有 TTY 的情況下（快照指令碼會從 /dev/null 讀取 stdin），它會因 Input is required, but 'npx expo' is in non-interactive mode 錯誤而崩潰，導致所有快照失敗。因此，只有在您同時於模擬器上預先安裝了相符的 Expo Go 時才指定舊版 SDK — 否則請堅持使用最新版本。

選擇 Runner — Expo Go（預設）或 Development build。 透過 AskUserQuestion 詢問（若請求中已說明則跳過）：

• Expo Go（預設） — 快照指令碼直接以原樣透過 expo start --ios / expo start --android 執行 App。速度快（無原生編譯），且可執行 Expo Go 打包的任何內容（包括 SDK 56+ 上的 @expo/ui）。無法執行自訂原生程式碼（expo-modules、config plugins、未包含在 Expo Go 中的原生依賴）。
• Development build — 快照指令碼改為執行 expo run:ios / expo run:android，為每個專案 fixture 編譯原生開發用戶端。適用於輸出需要自訂原生程式碼的 Skill（否則會屬於 static-only 的案例）。速度慢得多 — expo run 會預先建置並原生編譯每個專案 fixture（需要數分鐘，尤其是第一次），且需要完整的 iOS/Android 建置工具鏈 — 因此僅在 Skill 確實需要原生程式碼時才選擇。消耗大量磁碟空間： 每個專案 fixture 的原生建置都高達數 GB。快照階段會在每個專案 fixture 執行後運行 clean-fixture.sh，以將峰值用量控制在大約一次建置的量，但對於 dev-build 執行，仍建議減少評測案例數量並使用單一平台，同時保持數 GB 的可用空間。clean-fixture.sh 會清除每個專案 fixture 的建置產出（node_modules、ios、android、.expo、dist 以及 fixture 的 iOS DerivedData），並保留 App 源碼與 git。控管 dev-build 磁碟空間的關鍵在於減少評測案例 + 單一平台 — 它只會回收每個專案 fixture 的建置產物，絕不會觸及 s...