Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/c9r-io/orchestrator/e2e-testingnpx skills add c9r-io/orchestrator --skill e2e-testinggit clone --depth 1 https://github.com/c9r-io/orchestratorWrote 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/skills/c9r-io/orchestrator/e2e-testing)<a href="https://agentmods.dev/skills/c9r-io/orchestrator/e2e-testing"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/e2e-testing.svg" alt="Measured on agentmods" 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 | $0.00036 | $0.00471 |
| Opus 5 | $0.00018 | $0.00235 |
| Sonnet 5 | $0.00007 | $0.00094 |
| Haiku 4.5 | $0.00004 | $0.00047 |
Grade A, and why
e2e-testing scanned grade A with 0 findings 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 5d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
E2E Testing (Playwright)
Use the existing Playwright configuration and a small set of stable, behavior-focused journeys.
Repository Layout
- Frontend package:
gui/package.json - Playwright config:
gui/playwright.config.ts - Browser tests:
gui/tests/e2e/ - Default test server: the Vite server declared by the Playwright config
- Native host:
crates/gui/; use Tauri-specific tests only when native commands are in scope
Do not assume Docker Compose, Kubernetes, or a legacy portal tree. If a different target repository owns those surfaces, discover and verify them there first.
Run Existing Tests
cd gui
npm run test:e2e
Use the package's test:all script when unit, coverage, E2E, and build evidence are all required. Install browsers or packages only with user approval when the environment is missing them.
Authoring Tests
- Prefer
getByRole,getByLabel, and accessible names over CSS structure. - Avoid sleeps; wait for visible state, URLs, responses, or emitted events.
- Keep each scenario narrow and deterministic.
- Use the existing mock and transport boundaries. If a daemon is required, apply a deterministic fixture from
fixtures/manifests/bundles/and isolate it by project. - Capture a trace or screenshot for failures when the config supports it.
Example:
import { expect, test } from "@playwright/test";
test("critical control remains reachable", async ({ page }) => {
await page.goto("/");
await expect(page.getByRole("main")).toBeVisible();
});
Flake Triage
- Re-run the single failing spec with the same revision and server state.
- Inspect the retained trace and browser console.
- Replace timing assumptions and shared state with explicit conditions and setup.
- Re-run the single spec, then
npm run test:e2e, then the relevant build/tests.
Never weaken an assertion or add retries without identifying the nondeterministic boundary.
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.
- 5d ago First seen · 56 lines · 36 tokens per session scan A 64cdec48156d
e2e-testing is a skill published in the GitHub repository c9r-io/orchestrator (21 stars, last pushed 3d ago), licensed MIT. It adds 36 tokens to every session and 471 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
webapp-testing
Start/reuse a local app, wait for readiness, inspect rendered state/console/network, act from observed selectors, and verify with evidence.
tutti-workspace-app-factory
Create, convert, or repair one Tutti workspace app as either a self-contained publishable package under package/ or a Chrome-style local debug app under .tutti/dev-app/. Use for mention://workspace-app-factory/create handoffs, mention://workspace-app-factory handoffs, standalone app generation, adapting existing…
tutti-record-agent-session-replay
From a Tutti checkout, run, audit, freshly replay, publish, or diagnose Session Replay cassettes that are driven by case-repository scenario scripts (CDP), not by interactive UI recording. Use for real-Provider capture while a scenario.mjs executes, cassette transport or semantic-state mismatches, fresh replay…
qa
Browser-based QA verification. Launches a real browser, navigates the app, clicks buttons, fills forms, and tests user flows. Works as a standalone skill or as a phase end condition in campaigns. Requires Playwright (optional dependency, graceful skip if not installed).
browser
Browser automation via the agent-browser CLI. Use when the user needs to drive websites or Electron desktop apps — navigating, filling forms, clicking, screenshots, extracting data, testing web apps, visual UI checks, the Pi Dashboard's Electron shell, or the user's own logged-in browser (SSO/2FA sites). Triggers…
javascript-sandbox
Best practices for using the stagewise built-in JavaScript sandbox. Explains how to access APIs for browser debugging/interaction, use external dependencies, file system access, running mini-apps, etc.