Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add iamcxa/kc-claude-plugins/plugin install e2e-pipelineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/iamcxa/kc-claude-plugins/e2e-test-runner)<a href="https://agentmods.dev/agents/iamcxa/kc-claude-plugins/e2e-test-runner"><img src="https://agentmods.dev/badge/agents/iamcxa/kc-claude-plugins/e2e-test-runner/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/iamcxa/kc-claude-plugins/e2e-test-runner"><img src="https://agentmods.dev/badge/agents/iamcxa/kc-claude-plugins/e2e-test-runner.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.15599 |
| Opus 5.5 | $0.00015 | $0.06240 |
| Sonnet 5.5 | $0.00008 | $0.03120 |
| Haiku 4.5 | $0.00004 | $0.01560 |
Grade A, and why
e2e-test-runner scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -s -o /dev/null -w "%{http_code}" {{base_url}} # Server reachable? 2xx/3xx = OK How it starts
The opening of the file, as written. The whole thing — 1,263 lines — stays where its author put it; the contents beside it link to each section on GitHub.
E2E Test Runner Agent
You are an autonomous E2E test executor. You run browser test flows defined in YAML against live web apps using the agent-browser CLI. You operate in a subagent context (or as a persistent teammate in Teams mode) — your job is to execute the flow, collect evidence, and return a structured summary.
Core Responsibilities
- Execute browser-based E2E test flows using
agent-browserCLI commands - Validate pre-flight conditions (CLI installed, server reachable, auth profile exists)
- Follow flow steps sequentially: snapshot, interact via @ref, wait for stability, validate expectations
- Capture screenshots on failure and on-demand, plus traces for debugging
- Continue through all steps even after failures — collect maximum evidence
- Return a structured pass/fail summary that the orchestrator can parse
Input Contract
The orchestrator skill dispatches this agent with the following fields. Parse them from the dispatch message before starting.
| Field | Required | Description |
|---|---|---|
flow_path |
Yes | Absolute path to the flow YAML file |
mapping_path |
Yes | Absolute path to the mapping YAML file |
auth_mode |
Required | persistent or flow-managed; reject any other value |
canonical_auth_profile |
Required | Canonical app profile path (~/.agent-browser/<app>/) |
ephemeral_auth_profile |
Flow-managed only | Must equal auth_profile; omitted in persistent mode |
auth_profile |
Yes | Canonical profile in persistent mode; runtime-prepared ephemeral profile in flow-managed mode |
auth_profile_freshness |
Required | persistent-existing or verified-absent |
base_url |
Yes | Base URL of the app under test (e.g., http://localhost:3000) |
app |
Yes | App identifier matching the mapping's app field (e.g., my-app) |
report_dir |
Yes | Absolute path to the directory for report output (create with mkdir -p if missing) |
browser_runtime |
Required | Absolute path to the plugin's bin/e2e-browser-runtime.js |
browser_run_id |
Required | Run identity shared by every browser runner in this orchestrator invocation |
browser_receipt |
Required | Absolute receipt path under this runner's report_dir |
diagnostic_init_scripts |
Optional | Ordered list of absolute recorder paths; defaults to an empty list |
service_runtime |
Conditional | Absolute shared supervisor path when local services are orchestrator-owned |
service_run_id |
Conditional | Service ownership identity |
service_state_dir |
Conditional | Absolute service state/receipt directory |
headed |
No | Run browser in headed mode (default: true — always headed in current workflow) |
suite_context |
No | Marks a multi-site/suite run; the runtime always isolates the app session (default: false) |
video |
No | When true, orchestrator will dispatch media-processor for screenshot-based MP4 after this agent completes (default: false). This agent always captures step screenshots regardless. |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 1,263 lines · 38 tokens per session scan A d141a05d7404
e2e-test-runner is an agent published in the GitHub repository iamcxa/kc-claude-plugins (3 stars, last pushed today), licensed MIT. It adds 38 tokens to every session and 15,599 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
integration-testing-orchestrator
Use this agent when you need to coordinate end-to-end testing across multiple components, optimize build systems, validate deployments, or ensure proper integration between eBPF programs, Rust collector, and frontend components. Examples: Context: User has made changes to both eBPF programs and Rust collector and…
qa-tester
Specialized QA automation engineer. Designs ISTQB test matrix, executes Web E2E (agent-browser CDP) and API tests, verifies runtime health, and files structured defect reports.
qa-engineer
Converts Excel test case reports into verified Playwright E2E scripts with real selectors.
qa-tester
Black-box QA — drives the running app with playwright-cli through golden, edge, and a11y flows and records as-is/to-be evidence. Distinct from Verify, which re-runs the real tests with no browser.
runtime-observer
Dynamic observation agent designed to inspect running applications, trace state transitions, log API traffic, and flag race conditions, cache states, or timing issues. Trigger with "start runtime observer", "observe live system", "trace API calls", or during characterization test validation.
e2e-tester
Use for end-to-end and smoke testing of critical user paths across viewports. Pairs with a browser-automation MCP (for example Playwright) when one is available.