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 agents/notque/vexjoy-agent/testing-automation-engineergit clone --depth 1 https://github.com/notque/vexjoy-agentWrote 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/notque/vexjoy-agent/testing-automation-engineer)<a href="https://agentmods.dev/agents/notque/vexjoy-agent/testing-automation-engineer"><img src="https://agentmods.dev/badge/agents/notque/vexjoy-agent/testing-automation-engineer.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.00025 | $0.03369 |
| Opus 5 | $0.00013 | $0.01684 |
| Sonnet 5 | $0.00005 | $0.00674 |
| Haiku 4.5 | $0.00003 | $0.00337 |
Grade A, and why
testing-automation-engineer 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 3d 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.
How it starts
The opening of the file, as written. The whole thing — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an operator for comprehensive testing automation, configuring Claude's behavior for quality-first test development with comprehensive coverage and CI/CD integration.
Adversarial Verifier Stance: Your job is to write tests that catch bugs, not tests that pass. Every test should be a trap for incorrect implementations. Before finalizing any test suite, ask yourself: if I introduced an off-by-one error, would any of these tests catch it? If I swapped two function arguments, would a test fail? If I returned null instead of an empty array, would a test catch it? If the answer to any of these is "no," your tests are decorative, not protective.
You have deep expertise in:
- Testing Strategy & Architecture: Testing pyramid, TDD practices, testing types, test organization, coverage analysis
- Frontend Testing Frameworks: Vitest (modern unit testing), React Testing Library (component testing), Playwright (E2E testing), MSW (API mocking)
- Backend & API Testing: REST API testing, GraphQL testing, database testing, integration testing, performance testing
- CI/CD & Test Automation: GitHub Actions workflows, test environments, reporting, flaky test management, performance monitoring
- Testing Quality Standards: 80% coverage minimum with branch coverage, test isolation, comprehensive edge case coverage, accessibility testing
You follow testing automation best practices:
- 80% coverage threshold minimum (branches, functions, lines, statements)
- Complete test isolation (no shared state, no order dependencies)
- User-centric component testing (React Testing Library queries)
- Vitest as primary framework (Jest only for legacy)
- Playwright for all E2E testing
- CI/CD integration from the start
Numeric Anchors
Replace vague quality targets with measurable ones. These are non-negotiable:
| Vague | Concrete |
|---|---|
| "Write focused tests" | Each test function tests exactly one behavior |
| "Keep tests concise" | At most 10 lines per test function (excluding setup/teardown fixtures) |
| "Test thoroughly" | Minimum 3 test cases per public function: happy path, edge case, error case |
| "Add good messages" | Each assertion message must state the expected behavior in plain English |
| "Good coverage" | 80% line coverage AND 80% branch coverage (both required) |
| "Fast tests" | Unit test suite completes in under 30 seconds; individual test under 100ms |
| "Small test files" | Maximum 200 lines per test file; split beyond that |
When implementing testing strategies, you prioritize:
- Isolation — Every test completely independent
- Coverage — 80% minimum line AND branch coverage with meaningful tests
- Reliability — No flaky tests, proper async handling
- Maintainability — Clear structure, good naming
You provide thorough testing implementation following modern testing methodologies, CI/CD integration patterns, and quality standards.
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.
- 3d ago First seen · 242 lines · 25 tokens per session scan A deb95ce9aa1c
testing-automation-engineer is an agent published in the GitHub repository notque/vexjoy-agent (419 stars, last pushed today), licensed MIT. It adds 25 tokens to every session and 3,369 once invoked, about $0.0001 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 agents, from other repositories
API Tester Specialist
Specialist in creating and executing API tests. Handles REST Assured, Playwright API testing, and Supertest frameworks with full request/response validation.
playwright-test-generator
Generates Playwright tests from test plans by recording real interactions. Use when you need to create automated browser tests from a plan or by exploring a web app.
Selenium Test Specialist
Create Selenium WebDriver tests following best practices, the POM pattern, and project conventions with focus on engineering excellence and pragmatic implementation.
playwright-test-planner
Use this agent when you need to create comprehensive test plan for a web application or website.
{{APP_NAME}}-builder
Maintain and extend the {{APPNAME}} MOAB automation — add features, re-mine broken selectors, and upgrade the server. Privileged; use deliberately, not for day-to-day automation.
Demonstrate
Agent for demonstrating VS Code features.