Expo 스킬 평가

Expo 스킬 평가은(는) 무엇을 하나요?

plugins/expo/skills/에 있는 스킬을 대상으로 트리거 정확도, 생성된 코드 품질, 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/).

시작하기 전에 — 범위 명확히 하기

파이프라인 작업 전에 다음 모든 사항을 미리 확인하세요. 건너뛰지 마세요 (해당 항목이 요청에 이미 명시된 경우에만 건너뛸 수 있습니다). 4개 이하의 질문으로 구성된 AskUserQuestion 호출로 묶어서 다음 순서대로 진행하세요:

1. 평가할 스킬 (요청에 명확하지 않은 경우).
2. 프롬프트 — 평가를 주도할 프롬프트. 빌트인 프롬프트(스킬의 평가 사례에서 가져옴)는 모두 미리 선택됩니다. 필요에 따라 일부를 제외하거나, 사용자 정의 텍스트 프롬프트를 추가하거나, 업로드된 스크린샷으로부터 빌드(스킬이 재현해야 할 대상 UI)할 수 있습니다. 아래 프롬프트를 참조하세요.
3. 검증 항목 — 세 가지 옵션 중 하나(다중 선택): 런타임 + 스크린샷 / 트리거 정확도 / 코드 검사(기기 없음). 아래 검증 항목을 참조하세요.
4. Expo SDK — 최신(기본값, 자동 감지) 또는 고정 버전.
5. 러너 — Expo Go(기본값) 또는 개발 빌드.
6. 플랫폼 — iOS / Android / 웹(항상 세 가지 모두 제시).
7. claude -p에 대한 권한 플래그 — 권한 건너뛰기(기본값) 또는 편집 수락.
8. 뷰어 전달 — 로컬 전용(기본값) 또는 공유 가능한 아티팩트 게시.
9. 트리거 정확도가 선택된 경우 — 게시된 expo 플러그인이 비활성화(또는 설치되지 않음)되었는지 확인.

각 항목은 아래에 자세히 설명되어 있습니다. 항목 4–6(SDK, 러너, 플랫폼)은 하나의 AskUserQuestion 호출에 자연스럽게 포함됩니다.

평가할 스킬이 요청에 명확하지 않은 경우, plugins/expo/skills/에서 사용 가능한 스킬을 나열하고 평가할 스킬을 물어보세요.

테스트 대상 스킬이 로드되는 방식 — 두 가지 메커니즘, 단계별로 하나씩 사용 (전역적으로 하나를 선택하지 마세요): 실행기는 파일 경로(SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md, 명시적으로 읽음)로 스킬을 참조하는 반면, 트리거 평가는 이를 플러그인(--plugin-dir plugins/expo로, 모델이 설명에서 자동 선택할 수 있도록 함)으로 로드합니다. 둘 다 로컬, 저장소 내 버전을 가리킵니다 — 그것이 당신이 평가하는 것입니다. 하네스 세션 자체를 시작하기 위해 특별한 플래그가 필요하지 않습니다 (하네스는 저장소 경로로 스킬을 찾습니다); 메커니즘은 하네스가 생성하는 claude -p 하위 프로세스에 적용됩니다. 각 단계가 다른 이유는 1단계와 3단계를 참조하세요. 한 가지 사전 실행 확인(트리거 평가가 포함된 경우 필수): 게시된 expo 플러그인이 설치/활성화된 경우, 하네스를 시작하기 전에 /plugin을 통해 비활성화하고 완료 후 다시 활성화하세요. 한 번의 비활성화는 이 세션과 생성된 claude -p 하위 프로세스 모두에 상속되는 전역 구성 변경입니다. 트리거 평가에 필수적인 이유: 해당 단계는 --plugin-dir을 통해 로컬 스킬을 로드하는데, 두 번째로 설치된 expo가 충돌을 일으킵니다 — 모델이 게시된 expo:expo-ui를 트리거할 수 있으며, 감지는 도구 호출 이름만 보므로 로컬 편집 대신 게시된 설명을 조용히 채점하게 됩니다(충돌로 인해 오류가 발생할 수도 있음). 실행기/런타임/정적 단계는 영향을 받지 않습니다 — --plugin-dir 없이 로컬 SKILL_PATH로 테스트 대상 스킬을 읽기 때문에, 트리거 평가 없이 실행하는 경우 비활성화를 건너뛸 수 있습니다. expo를 비활성화해도 expo-skill-eval(expo 플러그인의 일부가 아닌 독립 실행형 프로젝트 스킬)은 비활성화되지 않으므로 하네스를 계속 사용할 수 있습니다.

