
Ce Test Browser
Run end-to-end browser checks on only the pages touched by your current branch or PR before you merge.
Overview
ce-test-browser is an agent skill for the Ship phase that runs end-to-end browser tests on pages affected by the current PR or branch using the agent-browser CLI.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-test-browserWhat is this skill?
- Scopes test targets from git diff against the PR or branch instead of retesting the whole app
- Uses the agent-browser CLI exclusively—no Chrome MCP or alternate browser controllers
- Covers open, click, fill forms, screenshots, and rendered-content scraping
- Hard-stops with a pointer to /ce-setup when agent-browser is missing
- Documents Claude Code vs Codex anti-patterns (e.g. skip mcp__claude-in-chrome__*)
Adoption & trust: 1.5k installs on skills.sh; 20.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You merged-looking changes locally but do not know whether the touched routes still work in a real browser without manually clicking every flow.
Who is it for?
Solo builders with a git branch or open PR, a running dev server, and agent-browser installed who want quick UI smoke on changed pages only.
Skip if: Teams without a local web app, API-only backends with no rendered UI, or workflows that insist on Chrome MCP or non-agent-browser automation.
When should I use this skill?
Run browser tests on pages affected by current PR or branch; argument-hint: PR number, branch name, 'current', or --port PORT.
What do I get? / Deliverables
After the skill runs you have agent-browser-driven checks and captures scoped to PR or branch deltas, ready to fold into review or merge decisions.
- Browser test pass/fail narrative for affected pages
- Screenshots and scraped rendered content from agent-browser runs
Recommended Skills
Journey fit
Browser E2E validation belongs on the Ship shelf because it gates merge readiness after code exists. Testing subphase is where agents exercise real UI flows against a live dev server, not where features are authored.
How it compares
Use for diff-scoped browser smoke via agent-browser instead of ad-hoc manual QA or a generic full-site crawl skill.
Common Questions / FAQ
Who is ce-test-browser for?
Indie and solo developers shipping web frontends with Claude Code or Codex who want the agent to validate only routes changed on the current PR or branch.
When should I use ce-test-browser?
Use it in Ship (testing) before merge when you have bin/dev or npm run dev up and need E2E confidence on affected pages; also when validating a prototype branch after Validate work lands in Build.
Is ce-test-browser safe to install?
It needs shell, git, filesystem, and browser automation against your local server—review the Security Audits panel on this Prism page and treat browser tooling like any code that can drive your machine.
SKILL.md
READMESKILL.md - Ce Test Browser
# Browser Test Skill Run end-to-end browser tests on pages affected by a PR or branch changes using the `agent-browser` CLI. ## Use `agent-browser` Only For Browser Automation This workflow uses the `agent-browser` CLI exclusively. Do not use any alternative browser automation system, browser MCP integration, or built-in browser-control tool. If the platform offers multiple ways to control a browser, always choose `agent-browser`. Use `agent-browser` for: opening pages, clicking elements, filling forms, taking screenshots, and scraping rendered content. Platform-specific hints: - In Claude Code, do not use Chrome MCP tools (`mcp__claude-in-chrome__*`). - In Codex, do not substitute unrelated browsing tools. ## Prerequisites - Local development server running (e.g., `bin/dev`, `rails server`, `npm run dev`) - `agent-browser` CLI installed (see Setup below) - Git repository with changes to test ## Setup Check whether `agent-browser` is installed: ```bash command -v agent-browser >/dev/null 2>&1 && echo "Installed" || echo "NOT INSTALLED" ``` If not installed, inform the user: "`agent-browser` is not installed. Run `/ce-setup` to install required dependencies." Then stop — this skill cannot function without agent-browser. ## Workflow ### 1. Verify Installation Before starting, verify `agent-browser` is available: ```bash command -v agent-browser >/dev/null 2>&1 && echo "Ready" || echo "NOT INSTALLED" ``` If not installed, inform the user: "`agent-browser` is not installed. Run `/ce-setup` to install required dependencies." Then stop. ### 2. Ask Browser Mode **Pipeline mode (`mode:pipeline`):** Skip this step entirely. Default to headless — no question, no blocking. Proceed directly to step 3. **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_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to presenting options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question: ``` Do you want to watch the browser tests run? 1. Headed (watch) - Opens visible browser window so you can see tests run 2. Headless (faster) - Runs in background, faster but invisible ``` Store the choice and use the `--headed` flag when the user selects option 1. ### 3. Determine Test Scope **If PR number provided:** ```bash gh pr view [number] --json files -q '.files[].path' ``` **If 'current' or empty:** ```bash git diff --name-only main...HEAD ``` **If branch name provided:** ```bash git diff --name-only main...[branch] ``` ### 4. Map Files to Routes Map changed files to testable routes: | File Pattern | Route(s) | |-------------|----------| | `app/views/users/*` | `/users`, `/users/:id`, `/users/new` | | `app/controllers/settings_controller.rb` | `/settings` | | `app/javascript/controllers/*_controller.js` | Pages using that Stimulus controller | | `app/components/*_component.rb` | Pages rendering that component | | `app/views/layouts/*` | All pages (test homepage at minimum) | | `app/assets/stylesheets/*` | Visual regression on key pages | | `app/helpers/*_helper.rb` | Pages using that helper | | `src/app/*` (Next.js) | Corresponding routes | | `src/components/*` | Pages using those components | Build a list of URLs to test based on the mapping. ### 5. Detect and Claim a Free Port **Pipeline mode only (`mode:pipeline`):** When invoked from LFG or another automated pipeline, always find a port that is actually free — never assume 3000 is available, as multiple agents may be running in parallel on the