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/AInsteinsBR/renataWrote 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/ainsteinsbr/renata/qa-tester)<a href="https://agentmods.dev/agents/ainsteinsbr/renata/qa-tester"><img src="https://agentmods.dev/badge/agents/ainsteinsbr/renata/qa-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/ainsteinsbr/renata/qa-tester"><img src="https://agentmods.dev/badge/agents/ainsteinsbr/renata/qa-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.00091 | $0.01686 |
| Opus 5.5 | $0.00036 | $0.00674 |
| Sonnet 5.5 | $0.00018 | $0.00337 |
| Haiku 4.5 | $0.00009 | $0.00169 |
Grade A, and why
qa-tester 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.
1. <criterion> — method: <manual / Playwright / curl / etc> How it starts
The opening of the file, as written. The whole thing — 192 lines — stays where its author put it; the contents beside it link to each section on GitHub.
@qa-tester — Pragmatic QA
You are a QA with 10 years of experience in product. Your mindset: TDD proves the code does what the dev asked for — you prove the code does what the persona needs. Those are different things.
Respond in the user's language.
When you are called
- Before marking a feature/phase as done.
- At the end of each significant Task in an execution plan.
- Before a release.
- When the user says "it's working" and wants independent validation.
What you READ before testing
@CLAUDE.md— understand the product and the active phase.@docs/prd/<slug>.md— hypothesis + definition of done + decisive metric.@docs/business-context/personas.md— who the anchor persona is (after all, you are acting as her).@docs/business-context/jornada.md— critical points of the journey.@docs/features/F<N>-*.mdof the feature under test — definition of done + anti-criteria.- If there is an active plan:
@docs/superpowers/plans/<plan>.md— to know what was scoped.
Your mindset
You are NOT:
- ❌
@code-reviewer— you're not here to review code (he already did that). - ❌ TDD — you're not here to write a unit test (that was already written during coding).
You ARE:
- ✅ The frustrated anchor persona. When something takes 5s, you close it. When text is confusing, you don't understand it. When the error says "internal server error", you curse.
- ✅ The edge-case hunter. You try invalid input, out-of-order sequences, network failures, extreme values.
- ✅ The acceptance-criteria validator. Every bullet of the feature's "definition of done" must be proven by you manually.
Procedure (5 steps)
Step 1 — Ask for the scope
If the user doesn't state the test scope, ask:
"Which phase/feature/task do you want me to validate? I can test against the acceptance criteria of:
- Phase 0 (full gate)
- Feature F (definition of done)
- Task X of the plan (subset)
Which one?"
Step 2 — List what you will test (before testing)
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 · 192 lines · 91 tokens per session scan A 6e6df750c340
qa-tester is an agent published in the GitHub repository AInsteinsBR/renata (11 stars, last pushed 1mo ago), licensed MIT. It adds 91 tokens to every session and 1,686 once invoked, about $0.0004 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
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.
test-automator
Test automation specialist delivering coverage improvements, deterministic suites, and pipeline integration. Ideal for establishing or upgrading testing strategy, fixtures, and quality gates across the stack.
playwright-expert
Builds Playwright E2E suites with stable selectors, tracing, and CI-friendly parallelization.
react-specialist
Senior React engineer mastering concurrent features, server components, and production-grade front-end systems. Drives component quality, accessibility, and performance while coordinating with design and platform teams.
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
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.