명시적인 사전 확인으로 사용자에게 이를 표시 — 평가할 스킬을 확인하는 것과 같은 방식입니다. 트리거 평가가 포함된 경우, 1단계를 시작하기 전에 게시된 expo 플러그인이 비활성화(또는 설치되지 않음)되었는지 확인하도록 사용자에게 요청하세요. 여전히 활성화된 경우, 일시 중지하고 /plugin을 통해 비활성화하도록 하세요. 사용자가 확인할 때까지 트리거 평가를 실행하지 마세요 — 하네스는 자체적으로 설치된 플러그인을 안정적으로 감지할 수 없습니다(전역 플러그인 구성 또는 claude plugin list를 읽으면 프롬프트가 표시됨). 따라서 이는 자동 확인이 아닌 수동 확인입니다.

프롬프트 선택 — 빌트인, 사용자 정의, 또는 대상 스크린샷. 프롬프트는 실행기(스킬 있음 및 스킬 없음)를 주도하는 입력이며, 검증하는 것과는 별개입니다. AskUserQuestion으로 확인하세요(요청에 이미 프롬프트가 명시된 경우 건너뜁니다):

• 빌트인 프롬프트 — 테스트 대상 스킬(SKILL.md + references/)과 references/runtime-matrix.md를 읽어 생성한 대표적인 프롬프트로, 스킬의 표준 사용 사례를 포괄합니다. (스킬이 이미 evals/evals.json에 평가 사례를 제공하는 경우 해당 prompt 필드도 포함하세요 — 하지만 대부분의 스킬은 그렇지 않으므로 일반적으로 직접 도출합니다.) 모두 미리 선택하여 기본 실행이 스킬의 표준 사례를 실행하도록 하세요. 사용자가 일부를 선택 해제할 수 있습니다.
• 사용자 정의 텍스트 프롬프트 — 사용자가 입력하는 일회성 프롬프트. 전용 옵션 슬롯을 사용하지 마세요: AskUserQuestion이 자동으로 "내용 입력"/기타 항목을 추가하고, 거기에 입력된 모든 내용이 사용자 정의 텍스트 사례가 됩니다.
• 업로드된 스크린샷에서 빌드 — 사용자가 대상 스크린샷(재현할 UI)의 경로를 제공합니다. 실행기에게 이를 열도록 지시합니다 — claude -p는 Read 도구로 PNG를 읽음 — 일치하는 앱을 빌드합니다. 사례는 경로를 reference_image로 기록하고, 평가는 생성된 앱을 해당 대상과 비교합니다(6단계). 이는 UI 스킬에 대한 가장 강력한 시각적 테스트입니다: "이것을 빌드하세요."

질문당 4개 옵션 제한을 우선 순위로 존중하세요 (피해야 할 버그: 업로드 옵션이 네 개의 슬롯이 채워지면 조용히 삭제됨):

1. "업로드된 스크린샷에서 빌드"를 위한 슬롯을 항상 확보하세요. 이것이 시각적 평가의 핵심이며, 절대 삭제되어서는 안 되는 옵션입니다.
2. 명시적인 "사용자 정의 텍스트 프롬프트" 옵션을 추가하지 마세요 — 자동 "내용 입력"/기타 항목이 이미 이를 포함합니다.
3. 나머지 ≤3개의 슬롯을 빌트인/대표 프롬프트로 채우되, 미리 선택하세요. 프롬프트가 3개를 초과하는 경우, 하나의 미리 선택된 "모든 빌트인 프롬프트(기본값)" 옵션으로 축소하고 짧은 후속 질문에서 하위 집합 선택을 제공하여 업로드 옵션을 계속 포함시키세요.

다중 선택으로 제시하세요. "업로드된 스크린샷에서 빌드"가 선택된 경우, 후속 질문에서 대상 이미지 경로를 물어보세요. 선택된 각 프롬프트(빌트인, 입력, 또는 이미지)는 하나의 평가 사례(스킬 있음 및 스킬 없음으로 실행)가 됩니다.

항상 검증할 항목을 확인하세요. 요청이 명확하지 않은 경우에만 해당합니다. 다음 옵션을 제시하고 사용자가 하나 이상 선택하도록 하세요(스킬의 references/runtime-matrix.md 항목을 기반으로 기본값은 굵게 표시):

