CE Test Browser by @every · Skillet

CE Test Browser by @every · Skillet

Select the driver per the policy above and record it. This also requires a git repository with changes to test.
Determine test scope from the argument: a PR number → gh pr view [number] --json files -q '.files[].path'; current or empty → git diff --name-only main...HEAD; a branch name → git diff --name-only main...[branch].
Map changed files to routes and build the list of URLs to test.
Determine the dev server port. scripts/resolve-port.sh owns the resolution and prints the port alone on stdout: an explicit port argument; else a --port flag in a package.json dev/start script; else PORT= in .env, .env.local, or .env.development; else 3000. Pass an explicit port when the user gave --port N, or when your active project instructions already in context state the dev-server port — don't grep instruction files for one, since prose mentions in docs, examples, and troubleshooting are unreliable and false-positive-prone while config files and .env are trustworthy. Each mode runs the script in the shell call that needs the port, so no port value has to survive between shell calls or be transcribed out of prose; the reference gives the command. Manual mode uses that port as-is: the user controls their own server, so do not scan for alternatives.
Verify the dev server is running before asking the headed/headless question — a manual run with no server stops here, so asking first would waste the question.
Set visibility, then verify the root. Visibility is independent from unattended execution:
- Host-native integrated browser: keep its normal integrated surface visible and non-blocking so the user can watch progress when useful. Do not repeatedly steal focus as routes change. This applies in both manual and pipeline modes.
- agent-browser fallback, pipeline mode: run headless without asking.
- agent-browser fallback, manual mode: ask the user whether to run headed or headless using the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded), request_user_input in Codex, ask_question in Antigravity CLI (agy), ask_user in Pi (requires the pi-ask-user extension). Fall back to presenting options on the host's user-visible chat surface only when no blocking tool exists in the harness or the call errors. Never silently skip the question.
Then navigate to http://localhost:<port>, capture its rendered or interactive state, and confirm the root is served before iterating.
Test each affected page — navigate, inspect fresh state, exercise the critical interactions, capture evidence.
Human verification where a flow needs external interaction (OAuth, email, payments, SMS, third-party APIs): pause and ask. Pipeline mode does not pause — log each such flow as Skip with the reason and continue.
Handle failures by capturing the error state and the exact repro, then asking whether to fix now or skip. Pipeline mode does not ask — log the failure and continue.
Report the summary in the format the reference gives.