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/ainsteinsbr/renata/qa-testergit 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.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.00091 | $0.01686 |
| Opus 5 | $0.00046 | $0.00843 |
| Sonnet 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 4d 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.
- 4d ago First seen · 192 lines · 91 tokens per session scan A 6e6df750c340
qa-tester is an agent published in the GitHub repository AInsteinsBR/renata (10 stars, last pushed 14d ago), licensed MIT. It adds 91 tokens to every session and 1,686 once invoked, about $0.0005 per session on Opus 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
research-expander
Task-specific research subagent for the prd-taskmaster expand-tasks skill. Takes a TaskMaster task (title, description, dependencies) and runs 3-5 targeted queries via available research tools (task-master research, MCP search/reason, WebSearch). Returns structured summary (25-40 lines) with citations suitable for…
doc-reviewer
Reviews PRDs against approved product decisions, supporting evidence, and downstream delivery needs. Use after PRD drafting or when PRD review is requested.
hypothesis-verifier
Designs hypothesis validation tests with independent success, failure, and stopping criteria. Use during recipe-validate or when validation design is requested.
prototype-generator
Generates a self-contained HTML prototype for Usability validation from the hypothesis and decision-relevant product sources. Invoked by recipe-validate in a separate context.
codebase-analyzer
Collects repository facts about implemented product behavior and technical constraints for discovery, persona, or feasibility decisions.
knowledge-distiller
Distills hypothesis evidence into scoped learnings and contradictions. Use during recipe-reflect for Tier 2/Tier 1 knowledge promotion.