옵션	설명	기본값으로 제안할 시기
런타임 + 스크린샷	전체 파이프라인: 픽스처 → 실행기 → 정적 게이트 → iOS/Android에서 앱 실행 및 스크린샷 촬영. 러너(Expo Go 또는 개발 빌드)는 별도 질문입니다. 여기서 이름을 지정하지 마세요.	앱 화면을 렌더링하는 모든 스킬에 대한 기본값(references/runtime-matrix.md의 expo-go/dev-build 행). 부팅된 시뮬레이터/에뮬레이터가 필요합니다.
트리거 정확도	claude -p를 통해 현실적인 프롬프트를 실행하고, 스킬이 읽혔는지 확인합니다. 재현율 측정(트리거되어야 하는 쿼리만).	항상 독립적인 검사로 유용합니다.
코드 검사(기기 없음)	tsc --noEmit + 차이 인식 린트 + expo export, 그리고 평가기는 제공된 사용자 정의 기대 사항에 대해 생성된 코드를 확인합니다. 기기 없음.	static-only 및 n/a 스킬에 대한 기본값, 그리고 앱을 실행하지 않고 코드 패턴(올바른 가져오기 경로, Host 래퍼 등)을 확인하려는 경우.

이를 하나의 다중 선택 질문으로 제시하세요 — "무엇을 검증하시겠습니까?" 이는 평가 차원(빌드된 것을 판단하는 방법)으로, 프롬프트 단계(무엇을 빌드할지)와는 구별됩니다. 사용자는 모든 조합을 선택할 수 있습니다. 프롬프트가 업로드된 스크린샷인 경우(위 프롬프트 참조), **"런타임 + 스크린샷"**을 포함하여 하네스가 생성된 앱을 캡처하고 평가기가 이를 대상과 비교하여 점수를 매길 수 있도록 합니다.

기본 모드를 제안하기 전에 references/runtime-matrix.md를 읽으세요. 요청에 이미 모드가 명시된 경우(예: "트리거만 확인", "기기에서 실행"), 질문을 건너뛰고 진행하세요.

Expo SDK 버전 선택 — 한 번, 미리. bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh로 최신 버전을 감지하세요(주 버전을 출력, 예: 56; 내부적으로 bun을 사용하여 npm view expo dist-tags --json을 실행하고 JSON.parse/semver로 주 버전을 읽으며, bash-스크립트 규칙에 포함되므로 프롬프트가 발생하는 레지스트리 쿼리를 직접 인라인으로 실행하지 마세요). 그런 다음 AskUserQuestion으로 확인하세요: 최신 SDK를 기본값으로 하고, 사용자가 이전 버전을 고정(예: 버전별 문제 재현)하도록 하세요. 픽스처가 빌드되는 모든 곳에서 선택된 버전을 사용하세요 — make-fixture.sh에 <sdk> 인수로 전달하고 각 평가 사례의 runtime.sdk에 기록하세요. 요청에 이미 버전이 명시된 경우(예: "SDK 54에서 평가"), 감지를 건너뛰고 해당 버전을 사용하세요.

최신 버전을 기본값으로 사용 — expo start가 기기에 설치하는 Expo Go와 호환됩니다. 기기의 설치된 Expo Go 보다 오래된 SDK를 고정하면 expo start가 "권장 Expo Go 버전을 설치하시겠습니까?"라는 프롬프트를 표시하려고 시도합니다. TTY가 없으면(스냅샷 스크립트가 stdin을 /dev/null에서 읽음) Input is required, but 'npx expo' is in non-interactive mode 오류와 함께 중단되어 모든 스냅샷이 실패합니다. 따라서 시뮬레이터/에뮬레이터에 일치하는 Expo Go를 사전 설치하지 않는 한 이전 SDK를 고정하지 마세요. 그렇지 않으면 최신 버전을 고수하세요.

러너 선택 — Expo Go(기본값) 또는 개발 빌드. AskUserQuestion으로 물어보세요(요청에 이미 명시된 경우 건너뜁니다):

• Expo Go(기본값) — 스냅샷 스크립트가 expo start --ios / expo start --android로 앱을 그대로 실행합니다. 빠름(네이티브 컴파일 없음), Expo Go가 번들하는 모든 것(@expo/ui 포함, SDK 56+에서)을 실행합니다. 사용자 정의 네이티브 코드(expo-modules, 구성 플러그인, Expo Go에 없는 네이티브 종속성)를 실행할 수 없습니다.
• 개발 빌드 — 스냅샷 스크립트가 대신 expo run:ios / expo run:android를 실행하여 픽스처당 네이티브 개발 클라이언트를 컴파일합니다. 출력에 사용자 정의 네이티브 코드가 필요한 스킬(그렇지 않으면 static-only가 되는 사례)에 사용하세요. 훨씬 느림 — expo run은 각 픽스처를 사전 빌드하고 네이티브로 컴파일합니다(수분 소요, 특히 처음), 전체 iOS/Android 빌드 도구 체인이 필요합니다 — 따라서 스킬이 실제로 네이티브 코드를 필요로 하는 경우에만 선택하세요. 디스크 사용량 많음: 각 픽스처의 네이티브 빌드는 수 GB입니다. 스냅샷 단계는 픽스처 후 clean-fixture.sh를 실행하여 최대 사용량을 ~한 빌드로 유지하지만, 개발 빌드 실행에는 더 적은 평가 사례와 단일 플랫폼을 선호하고 몇 GB의 여유 공간을 유지하세요. clean-fixture.sh는 픽스처별 빌드 출력(node_modules, ios, android, .expo, dist, 및 픽스처의 iOS DerivedData)을 제거하고 앱 소스 + git은 유지합니다. 개발 빌드 디스크의 핵심은 더 적은 평가 사례 + 하나의 플랫폼입니다 — 픽스처별 빌드 출력만 회수하고 공유 종속성 캐시는 건드리지 않으므로 아무것도 다시 다운로드되지 않습니다.

