Sponsor Suno AI Music arrow_forward
Subagent

Gem Browser Tester

E2E browser testing, UI/UX validation, visual regression.

Type
Subagent
GitHub stars
39.4k
License
MIT
Repo last updated
Sep 27, 2026

What Gem Browser Tester is

Gem Browser Tester is a subagent published in the github/awesome-copilot repository on GitHub, which has about 39.4k stars. The repository describes itself as: “Community-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.”

A subagent is a specialist assistant that Claude can hand part of a task to. It is a markdown file whose frontmatter sets a name, a description that tells Claude when to delegate, and optionally the tools and model it may use; the body becomes the subagent's own system prompt.

Because a subagent works in its own context, it keeps the main conversation focused: Claude can send a narrow job, such as a review or a specialised analysis, to Gem Browser Tester and get back a compact result.

How to install Gem Browser Tester

Claude Code

  1. Download gem-browser-tester.agent.md from the repository.
  2. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control.
  3. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Claude Cowork

  1. Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent.
  2. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

New to extending Cowork? Our plugins guide and Customize guide explain how skills, plugins, and connectors fit together.

Inside the source file

An excerpt from agents/gem-browser-tester.agent.md, shared under the repository's MIT license. Read the full file on GitHub.

E2E/flow tests, UI/UX, accessibility, visual regression. Never implement.

Execute E2E/flow tests, verify UI/UX, accessibility, visual regression. Never implement. No improvisation.

  • 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.
{
  "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,
  "evidence_path": "string",
  "learn": "string"
}
  • Prefer native semantic tools for discovery/diagnostics; CLI for execution or when simpler.
  • Batch independent calls/ steps; serialize dependencies/conflicts.
  • 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.
  • 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.

Before you install

  • Read the whole file first. Skills, commands, and subagents are instructions Claude will follow, so make sure they match what you want.
  • Check which tools, scripts, or MCP servers it uses. Local servers and scripts run with your permissions.
  • Try it in a test project or a copy of your files before pointing it at real work.
  • Pin the version you tested, and review changes before updating.
  • Watch for instructions that fetch web content or run shell commands; those are where prompt injection risks start. See our prompt injection guide.

FAQ

What is Gem Browser Tester?

Gem Browser Tester is a subagent for Claude Code and Claude Cowork from the github/awesome-copilot repository on GitHub. E2E browser testing, UI/UX validation, visual regression.

How do I install Gem Browser Tester in Claude Code?

Download gem-browser-tester.agent.md from the repository. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Can I use Gem Browser Tester in Claude Cowork?

Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

Is Gem Browser Tester safe to install?

It is a third-party community resource, not reviewed by Anthropic or this site. Read the source file first, check which tools and connectors it uses, and install only from sources you trust.

Similar resources

Browse all skills, subagents, and plugins →

Listing data comes from the public GitHub repository and was last checked in September 2026. Excerpts are © their authors and shared under MIT. This directory is independent and not affiliated with Anthropic or the resource's authors.