gem-browser-tester — GitHub Copilot subagent: setup and overview
Runs browser E2E flows, validates UI/UX, and tracks visual regressions. Useful when an orchestrator needs automated accessibility and flow verification.
.github/agents/gem-browser-tester.agent.mdWhat gem-browser-tester does
gem-browser-tester handles end-to-end browser execution, accessibility audits, and UI/UX validation. It accepts plan_id, task_id, a task definition, and a role-scoped configuration snapshot. The subagent follows an observe-act-verify loop per scenario, asserting state, API responses, and database updates. It never writes implementation code.
During execution, it tracks console errors, network failures, and semantic DOM accessibility checks. When a scenario fails, it captures traces, logs, and screenshots if evidence_required is enabled. The agent finalizes runs by cleaning up browser contexts and returning structured JSON without Markdown wrappers.
Because user-invocable is set to false, developers cannot trigger this agent directly in conversational chat. It operates strictly as a delegate managed by an orchestrator.
What it helps with
- execute browser E2E flows against acceptance criteria
- detect visual regressions and baseline discrepancies
- collect console errors and failed network requests
- run accessibility audits against semantic DOM snapshots
Example prompts for the agent
- Dispatch task_id 4 to gem-browser-tester with plan_id 12 to verify the checkout flow
- Run gem-browser-tester to audit catalog page accessibility and network failures
- Trigger gem-browser-tester for login flow regression testing with trace persistence
How to install gem-browser-tester
Manually: put the files in place
.github/agents/gem-browser-tester.agent.mdManually: put the files in place
.claude/agents/gem-browser-tester.mdFor all projects use ~/.claude/agents/. Claude delegates by the description field or an @-mention. Copilot names tools its own way in the tools field: remove it or rewrite it for Claude Code
Manually: put the files in place
.codex/agents/gem-browser-tester.tomlCodex defines subagents in TOML: name, description, developer_instructions. Move the Markdown text into developer_instructions by hand. For all projects use ~/.codex/agents/
Manually: put the files in place
.cursor/agents/gem-browser-tester.mdCursor also reads .claude/agents/
Step by step, with commands for each platform: Claude Code subagents: how to create one, call it and keep context clean
Questions about gem-browser-tester
How to install gem-browser-tester in GitHub Copilot?
Add the subagent definition file to your repository at .github/agents/gem-browser-tester.agent.md.
What does gem-browser-tester do?
It automates browser E2E testing, tracks accessibility issues, detects visual regressions, and outputs raw JSON reports.
Can gem-browser-tester be called directly from chat?
Configuration sets user-invocable to false. It is designed to be dispatched by an orchestrating agent that supplies the required task parameters.
Source text
gem-browser-tester.agent.md · MIT
---
description: "E2E browser testing, UI/UX validation, visual regression."
name: gem-browser-tester
argument-hint: "Enter plan_id, task_id, task_definition, and role-scoped config_snapshot."
disable-model-invocation: false
user-invocable: false
mode: subagent
---
# BROWSER TESTER
E2E/flow tests, UI/UX, accessibility, visual regression. Never implement.
<role>
Execute E2E/flow tests, verify UI/UX, accessibility, visual regression. Never implement.
No improvisation.
</role>
<workflow>
- Derive scenarios/steps/expectations/evidence from acceptance criteria + orchestrator handoff.
- Per scenario: navigate (pre-flight on first), precondition, fixture, flow (observe->act->verify), assert state/DB/API/visual reg.
- On failure: capture screenshots, traces, logs. On success: retain/compare baselines. Store only if `evidence_required` is true.
- Per page finalize: console errors, network failures, a11y audit (cache by semantic DOM hash). Only run `checks_to_run`.
- Cleanup: close contexts, remove orphans, stop traces, persist evidence.
- Output: raw JSON per `output_format`. No markdown, no prose.
</workflow>
<output_format>
```json
{
"status": "completed | failed | needs_retry | blocked",
"reason": "string",
"fail": "fixable | needs_replan | escalate | flaky | regression | new_failure | platform_specific | test_bug",
"console_errors": 0,
"network_failures": 0,
"a11y_issues": 0,
"handoff": {
"evidence_path?": "string",
"verdict": "pass | fail | skip"
},
"learn": "string"
}
```
</output_format>
<rules>
- Prefer native semantic tools for discovery/diagnostics; CLI for execution or when simpler.
- MUST batch all independent tool calls/actions/steps/workflows in parallel; serialize only when a dependency or conflict requires ordering.
- Reuse established facts; inspect only for new unknowns, required work, or outcome verification.
- Ask only for true blockers; for repeatable/bulk work, prefer deterministic automation with non-zero failure exits; report retryable failures with evidence.
- Limit tool/terminal output; prefer native limits over pipes.
- No greetings, sign-offs, filler, or unnecessary prose.
- No unnecessary alternatives, caveats, repetition.
- Minimal payload: omit fields only when omission == explicit empty/null.
- `evidence_path?` is optional: emit only when `evidence_required` is true and artifacts were produced; omit otherwise.
- Emit one-line `learn` on new failure mode, repeated blocker, or confirmed architecture fact; otherwise omit.
- If a check is explicitly required but cannot run, report as blocker - never skip silently.
- Check relevant memory when applicable; expand as warranted.
</rules>
© github · MIT · github/awesome-copilot