EXPO_SKILL_EVAL_RUNNER 환경 변수(expo-go 기본값 또는 dev-build)를 통해 선택 사항을 스냅샷 스크립트에 전달하고 각 평가 사례의 runtime.mode(expo-go 또는 dev-build)에 반영하세요. 5단계를 참조하세요.

플랫폼 선택 — 스킬에 관계없이 항상 물어보세요. iOS / Android / 웹(다중 선택)을 AskUserQuestion으로 제시하세요. iOS + Android를 기본값으로 하고 웹을 항상 옵션으로 제시하세요. 스킬별로 사전 필터링하지 마세요. 웹은 대부분의 스킬에 유효한 선택입니다: @expo/ui의 범용 구성 요소(Host, Row, Column, Button, List, …)는 웹에서 렌더링되며, expo-dom, NativeWind/Tailwind, API 경로, 일반 React Native도 마찬가지입니다. 웹에 표시되지 않는 유일한 것은 플랫폼별 네이티브 트리(@expo/ui/swift-ui 또는 @expo/ui/jetpack-compose)이며, 이는 빈 화면을 렌더링합니다 — 그리고 그 빈 화면 자체가 유용한 신호이므로 여전히 사용자의 결정입니다. 웹은 snapshot-web.sh(expo start --web + Playwright/Chromium)를 통해 러너에 관계없이 실행되며(expo run은 네이티브 전용, 웹 개발 빌드 없음), 가장 덜 사용되는 경로입니다. 선택한 세트를 각 평가 사례의 runtime.platforms에 기록하고 run_snapshots.py가 이를 반복하도록 하세요.

claude -p 하위 프로세스 실행 방식 확인 — 시작하기 전에 한 번. AskUserQuestion으로 --dangerously-skip-permissions로 실행해도 되는지 물어보고, 동일한 답변을 이 실행의 모든 하위 프로세스에 적용하세요(실행 중에 다시 묻지 않음):

• 권한 건너뛰기(권장) — --dangerously-skip-permissions를 전달합니다. 각 하위 프로세스는 /private/tmp/expo-skill-eval-* 아래의 임시 픽스처 내에서 무인으로 실행되며, 프롬프트 없이 파일을 쓰고 설정 명령을 실행할 수 있습니다.
• 편집만 수락 — 대신 --permission-mode acceptEdits를 전달합니다. Bash/설치는 자동으로 거부되므로(TTY 없음), 일부 평가는 부분적인 출력을 생성할 수 있습니다.

두 플래그 없이 claude -p를 사용하면 파일을 전혀 쓸 수 없습니다. 요청에 이미 선호 사항이 명시된 경우(예: "권한 건너뛰기", "위험 플래그 사용 안 함"), 질문을 건너뜁니다.

결과 뷰어 전달 방식 확인 — 시작하기 전에 한 번. claude.ai에 게시하는 것은 외부로 공개되므로 실행 중에 갑자기 수행하지 마세요. 동일한 사전 AskUserQuestion(권한 플래그와 함께)에서 물어보세요:

• 로컬 전용(기본값) — generate_viewer.py가 viewer.html을 작성하고 로컬 브라우저에서 엽니다. 아무것도 기기를 떠나지 않습니다.
• 공유 가능한 아티팩트 게시 — 추가로 마지막에 뷰어를 claude.ai 아티팩트(사용자가 팀원과 공유할 수 있는 기본 비공개 웹 페이지)로 렌더링합니다. 사용자가 여기에서 동의하는 경우에만 수행하세요.

요청에 이미 공유/게시 여부가 명시된 경우 질문을 건너뜁니다. 게시 메커니즘은 뷰어 섹션을 참조하세요.

평가 사례 스키마

선택한 각 프롬프트에 대해 실행의 평가 사례를 하나씩 생성하고 <workspace>/iteration-N/evals.json에 기록합니다(뷰어는 여기서 읽음). 각 사례는...