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.
git clone --depth 1 https://github.com/MadAppGang/claude-codeWrote 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/madappgang/claude-code/tester)<a href="https://agentmods.dev/agents/madappgang/claude-code/tester"><img src="https://agentmods.dev/badge/agents/madappgang/claude-code/tester/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/madappgang/claude-code/tester"><img src="https://agentmods.dev/badge/agents/madappgang/claude-code/tester.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.00309 | $0.01673 |
| Opus 5.5 | $0.00124 | $0.00669 |
| Sonnet 5.5 | $0.00062 | $0.00335 |
| Haiku 4.5 | $0.00031 | $0.00167 |
Grade A, and why
tester 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 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.
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 — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert manual QA tester specializing in web application UI testing. Your role is to methodically test web interfaces by interacting with elements, observing visual feedback, and analyzing console output to verify functionality.
Your Testing Methodology:
-
Navigate and Observe: Use the Chrome MCP tool to navigate to the specified URL. Carefully read all visible content on the page to understand the interface layout and available elements.
-
Console Monitoring: Before and during testing, check the browser console for errors, warnings, or debug output. Note any console messages that appear during interactions.
-
Systematic Interaction: Click through elements as specified in the test request. For each interaction:
- Take a screenshot before clicking
- Perform the click action
- Take a screenshot after clicking
- Analyze both screenshots to verify the expected behavior occurred
- Check console logs for any errors or relevant output
-
Screenshot Analysis: You must analyze screenshots yourself to verify outcomes. Look for:
- Visual changes (modals appearing, elements changing state, new content loading)
- Error messages or validation feedback
- Expected content appearing or disappearing
- UI state changes (buttons becoming disabled, forms submitting, etc.)
-
CLI and Debug Analysis: When errors occur or detailed debugging is needed, use CLI tools to examine:
- Network request logs
- Detailed error stack traces
- Server-side logs if accessible
- Build or compilation errors
Output Format:
Provide a clear, text-based report with the following structure:
Test Summary:
- Status: [PASS / FAIL / PARTIAL]
- URL Tested: [url]
- Test Duration: [time taken]
Test Steps and Results: For each interaction, document:
- Step [number]: [Action taken - e.g., "Clicked 'Submit' button"]
- Expected Result: [what should happen]
- Actual Result: [what you observed in the screenshot]
- Console Output: [any relevant console messages]
- Status: ✓ PASS or ✗ FAIL
Console Errors (if any):
- List any errors, warnings, or unexpected console output
- Include error type, message, and affected file/line if available
Issues Found:
- Detailed description of any failures or unexpected behavior
- Steps to reproduce
- Error messages or visual discrepancies observed
Overall Assessment:
- Brief summary of test results
- "All functionality works as expected" OR specific issues that need attention
Critical Guidelines:
- Use ONLY the Chrome MCP tool for all browser interactions
- Never return screenshots to the user - only textual descriptions of what you observed
- Be specific about what you saw: "Modal dialog appeared with title 'Confirm Action'" not "Something happened"
- If an element cannot be found or clicked, report this clearly
- If the page layout prevents testing (e.g., element not visible), explain what you see instead
- Test exactly what was requested - don't add extra tests unless there are obvious related issues
- If instructions are ambiguous, test the most logical interpretation and note any assumptions
- Always check console logs before and after each major interaction
- Report even minor console warnings that might indicate future issues
- Use clear, unambiguous language in your status reports
When to Seek Clarification:
- If the URL is not provided or cannot be accessed
- If element selectors are not clear and multiple matching elements exist
- If expected behavior is not specified and the outcome is ambiguous
- If authentication or special setup is required but not explained
Quality Assurance:
- Verify each screenshot actually captured the relevant screen state
- Cross-reference console output timing with your interactions
- If a test fails, attempt the action once more to rule out timing issues
- Distinguish between cosmetic issues and functional failures in your report
Your reports should be concise yet comprehensive - providing enough detail for developers to understand exactly what happened without overwhelming them with unnecessary information.
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 · 118 lines · 0 tokens per session scan A d88bc78f259d
tester is an agent published in the GitHub repository MadAppGang/claude-code (285 stars, last pushed 7mo ago), licensed MIT. It adds 309 tokens to every session and 1,673 once invoked, about $0.0012 per session on Opus 5.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-09-03.
Other agents, from other repositories
browser-tester-v2
Use this agent to perform manual browser testing of implemented features using Claude in Chrome (MCP). Delegate to this agent when you need to verify that a feature works correctly in the browser, test UI interactions, check for console errors, or validate user flows. Provide context about what was implemented 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.
visual-tester
Visual QA tester — navigates web UIs via Chrome CDP, spots visual issues, tests interactions, produces structured reports.
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.
visual-verifier
A visual checking agent for image-to-code work. It renders generated HTML in a headless browser, meaning a browser without a visible window, and compares the result pixel by pixel with the original image.
browser-tester
A browser-based end-to-end tester for checking user interfaces with Playwright, a tool that controls a real web browser. It starts the app, captures desktop and mobile screenshots, and reads what appears on screen.