preflight
The foundation for every TestBeagle skill: read-only discovery that answers "can this repo be run and tested locally, and how?" before anyone launches, seeds, or captures anything. The other skills (bugsweep, breachsweep, a11ysweep, perfsweep, casewright, scriptify) start by reusing preflight's findings and stop if the repo isn't locally testable.
When to use
- Before any QA/test run, or when the user asks "이 레포 테스트 가능한 환경이야?" / "how do I run this locally?"
- Standalone, to produce a testability report without running anything.
Workflow (read-only — make no changes)
- Detect targets. Classify each runnable surface: web (Vite/Next/webpack,
index.html), iOS (*.xcodeproj/*.xcworkspace), android (build.gradle* + AndroidManifest.xml), api (server framework + health route, no UI), cli (bin/TUI entry). A monorepo yields several — enumerate all.
- Toolchain doctor. For each target, check the tools it needs exist and their versions: node/pnpm/npm, Xcode +
xcrun simctl, Android SDK adb, docker/compose, plus any repo-declared version pins. For web targets also resolve the driver per ../beagle-shared/drivers-web.md: the repo's own E2E runner, agent-browser --version, a connected browser MCP, or only headless Chrome (capture-only). Record what's missing with the install command to fix it (e.g. brew install agent-browser).
- Discover how it runs. Read
README, AGENTS.md, CLAUDE.md, package.json scripts, scripts/, Makefile, docker-compose*. Extract the exact local-run command per target and the env it needs (API base URL, ports, .env).
- Readiness method. Find how to know it's up by evidence: a health/ready endpoint to poll, a build-success marker to grep (never trust an exit code — some build wrappers exit 0 on failure). Note any documented gotchas.
- Existing tooling to reuse. Inventory seed scripts, deep-link/"review" capture modes, existing capture scripts, and prior QA reports. Downstream skills must reuse these, not reinvent them.
- Output location. Resolve where screenshots/video/reports should go via
../beagle-shared/capture-output.md and propose it.
Output — testability report
Report, in Korean by default, using the header/anti-slop conventions in ../beagle-shared/report-base.md:
- 판정: 각 타깃별 로컬 테스트 가능 / 불가(부족한 것 + 설치 명령).
- 실행 계획: 타깃별 실행 명령 · 필요한 env · readiness 확인법.
- 재사용 자산: 발견한 시드/review-mode/캡쳐 스크립트/기존 보고서 경로.
- 제안 출력 위치: 스크린샷·영상·리포트 경로.
- 드라이버: 각 타깃에 쓸 드라이버(
../beagle-shared/drivers-web.md / ../beagle-shared/drivers-mobile.md)와 그 한계(예: simctl 탭 불가, agent-browser·브라우저 MCP 둘 다 없으면 캡쳐 전용).
Downstream skills read this report and gate on it: if a target is "테스트 불가", say so and don't pretend to test it.
1---2name: preflight3description: Use when starting any app QA or test run, to check whether a repo can be run and tested locally — detect project type, verify the toolchain, discover how it runs and where screenshots/media should go — before capturing or testing. Triggers on "테스트 가능한 환경인지", "환경 점검", "preflight", "can I run this locally".4---56# preflight78The foundation for every TestBeagle skill: read-only discovery that answers "can this repo be run and tested locally, and how?" before anyone launches, seeds, or captures anything. The other skills (bugsweep, breachsweep, a11ysweep, perfsweep, casewright, scriptify) start by reusing preflight's findings and stop if the repo isn't locally testable.910## When to use1112- Before any QA/test run, or when the user asks "이 레포 테스트 가능한 환경이야?" / "how do I run this locally?"13- Standalone, to produce a testability report without running anything.1415## Workflow (read-only — make no changes)16171. **Detect targets.** Classify each runnable surface: web (Vite/Next/webpack, `index.html`), iOS (`*.xcodeproj`/`*.xcworkspace`), android (`build.gradle*` + `AndroidManifest.xml`), api (server framework + health route, no UI), cli (bin/TUI entry). A monorepo yields several — enumerate all.182. **Toolchain doctor.** For each target, check the tools it needs exist and their versions: node/pnpm/npm, Xcode + `xcrun simctl`, Android SDK `adb`, docker/compose, plus any repo-declared version pins. For web targets also resolve the driver per `../beagle-shared/drivers-web.md`: the repo's own E2E runner, `agent-browser --version`, a connected browser MCP, or only headless Chrome (capture-only). Record what's missing with the install command to fix it (e.g. `brew install agent-browser`).193. **Discover how it runs.** Read `README`, `AGENTS.md`, `CLAUDE.md`, `package.json` scripts, `scripts/`, `Makefile`, `docker-compose*`. Extract the exact local-run command per target and the env it needs (API base URL, ports, `.env`).204. **Readiness method.** Find how to know it's up by evidence: a health/ready endpoint to poll, a build-success marker to grep (never trust an exit code — some build wrappers exit 0 on failure). Note any documented gotchas.215. **Existing tooling to reuse.** Inventory seed scripts, deep-link/"review" capture modes, existing capture scripts, and prior QA reports. Downstream skills must reuse these, not reinvent them.226. **Output location.** Resolve where screenshots/video/reports should go via `../beagle-shared/capture-output.md` and propose it.2324## Output — testability report2526Report, in Korean by default, using the header/anti-slop conventions in `../beagle-shared/report-base.md`:2728- **판정**: 각 타깃별 로컬 테스트 가능 / 불가(부족한 것 + 설치 명령).29- **실행 계획**: 타깃별 실행 명령 · 필요한 env · readiness 확인법.30- **재사용 자산**: 발견한 시드/review-mode/캡쳐 스크립트/기존 보고서 경로.31- **제안 출력 위치**: 스크린샷·영상·리포트 경로.32- **드라이버**: 각 타깃에 쓸 드라이버(`../beagle-shared/drivers-web.md` / `../beagle-shared/drivers-mobile.md`)와 그 한계(예: simctl 탭 불가, agent-browser·브라우저 MCP 둘 다 없으면 캡쳐 전용).3334Downstream skills read this report and gate on it: if a target is "테스트 불가", say so and don't pretend to test it.
TestBeagle